Re: [glob2-devel] Goals for the next release

[Bradley Arsenault]

On 3/28/07, Kai Antweiler <address@hidden> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/glob2-devel


--
Really. I'm not lieing. Bradley Arsenault.