About Dagovar

This is an introduction about my experience with the Dagovar Project, my most complex programming project and the most complex working task I faced in my entire life.

The beginning

During years I had been programming, and however I never was employed as a programmer. With more or less success I finished - or not finished - in my home many applications made with Visual Basic 6. The serie of games baptized by me as DAGOVAR was the highest point in my personal career of programming, albeit having many inconvenients, due to my non-existent formation in game programming. This project was based on the combat mode used in that now old game called Fallout Tactics - The Brotherhood of Steel. I only had a demo version of it, in that now far year 2001, but that was enough to make me wanted to make a game that ressembled the mechanics of that one; I was specially fascinated by the idea of managing inventories of items. In that time, I was pretty unexperienced with the world of programing; I just had bought my first computer in the last days of 1999, and I still own that old computer in this year 2012, though the monitor and the DVD drive died along the way... but I still use that computer to work when I have no other choice. In those times (the times just before Windows XP, an operative system that I never used) I browsed some books about "creative informatics". One day one guy said me that for doing such creative things I could use a thing called Visual Basic, so I got a copy of Visual Basic 6 and also bought a book for beginners. But for my future ambitious projects, that would not be enough...

So in 2001 I started to work in the project, having very few idea on how I had to proceed to achieve some real success. In that time I had no internet connection, so I could not access resources such as information, applications or graphical files to work with. My first problem to solve was to get a library of graphics for creating the character animations. I chose to get the female characters from the Fallout 1 demo; they looked nice to me, they had six orientations and walked in a strangely hex-based terrain. Since I could not access some scrapper utility to extract the graphics, I just took screenshots from the game and then isolated each one of the character frames in Corel Photo Paint, carefully - and tediously - deleting the background. Then I spent many time in the tedious task of repainting over the original graphics to give them a different look, increasing their size as well; certainly, my doubtful drawing skills technically screwed the aspect of the animations, but that aspect was not crucial for my experimentations.

Since I had no idea about how a game engine worked, instead of using loop cycles and GDI functions (Bitblt) to move and draw the game, I used what I knew then: Timer controls and Picture Box or Image controls. The result was that the maps were not tile-based, but instead a single piece of terrain "rendered" with a big ugly-looking picture. It was very uncomfortable to set the unwalkable spots that I defined with Shape controls that I placed in the same way of terrain tiles are placed. So I had to create the maps within the programming environment; each map was a Form control that had its own - repetitive - source code and controls. Just crazy. The characters' animations were based in Image controls that moved and changed their frame by using Timer controls; each possible character in game had its own Image control dedicated to it, and Timer controls were used for managing any temporization. The result was that with more than two characters, the game started to slow too much, and it was noticeable that the characters would not move at the same time. So I abandoned the project and left it archived until I could continue it in another way.

The awakening

It was summer of 2003 when I had installed my first internet connection, with a 128 kbps cable modem. That would make possible many advances in my projects. The first experimentation that I worked on was a generator for tile-based terrains. I had to be very patient to create the complex source code that would arrange the field of tiles. Since I still did not managed the Bitblt function, what I did was to use a collection of Image controls that would be created during execution time. So I placed inside a Picture Box a single Image control with its Index property set to 0 that had the picture of a terrain square; I would make the same thing for the array of objects (trees, for example). So for creating a map that would be 40 x 40 squares, I would create in execution time a collection of 1600 Image controls, having each one of these its corresponding picture of an isometric, diamond-shaped square. By using a certain algorithm all of the Image controls would be arranged to form the entire map, inside a Picture Box that would be previously resized to match the size of the square-based terrain. A set of Timer controls would be activated or deactivated in order to move the map in the four directions required. The system worked, but the unpleasant problem was that the damn Image controls blinked their invisible background color when moving...

The resolution

In the summer of 2007 I had the DAGOVAR project long abandoned, albeit until that date I had discovered most of the things that I needed to achieve a successful result. One of the programs that showed this potential was MapEdit (source code available in this website), an application that was able to create simple square maps and save them in a file. This program included the basic techniques needed to make a game that can work: GDI-based rendering (Bitblt function) and loop-based time managing (cyclical multiplexing). The maps created in MapEdit supported animations that worked smoothly and additional objects could be added externally to be included in the maps. I did not used this last technique for the DAGOVAR games, being the graphical files and object definitions compiled within the executable files.

I decided to use a simple inventory and simple traits for the characters, to avoid getting overwhelmed by an excessive complexity in the source code. I created separated applications for creating characters and maps, since this would simplify the work as well. The most complex application would be the game itself, which has to load characters and maps, create the interaction between the characters and the environment, set the rules of play, save and load the in-game status, etc... The Desert Vixens games include around 20000 lines of source code in all the applications together; the first version of Desert Vixens took around four months to be completed, and this because I took advantage of the work previously done. However, I had to wait more time to find a solution for the pathfinding question.

After finishing the first Desert Vixens, I decided to create the Combat Dolls version, on which I included a big number of variations: a totally different terrain structure, made of hexagonal tiles, the use of random terrain generation instead of maps made with a scenario editor, three different terrain types and colored camouflage for the computer-managed dolls to match each of those environments, new character skins (hair and skin color), increased number of weapons, modified interfaces (vertical control bar instead of horizontal one, separation of the inventory and traits interface into two different windows, etc...) and the save/load function, which allows multiple files to be saved. I had suppressed in Desert Vixens this traditional way of saving the game status to force the player to win the game with only one try. This was intended to add realism and challenge to the game while suppressing the need of writing filenames, deleting files, etc... Well, returning to Combat Dolls, I have to say that, in return, I decided to simplify some parts of the game, by suppressing special ammunition types, antibullet vests and night time.

In Desert Vixens 2 I added the A* pathfinding algorithm, the campaign mode and the new character skins used in Combat Dolls, while in Desert Vixens 3 I added more weapons - specifically the same weapons used in Combat Dolls but with some variations - and some new inventory items, a greatly increased set of graphics, with many new objects for the scenarios, practically doubling the amount of objects found in the previous Desert Vixens 2, changed the angle of the terrain view to make it symmetric and added the RandEdit utility... really so much things... I will tell in the successive chapters how I did to create the diverse parts of the DAGOVAR games, solving the numerous problems that they presented.

The following images are an example of the numerous graphical files used by DAGOVAR games. The images shown here are only for demonstrative purposes and therefore out of their real scale. Note that each image include a mask that uses pure white and black colors so the Bitblt function can draw the graphics with a transparent background. These masks can be included on a picture apart or in the same picture that contains the graphics; we just should keep as smallest possible the number of picture boxes used to store the graphics, because they demand resources from the system. If we want, we can make the graphical files to be quite large, exceeding the size of the game screen, to have the application graphics stored in a lesser amount of picture boxes to be managed.

About graphical formats, Visual Basic 6 allows only for the standard BMP, JPG and GIF formats. From these, I prefer the GIF over the others; BMP weights too much and I don't want my programs to be too large in MB, while JPG produces artifacts in the pictures, which can ruin the edges of the masks. GIF has the inconvenient of allowing only 256 colors on each individual file - a different, customized palette of 256 colors for each picture -, but I like it because it will not generate artifacts and it can weight so less as an average JPG.

Combat Dolls 2 terrain tileset

Combat Dolls 2 terrain tileset.

Combat Dolls 2 scenery tileset

An example of Combat Dolls 2 scenery tileset.

Combat Dolls 2 scenery tileset mask

An example of Combat Dolls 2 scenery tileset mask.

Desert Vixens 2 terrain tileset

Desert Vixens 2 terrain tileset.

Desert Vixens 2 scenery tileset

An example of Desert Vixens 2 scenery tileset.

Desert Vixens 3 terrain tileset

Desert Vixens 3 terrain tileset.

Desert Vixens 3 scenery tileset

An example of Desert Vixens 3 scenery tileset.

Desert Vixens 3 scenery tileset mask

An example of Desert Vixens 3 scenery tileset mask.

Defining characters

~ Defining characters ~

Desert Vixens 2 maps

~ Desert Vixens 2 maps ~

Desert Vixens 3 maps

~ Desert Vixens 3 maps ~

Tile-based terrains

~ Tile-based terrains ~

Random maps

~ Random maps ~


~ Screenshots ~


~ Algorithms ~

API functions for games

~ API functions for games ~

Source code examples

~ Source code examples ~

Return To Index

Privacy Policy