DEV BLOG :: SEPTARIUM
Title: The Pursuit Of Perfection
Remodeling established doctrines.
Project development whirls around one tiny casus: planned ideas, written into game design document, sometimes can't be accomplished due to insufficient experience points. Killing boars won't gain required experience for leveling up...
Although technical game development just got too close to the final stage. However, the golden rule states: never get things that are already done more better or perfect before you finish project. Don't get me wrong! Aspiration for perfect is insatiable but it is quite rewarding monster that needs to be taimed carefully. As I said before, this is nothing but endless race - one can spend all life to improve his projects. Does that one realize he won't be satisfied after all? Perfectionist is like a mule who has attached stick in his neck with droopy carrot in front of him. This sounds harsh... well, comparing with other types, these one are the only who constantly moves forward.
Project forced me to overlook some core elements of the engine - particle system. There was a task to construct dynamic and attractive starfield and particles were great solution. I'm saying this cause, to think, for some reason i thought to write dedicated class for that... derp! During its development i had to rewrite, add novelties and tweak (the beak) particle system. In result, particles became more dynamic and extended. Previously, i used to attach texture reference into particle so that render function will use it to determine texture. This caused "set texture, set color, draw verticles" in great number and that caused unchildish performance hip. The idea was to set any texture game wants, including game sprites like ships. So, solution was obvious (it wasn't before i know it): make small database of particle sprites and use iter id to set texture only once and then draw tonz of verticles, then set second text and go again...
With the help from TinyXML
Sprite class got itself a brand new alternative way of loading textures – using right document you can make more flexible magic: set individual speed for each frame, cut stuff and make a large atlas etc. For some reason xml sprite loading via “create bitmap and draw stuff” cut down less resources rather than unremarkable al_load_bitmap at the end. Magic!
Sprite class started to grow and asked for more food. I guess this was most irritating moment in this development period. Class was rewritten several times till it became ideal. I had to spawn new class - bitmap data class, the one which will hold bitmaps (hello from captain obvious) and some base animation data. Sprite inherits reference from bitmap class, adapts animation base values and acts as if it was something new... something different from the bitmap class it sits on. The reason of changes are quite simple. The first one, is ridiculously retarded – long time ago each sprite object had its own bitmap so if there were 5 enemy units – there were 5 same bitmaps in memory. Lately, after playing with shaman's tambourine sprites turned global. There were sprites that served as bitmap holders and game entities had pointers to these sprites. The core of troubles lied on its dependence. I wanted for each object to have its own animation with user options, with ability to add layers with new animation and other gimmicks that made this sprite into pseudo animation scene node. Attempts against “You shall not pass” were different – idea to pass vector reference from base sprite to derived was a total hoot; cpp doesn't like it and punishes programmer very hard for such sins. Shortly speaking, each sprite was about to have pointer to hybrid bitmap-animation class. That's it! Simply putting pointer on allegro bitmap caused damn inconveniences lately so I guess things were done in right way. Well... Just like previous task this one was finally done – with bug free code, cheetah performance and perfect flexibility. Sprites are essential part of the game development so I guess dedicating time for its optimization would be unquestionably vital.
Hm... next task was dealing with very popular topic in gamedev. And that is collision check. Theoretically it was piece of cake but as always with shit inside. In practice things were not so good as it should be. One topic in stackoverflow
served as proper way out. Adding some hacks to it and finalizing task with circle check made me smile like that Cheshire cat. Just like in history of mankind, every deed determines another. To make development more comfortable I wrote new abstract class of game entities. By the way, there was strange issue with abstraction – objects that were derived from new abstract class refused to pass pointer of themselves in collision check function. Again, Stack made the day and taught me what is dynamic_cast
. I must say stackoverflow is the best source of answers for my unasked questions.
Game design document strongly suggests for game to use camera zooming. Since the game is 2D the only way was to use allegro transformation functions (scaling). Kudos goes to allegro this time. Just like stackoverflow, allegro.cc forums has tonz of useful answers. I recalled Huckleberry hound, cartoon character made by Hanna-Barbera. Can't say why but the song he often sang «Oh My Darling Clementine» spontaneously intercepted my mind; half of day me and my neighbors were listening to it , while doing the game of course.
Apart from technical programming, some parts of game design begun to appear in the game. Development took its place in designing of first enemy unit – Explorer. Behavior of explorer is inspired by water strider, which is sort of a “bug” I was talking about in previous development entry. It floats from one point to another with smooth tweening transaction and shoots at enemy on stop. Obviously, as first enemy unit, explorer will be much more weaker than others with an exception of dealing damage that ignores protagonist's defense. Apart from that, bullets will deal extra damage based on current structure of the victim. Perhaps, these facts may rise a question similar to “It's not so easy as you say, isn't it?”. Well, during early stages player will experience difficulties due to lack of experience and inferior gimmicks on a board, this is for sure. Even in late game explorers, when player will most likely be brand new polished terminator, will cause difficulties due to armor piercing damage. Of course, once you master spaceship control and figure out enemy weaknesses things might go way to easy for you(a bit unusual cons, not like “gee, it has low resistance against rockets so burn it with fire” but more interesting based on how player behaves rather how much rocket deals damage to it; Weakness? Nah! Won't spoil da stuff folks). Now, I won't make player public as enemy number one in this game because units will have alignment flag - it is possible for alien to become hostile to other brethren and even ally with player.
was installed on ancient laptop of mine. Distribution promised to work like a charm on weak computer. After playing with it for some little time it was clear that distro kept its words. Once game source was transferred to laptop new problems came out. Tuning up development environment is child's play in linux – I was very happy cause of this since doing same stuff on windows in any cases can't compete with penguin's abode. I had to fix some boring stuff related with compiler differences like put a white space between template <> symbols or define null as ... null (haha) in some external parts of the game. Finally, when compilation was done with no errors I noticed vast number of warnings. Dafuq? Actually I don't give a brick to such warnings but its very irritating and somehow to realize this. I guess all in all it was just another brick in the –Wall. Will cover 'em later.
Soon, a thing appeared which made me move todo element «make it work under linux» on last place. Dunno why but render doesn't work, segmentation faults shows up and some other shit pointing that something is wrong with boost libraries. What can be wrong with boost libraries? I tried to use magical spell but ...«A hollow voice says fool»...
About one of these slacking moments: recently I played new game called South Park: Stick of Truth. Friend of mine insisted on playing it. One day a sudden boredom attack affected me. I started to play it despite indifference towards cartoon series. Each day of playing this retarded game made me ROFLMAO. I strongly recommend it to try at least. One of prominent game features is unpredictability – feeling I adore most.
Back to the devblog