Re: [glob2-devel] increasing our workforce

[donkyhotay]

The real way for any open source project to thrive is to get community
interest in it. The more people following a project the more
beta-testers there will be which leads to more people working on the
project which leads to faster growth. By this line of reasoning
"increasing our workforce and the number of users" should be our top
priority. Sadly I don't know of any very good way of doing this besides
just trying to get the word out. I mean we are listed with good reviews
in happypenguin.org (it's how I first found out about the project) and I
assume other linux/OSS game reporting sites. I think if anyone out there
is aware of a game reporting site that doesn't have a listing of us then
(especially for linux/OSS) then we should submit the game to them. We
also need to work on the game ourselves and update it more regularly.
Last I checked the official version STILL has the flag-desync bug in it.
It's been awhile since I've been able to look at the code much less work
on it but I fixed that bug and uploaded onto CVS awhile ago (this was
just before bradley's improvements were done). Having rapid releases for
a program isn't necessarily a bad thing, especially when it still hasn't
reached the 1.0 stage like glob2 is at right now. At one point linux
itself had more then one "release" per day. It just shows users that
it's being worked on. What would be really good is to have a "stable"
version and a "test" version. Many other OSS programs work this way and
to a degree we do this with the CVS version however when the "stable"
version has a serious defect in it that isn't quickly corrected then
people assume it isn't being worked on and lose interest in it. It
doesn't matter if the test version has the fix because people assume the
stable version is going to be the one that works the best and the test
version will have more features but buggier. I'll admit I haven't had a
chance to work on glob2 in awhile (school & work take up all my time
right now) and bradley's contributions have been put on hold due to his
connectivity issues but whats happened to everyone else? I mean, merging
the source code is tedious but from my perusing of my changes along with
bradley's changes I don't think it will be difficult to merge them. Most
of the changes made to prevent flag-desyncs don't affect the features
implemented by bradley. The places of overlap had to do with the fact
that the networking now sends/recieves the default number of workers
assigned to a flag/building in addition to the type-player-location.
Simply make certain that the new orders (especially AI orders) include
the new variables (I just put a default 1 for all AI's since that is
what they were originally designed for) and a CVS merge should do it.
Anyways getting back to what we were discussing previously I think the
best thing we can do right now is let our users know that glob2 isn't
dead and IS being worked on. First of all we need to update our latest
official version (at *least* implement the fix for the stupid
flag-desync). Second we need to update the official version more
frequently or make it easier (and advertise) the CVS version more. If
users know the program is being worked and can SEE those changes because
of the updates (whether to the stable or test version) people will be
more interested in it and build up a bigger user base. If we don't do
anything glob2 will end up as just another abandoned project which would
be a waste since I think glob2 is the best RTS I've played since
starcraft (and after playing glob2 I have often wished I could use flags
in starcraft to command my units). 




On Tue, 2006-11-28 at 17:09 +0100, Stéphane Magnenat wrote:
> On Tuesday 28 November 2006 12:07, Kai Antweiler wrote:
> > I'd like to make "increasing our workforce and the number of users"
> > our top priority.
> 
> Agreed, especially workforce, we do not even have force to reply to bug 
> reports.
> 
> > If anyone has a good idea how to achieve this - please reply.
> > Is it really feasible to rewrite the network code (Bradley) in a
> > reasonable amount of time?
> 
> It's an hard job but feasable, yet it requires people with time and 
> experience 
> with network code to work on it. I suggest working in a branch for such big 
> changes.
> 
> > I wonder how many users we have.
> 
> Probably more than we imagine, because on large inclusions in distributions, 
> but most people probably play single or local games.
> 
> > Is it possible to count the number of users that regulary play
> > or the number of glob2 network games per week?
> 
> It would be a relative easy change to YOGserver.
> 
> > How about getting the numbers of network games for each day and hour,
> > like a schedule?
> 
> Nad making web statistics out of the YOGServer, it is feasable.
> 
> > Are there enough players to do a tournament and is the network stable
> > enough for this?
> 
> Probably, but difficult to say.
> 
> > When would be the best time for this?
> 
> what do you mean ?
> 
> > Could we implement a glob2 ladder (despite the network bugs)?
> 
> Probably, but if there is ladder there will be much more cheating.
> 
> > How many users create maps?
> 
> Hum... good question.
> 
> > Can we make user votes on maps and put the results on our homepage?
> 
> It would be nice to have a web-based repository of maps that could also be 
> accessed from the game, that is the idea I had behind the head while making 
> the stream system.
> 
> > Are there maps that promote quick games (30 minutes)?
> 
> It is feasable, but the risk is to reduce the strategical depth, altough it 
> is 
> probably not depth enough anyway.
> 
> > We could implement campaign like games, where every side is played
> > be a human player.  Thereby advanced players can play against less
> > advanced players without having to hold back.
> > Also games could be much faster, since the building phase already happend.
> 
> That is a funny but interesting idea.
> 
> > If we ask our users to learn c++, could that possibly work?
> 
> One requires more than some knowledge of C++ to enter into glob2's codebase, 
> which is not well documented and quite complex ; but some might manage to, if 
> they are programmers already.
> 
> Have a nice day,
> 
> Steph
>