syntax#1

74
BUGS AND BEASTIES
But then more and more little annoyances, limitations and bugs were
reported. Functionality needed to get rewritten, breaking other
functions and so forth. If you are a self-taught coder, you were surely
putting your feet into the shiny glaring trap right ahead of you.
Fixing bugs and rewriting functions is what most of us would describe
as boring and so motivation declined more and more. Progress became slower and formerly
active people focused on other things.
“
Having hard-coded settings in your application hides a lot of trouble you else will have to face.
I left the secure haven of hard-coded stuff I was required to code some proper GUI elements.
People like to rename their player chars, to select from drop down lists and all the little basic
functionality people of today just expect. Using BlitzMax meant easy access to graphics, sound
and other important stuff. But it did not provide access to a game GUI fitting to what I planned.
While writing the GUI stuff and other game functions I was also coding helper
functions to allow manipulating graphics in software. There was no „Render to
texture“ functionality abstracting the bindings to DirectX and OpenGL, so I needed
to do certain stuff on raw pixel data. At the end I was able to replace all “gray”
parts of an image portion with a colorized version. So player figures were drawn in
gray across all parts requiring colorization and then I was able to tint it properly.
Elements which were to display in gray were not possible without a little hack: a
slight tint (adding 4 to the blue channel). Having a GUI consisting of many single
image textures made the performance drop on the older computers some
people used for TVTower. So I‘ve read about sprite atlases. BlitzMax did not
offer support for sprite atlases per-se but allowed rendering parts of an image.
I utilized this in a custom sprite class which also handled animation setups and
special drawing variants. Having written all the helper functions increased
performance quite a bit and the game even drew tinted assets back to the
sprite atlases.
Next to the graphical parts the game required some proper data storage for the
game data , and so we switched from regular TXT files to XML.
The game became more and more playable. A lot of the game core mechanics
were working. It felt really playable. A big important step then was that another
user approached to me ...
In 2007 another German fellow applied for coding the AI in Lua. I gladly
accepted especially as BlitzMax offered Lua support already. Just needed to
learn how to make the AI be able to access game information. Months passed
and the AI started to move around in the building and to do simple
program schedule planning. Things got more and more complex and a
lot of requests were created. Instead of extending the game play
functions I was again just coding internal stuff nobody except the AI
would ever see. People loose interest if stuff does not change for
months. And I cannot expect the players to keep waiting for the game
for years.