On 3/28/07, Kai Antweiler <[EMAIL PROTECTED]> wrote:
What do you mean by: "Alliances should be able to be changed in net games as well" So simply everyone will change to the same side during the game, so that everyone wins because the looser alliance is empty?
Well meaing that the host can set who's allied with who before the game match begins. I forgot to add in that it should be possible to freeze alliances, so (other than inn view and such) you can't change alliances in the game.
"Serious consideration should be given to using a system like Guile or Squirrel in the game." Using fullblown languages would be really insecure. Hacker should at least need to search weak spots in the code. Simply letting them write a campaign with scheme commands they want and distributing it, is not a good practice.
Neither Guile or Squirrel are really full blown languages. Both of them have the capability to limit the end user functionality. Squirrel especially just doesn't provide the users with hax0r like functionality to begin with Tightly controlling a script in Guile is simple, I've seen the code, and cutting off a script from all file and network interaction, all interprocess communication, and any other tool is as simple as not loading those modules. I want a scripting language mainly for those high level constructs that make it turing complete.
"Random numbers must be synced!" Only the game play relevant ones. And they are, otherwise the netgames would fail.
I'm thinking more along the lines of if we seeded our syncRand with the time at program startup (which we don't yet), much like the net code, recorded games would need the syncRand appropriately seeded to.
Random numbers for (let's say) cloud movement don't have to be synced. Btw: also stl/boost classes and algorithms that use randomness (like multiset) are not allowed for gameplay. > Our version 1.0 has to be ready to earn its title. All loose ends > tied, bugs are fixed, settings are all meaningful, the game is well > documented, the interface clean. I don't want to do any major gameplay > changes like adding a building untill after 1.0. I do. And seriously we're talking about only freezing new development until 1.0 for years. I am getting sick of it. We are not one step closer to getting the network right. In fact we are further away since nuage left. I not only want new features (after our next release), I demand them! We don't get people into our team by telling them: "Your not allowed to do the things you want. They're good ideas. We would need them, but we are fanatic about that 1.0 thingy." Instead of limiting the development we should encourage to document new code and make it more maintainable and reusable.
I don't want to "freeze" development. From what I've heard from other people, the "1.0" release was meant to be done when things looked good. But I suppose you have a point, we should perhaps drop the idea of reaching 1.0, and stay the path with one release after another.
> I think most of our game is done, we just need to get all of those > little things put together to create the ultimate open source RTS. Most people (for some reason) like that typing tutor like fealing of other RTSs. I don't think we will be the ultimate open source RTS. But we already are: "the ultimate micromanagement minimizing RTS".
Just trying to Pep things up. Glob2 is a successful game as it stands. It did not fade away like many attempts to make open source games, and now has a growing community of players.
Most of us only know small part of the code and don't have the time to read through the highly entangled rest of glob2. Even if some changes seem inferior from the perspective of a glob2 coding experts, it's often all you can expect. Especially in open source where the developers frequently change, you'll have a lot of coders that don't know the code much. Forcing them to focus on things they don't know is bad. To be clear: setting priorities is a good thing. But it still has to be absolutely clear that contributions in other areas are welcome! (And realistically will be more frequented than the main issues.) >From my perspective increasing our workforce has absolute priority.
Well as the active coder its these things that *I'm* going to focus on. If we live on a release-to-release basis, Its good to have some goals for the next release. In particular, I've noticed that while Glob2 does have the game play and the features, it doesn't use them and showcase them as well as it could.
ps: I still would like to have an easy way to change which graphic tiles glob2 uses from inside the game. It's a shame that shew's graphics are lying around without being used. Doesn't anybody know this part of the code. -- Kai Antweiler _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
-- Really. I'm not lieing. Bradley Arsenault. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
