Re: [Kai Antweiler] Re: [glob2-devel] Thats it, we need a plan

[Bradley Arsenault]

> From: Kai Antweiler <address@hidden>
> Another subject:
> have you seen this?
> http://glob2.com

Jesus christ, they could trademark "Glob2", and that would nearly end
all slang on our website. I'm too lazy to type a full Globulation 2
all the time.


> ---------- Forwarded message ----------
> From: Kai Antweiler <address@hidden>
> To: Globulation2 development mailing list <address@hidden>
> Date: Tue, 21 Mar 2006 13:09:38 +0100
> Subject: Re: [glob2-devel] Thats it, we need a plan
> > This is it. I'm starting to get bored. I have nothing to do at nights.
> How about going to sleep? ;-)
I tried that, it didn't work :(



>
> This is one thing I want to see changed someday.  For a game which
> claims to reduce micromange management, it is not acceptable to be
> outperformed in this point by the *craft games.  Our building
> construction/upgrading takes much more human involvement than theirs,
> because we can't place ten buildings into a queue and expect them to
> be constructed efficiently.  In glob2 we would have to wait till
> one building is finished then request the next and so on or we
> would end up by ten construction sites and no finished building.
> I would prefer a queue for building construction/upgrading rather
> than your priority system, since it would be simpler for the user.
> (First requested job gets done first - reordering is unnecessary.)
> But I fear that this would not be as easy to implement as it sounds:
> When we have a large colony the player might not want his workers to
> travel from one end to the other, if on both ends are jobs with
> different priorities.  That applies to your priority system, too.
> Priority AND proximity would need to be considered when it comes to
> job assignment.  I don't know if this could be done till 1.0 .

Indeed, proximity should be considered. And I agree, getting the right
balance of priority and proximity for job assignment will be
difficult. We'll have to implement it and do usability testing.



>
> When it comes to unit training I don't think I care much if my globs
> learn running before swimming.
>
>
>

> One problem that I believe has to be dealt with before 1.0 is the
> I-have-100-globs-and-most-of-them-seem-to-do-nothing-although-I-have-
> requsted-many-jobs-problem.  If this is done by improving the code or
> writing user docs which explain why the globs behave in that way,
> is less important.
> One easy change might be to split the free glob number into three -
> each counting free globs regarding their education level.
> The tutorial explains this point, but I think it might be a big help
> to implement it anyway, because the general glob-job relationship is
> too confusing.  To know a part of it for sure and in numbers should
> reduce user frustration.

I personally think this is partly due to a bug. Another person
mentioned the bug on a new thread 5 minutes ago, although hes found a
method to reproduce it, where as i Didn't when i brought it up several
weeks ago.


> --
> Kai Antweiler


Thanks Kai, Bradley Arsenault.