[glob2-devel] New Features galore (ps: someone else has to merge)

[Bradley Arsenault]

While I have been missing for a month, I am still alive and  have been
working on Globulation 2. My ne house doesn't yet have internet, the
customer service representatives told us the end of September, the
technicians say it could be as late as December. Anyway, I have been
working hard on improving globulation 2.  A whole load of new features
is coming, as soon as someone takes the time to merge in the changes I
am uploading. (I can't merge them in, I have to operate off a library
pc with windows and no installations allowed. I'll describe later how
to retrieve my changes). Anyway, the changes are as follows (in order
of me completing them)

- New unit and building editor -

The map editor has new unit and building editing functionality! The
many in-game properties of units and buildings are editable. This is
achieved simply by clicking on the unit. The proccess of adding a new
editable property is simple enough, if someone wants a new editable
property for units or buildings added, I can do it. (This does *not*
allow the editing of ingrained building-type properties, only
properties mutable at game-time).

- New translation text shot code -

Personally, this is my favorite new feature. The translation text
shots are bassically screenshots that are taken of the screen when a
particular translation key is drawn to the screen. But not only that,
the translated text is highlited as well! This means translators will
be able to trivially get context to their translaions. It is enabled
by running glob2 with "glob2 -textshot <directory>". You can use "."
for the current directory. All of the screenshots are bmp's, so watch
out for hardrive consumption.

- New Script Areas -

Thats right, the old way of doing areas in scripts has been replaced.
The map editor now features new script areas. These "areas" can be in
any shape, they have a name and are place dmuch like forbidden zone.
Their can be between 0-9 of them on any one map. (The limit 9 is made
because each square is labeled with the areas it contains, in a 3x3
square, there are 9 places to draw a number. As well, script areas are
a light aqua in coloring). This is replacing the conventional position
and radius way of doing areas directly from the script. The old way is
still there, however a message signifying that its deprecated is sent
everytime the game is run. I did not make the changes on the tutorial,
since the script I had was not the one that has been merged with all
the translations.

- Improved Echo API -

The Echo API has been made much more generic since its last revision.
Conditions has been generalized, it is now much mroe powerfull. The
proccess of automatically constructing and upgrading 10 inns, to be
cosntructed and upgraded in sequence (1 after another), and having
upgrades start after the fifth is complete, *and* allowing the chain
of construction to continue even if one of the buildings is destroyed
takes a mere 100 lines of code, including all of the code to choose a
location. Its not bad for a low barrior approach to an API. This is
done via enhanced conditions, the merging of all the types of
management orders, and the allowance of building orders to accept
conditions. However, this shift in the API did not come with one
sacrifice: old save-games using ReachToInfinity can not be loaded with
the new API. Please don't scream, this was a nesseccarry sacrifice. I
thought long and hard to avoid it, I couldn't work arround this
difficulty, and still have the new API that I wanted.

- New No-Ressource-Growth Areas -

Thats right, this is the solution to those horrific "I can't upgrade
my racetrack bugs". These new areas, again placable like a traditional
zone from the map editor, restrict ressource growth . Nothing can grow
from, or into these areas. I haven't changes the tutorial yet, again
because I don't have a version with the merged translations. I will do
it as soon as I get internet at my house.

- Updated End-Game screen -

The end game screen graph has been signifigantly improved. Among the
new features includes time scaling, and amount marks. As well, you can
disable and enable particular teams to be drawn. And, if you move your
mouse pointer close to the lines on the graph, it will give you the
value of that position. These improvements make a siginifigant
contribution to the usability of the end-game screen graphs.

- New statistics -

You know how in the game, the statistics screen tells you that you
have tons of free workers, but the upper left hand statistic on the
top-bar of the screen tells you your desperately needing jobs? I've
now added for more small statistics that should help this
signifigantly. Each tells how many jobs are needed *per level*. This
can tell you if all of those unfilled jobs are level 2 jobs, which may
signify that you need to build more schools to train faster. This
should help us advanced players considerably.

- New overlay areas -

Now for a completely unique feature. I got this idea from Sim City
4000. Sim City would tell you what areas had, for example, the largest
polution, crime, or desirability. It did this by overlaying color onto
the main screen to signifiy the level of that particular overlay. I,
my friends, have done the same. You will now see, on the statistics
graph menu, three new check boxes with captions "Starving Map",
"Damaged Map", and "Defense Map". By clicking one of these checkboxes,
colors will be overlayed on the main screen. You can see areas of
concentration for starving and damaged units, and your areas of high
defenese. Remember all of these values are relative to the maximum
number of starving or wounded units, or your maximally defended areas.
(Having a finite graph was an option, but I decided I alone couldn't
achieve a good maximum and minimum value, since I wasn't the general
playing population). Gradient here is used in the graphical sense, not
the pathfinding sense.

Now, with low quality mode enabled, the score of a box is simply
converted to an alpha for a color and drawn to the screen. Bassically
it colors in 32x 32 boxes. With high quality enabled, I tried
something trickier. I attempted to gradient between the boxes in 8 x 8
sections (8x8 is sufficiently small you can barely tell). The
gradients are indeed extremely complex to do without writing a value
for every 8x8 box ( which would take up 16 times the memory of using
the standard squares anbd giving values to them ). The gradient
formula was very difficult to create, and it still has allot of error.
Its reasnobly enough to create a decently smooth gradient in areas of
high concentration. When there is only 1 starving unit on the entire
map, on teh other hand, and you enable this overlay, the flaw in my
gradient formula becomes clear. Te formula bassically takes the
average of the north-south gradients and the east-west gradients. The
value of the box in question is entirely ignored, its the surrounding
boxes that are considered, and the gradient is calculated between
them.

I went through *allot* of expirementation to come to this result. I
can honestly tell you that it is the best I could come up with. I
spent hours with a notepad working our formulas to make the gradient
the way I pictured it appearing in my head. I just couldn't do it. I
tried averaging between all 8 surrounding squares, not just four of
them. That turned out very mismatched. I tried calculating the
gradient of a square between what would logically be the score between
the lines that seperate the 32x32 pixel squares. That turned out too
blocky and obvious. I tried developing the gradient based on the
maximum instead of the average, that turned out just odd, I can't
remember how, but it just did. Anywho, I encourage anyone who has
experience with graphical algorithms for a gradient like what I'm
doing to improve my scode, its about 50 lines before the end of
Game::drawMap in Game.cpp. It sticks out because of all the
const-float definitions used in the formula. It should be easy enough
to figure out.

One question to nct/nuage, is it semantically correct to send the size
of the map to TeamStats in Game::load? Is there another setMapSize
function that I should locate the code into? The overlay maps are
calculated everytime the teams stats are updated (about once every 4
seconds).


- Thats it -

I didn't get anything else done. Un-impressed? I worked my ass off!
Ahh just kidding. These changes where fun to do. I hope you enjoy
them. Most of you wont enjoy them quite yet, because someone has to
merge them into the current cvs. I'm in the proccess of uploading the
glob2.tar.gz to my website, and I'll post some merging information on
another thread once I get that done.

--
Start and finish, Bradley Arsenault