H. Hernan Moraldo - personal archive
home about faq contact website

Edia Postmortem

Dated: October 2001

Article by H. Hernán Moraldo
Published first in my site, later in Pixelate #7



Escape del Imperio André (EDIA) postmortem developer's document

EDIA Postmortem



Introduction



This postmortem article is about a small fun game I developed in late 1999, called EDIA ("Escape del Imperio André" in its original Spanish version). It's mostly targeted to game developers who like reading other people's experiences and points of view on the subject.

In this article I've included all I'd like to know about EDIA's story and design if I wasn't its creator. It means you will find here:

  • A small description of the game for those who haven't played it yet.
  • The entire story of the game: how the development time was, what happened after I did it, and some almost unknown details (EDIA's comic!!!).
  • A very big technical explanation on the game design, describing how every aspect of it works and why it does that way, focusing specially in the design and the abstract code organization. That's the biggest part of the article, and probably the most interesting one both for game developers, and also for newbies trying to find out how games are developed.
  • More details about EDIA than the ones you could otherwise ever know! The original drawings that became sprites and splash screens, the meaning of the Spanish voices, and some pieces of my own story as software developer (very related to the game itself).

I don't know about you, but at least I (as a game developer) would love to read articles speaking so widely about games that have already been developed. I hope you like this one as well.

It's just my little contribution to the game development scene...

Enjoy!



A few words about EDIA



For those of you who haven't played the game yet, here comes a quick description of the game:

EDIA is a freeware game I did in late 1999. It's a 2d side scrolling arcade, with a graphic resolution of 320 x 240 x 8 bpp (Mode X), with sound capabilities (only for Sound Blaster™ compatible sound cards) and working under DOS™ protected mode (that is, working perfectly under Windows™ too... if it crashes you will have to execute it with disabled sound, by calling "ESCAPE NOSOUND"). The game is completely in English, though the voices remain being the original Spanish ones.

You control a little brown ship that's flying over the desert while a lot of alien ships and monsters do their best trying to beat you down. Your keys are the arrow ones, and Control for shooting.

The game basically is about hitting as much enemies as possible, while not losing lives and going through the different levels.

The idea is very simple, but it's a lot of fun (IMO, at least).

To end this little description, I've included the following two screenshots:



Game story: the development time



The game development

EDIA's development started in August 1999.

At that time, I was a 16 years old Argentinian programmer, and already had about 4-5 years of experience in programming and game development. However, I was totally unknown in the game development scene, because of my total absence in all the Internet related social activities (something that has drastically changed since then), and the games I developed used to be spread between a few people, mostly friends.

I started EDIA as a little experiment with my back then recently programmed PCX routines for DJGPP™, but as soon as I saw how cool it was coming, I decided to make of it my next game. I thought an entire story for the characters (that was the one I used for the comic, later), and decided the main game rules. After that, I started the programming, always trying to keep the code design as professional as possible (in fact, code organization was my highest priority there).

Apart of the programming work, I also did the sound and the graphics. Voices were my own voice, though extremely modified with the help of editors and other sound tools, to make them sound funny. Sprites and splash screens were mostly scanned drawings, lately edited with pixel by pixel graphic utilities, with a few exceptions that needed more powerful tools, like Photoshop™.

The game was completed in October 1999.

After that, I showed the game to the usual people (a very small group), and thought in making a website where to publish it, together with its source code. The website was up for a few time, and I cancelled it soon.

Right after that, I started to work, by the second time, in a commercial programming project that had already kept me busy for about a year until then (I started serious commercial software development when really young, as you'll see), and that kept me busy for about another year after EDIA.

For that, and a few other reasons, I didn't ever actually release the game at all, say through a massive media as Internet (that old website doesn't count here). It was that way, until in October 2001 I decided I was going to release the game, for the first real time. It happened almost two exact years after the game's completion.

As the original game was all in Spanish, I translated it to English (not the voices, for being so cool in its original language), remade the first two splash screens, and updated most of the texts, like the credits (adding some important thanks). Once I did it, uploaded the modified binary to my site, so making it public for the first time in two years.

Meanwhile, I started working in this postmortem, with the intention of making this old project useful for other game developers, and not to let it fall in the oblivion. Some time after that, I finally published it.

This article will probably be the end of EDIA's story, as I'm going to focus in new projects from now on. But who knows, maybe something new about this old game surprises us in the future.



The comic

One of the least known facts about EDIA is that it was a comic, too. And despite it was an only issue, I couldn't omit this point of the story if I wanted this document to be complete.

To be honest, I don't remember exactly what drove me to make a comic with EDIA's story. Maybe it was just that I had that big story in my head and wanted to do something with it, not just a game. And, with a background of informal drawer and writer, making a comic was surely the best idea I could have think of.

EDIA's comic, originally called "Invasión del Imperio André", was supposed to be a large comic divided in more or less five different issues, telling the fictional story the game was based on. However, the only issue that came published was the first, and after that one the story got interrupted (though the second issue was almost ready).

The first issue was a 12 pages magazine, with a page size similar to the used in comic books, though a bit smaller, in black and white, and with all the artwork and scripting done by me. It was a very limited edition (20 impressions!), as it was going to be reimpressed for a larger amount of readers as a single big comic book, together with the following issues, as soon as the entire story was ended.

It was published more or less at the same time I completed the game (in October 1999), and happily people used to like it (but please don't ask me for copies, I won't give out any more). Its readers / proofreaders were mostly members of the argentinian comic scene, a small few (mostly because of the mega-limited edition / distribution). No more people have read it since then.

At the time I interrupted the comic, I had all the argument assembled in my head. Right now I've forgotten some details, but it was more or less this way:

The story starts with a guy called Guillermo Marco discovering his next neighbour, Raúl (actually named Esp), was an alien. He always suspected it (as Esp had a slightly green skin, and used to call people "terrestrial") but now he confirmed it all when finding Esp flying in the middle of a room.

Esp couldn't let people knowing his condition, so he took Guillermo Marco with him, and sent the unlucky human in a small green ship to the terrestrial base of the alien empire he belonged to, André Empire.

There they spoke with a lot of people, found friends and enemies, and even met the emperor itself, called André (doesn't appear in the game at all).

There the first issue ended, but the story continued with a lot of events happening all the time. In summary, it told the story of a man in an alien base populated by the members of an extraterrestrial empire wanting to conquest Earth. It also was supposed to tell way that guy escaped from the alien base.

The game was in fact one of the latest scenes in the story, when Guillermo Marco was trying to get away from the empire, back to his city to alert the military center of his country (Argentina) about the situation. But it wasn't a peaceful escape: thousands of enemy ships tryied to stop him, finally having Marco's ship destroyed and falling.

I don't remember what was going to happen then (ok, Marco was going to survive and the empire was going to fall, but how?), but that was more or less the ending.



Game design description



This section will describe how the entire game was designed, showing the exact way everything was done. It will be with no doubt the more interesting part of this article for the game developers.

By the way, the entire game was programmed by me, in C++ with the DJGPP™ compiler, without using any external libraries. However, there was a file (DMA.cc) that was heavily based in a Stu Hull's original code.



Developer's document vs. source code

(Despite what is said in this article, I released the entire source code of EDIA in 2003. You can download it from the web too.)

People will surely wonder why I wrote such a detailed developer's document, while not releasing the real game source code. In other words, if I wanted to show people the way EDIA worked, wouldn't the original source code be totally more descriptive than any other kind of document? Wouldn't code be more effective for that?

I don't think so, about EDIA at least.

EDIA's technical strength aren't the algorithms (in fact they all are quite simple) but, for me, its structure, the code organization and game design. That is, the abstract concept behind the real code, things that are hardly appreciated in the real code.

The idea behind this part of the article is to share that more theoretical aspect of the game, without having us to bother with the implementation low level details.

I'm sure different programmers would have made the same exact game in a total different way, and it's always interesting for us to find what are the differences in our organizational styles. That's why I think this part of the article will be interesting for game developers, because this way we'll have a chance to share our thoughts about the software design (in no way I'm trying to teach other experienced developers how to make games, that's for sure).

But I'll rather stop speaking, and let the fun begin!

(By the way, the original source code is completly in Spanish, both the comments and the identificators... I don't think it will be useful at all to non Spanish speakers without a previous translation. Now I've learnt the lesson, and just code in English, for the sake of internationalization...)



The design document

It seems that to speak about the design document is a very usual way to start postmortems, but EDIA had no formal design document. I just had the main idea in my head, and developed the entire game based on it, with a very big flexibility though.

For this reason, the main historic development document is now the source code itself. I know there were a few papers I wrote detailing the future code organization, though very informally and more as a way to organize myself than as as a reminder. Anyway, I think I've lost them all.

Apart of the source code, all I still have from the game's development time is: the original drawings for the comic (and some other stuff related to it), the original scanned drawings that were used, later, for the sprites and the splash screens, and the developer diary I kept in one of the source files. And maybe some other things I haven't seen for a while.

For the technical explanation that follows, the most important consult material was the source code. It had enough information about the design, functionality and development time as to write a book. But with this article will be enough, I hope.



The files

EDIA's source code was divided in the following 9 files:

  • GraficX.cc: graphic wrapper for Mode X. 200 source lines of code (SLOC).
  • Speed1.cc: for calculating the FPS, and whether it's time or not to draw the current frame at screen. 170 SLOC.
  • Teclado.cc: keyboard wrapper. 80 SLOC.
  • Dma.cc: for sound (heavily based in a Stu Hull's original code, I can't even consider it as mine). 600 SLOC.
  • Efectos1.cc: group of functions to do the simple graphic effects between splash screens and the game itself. 230 SLOC.
  • Letras.cc: a module for drawing characters and text in the screen under graphic mode. 340 SLOC, including the character definition (260 SLOC).
  • PCX.cc: for loading the PCX files. 240 SLOC.
  • Sprites.cc: used for blitting memory data (sprites) to the screen. 300 SLOC (including old routines unused in EDIA).
  • Naves1.cc: the game source code. Everything else were wrappers, and other general modules with common code, but this one contained the real game code. Nearly 3000 SLOC.

In earlier versions of the program there were other extra source files, like stars.cc, used to draw little moving dots in the game field, simulating stars, or equivalent files to GraficX.cc but working in other resolutions. All of them can still be activated by uncommenting an undef, but as soon as the final release doesn't include them I didn't do it either.

In the list above, the SLOC values aren't exact, and include comments and blank lines (but don't include big comment blocks, as the development diary in Naves1.cc). Totally, there were more or less 5080 source lines, where almost half that number was the codebase, and the bigger half was the real game code.

For the purpose of this article, I consider Naves1.cc the game code, and all the other files are external code forming what I'll call subsystems here: low / middle level wrappers for Graphics, User Interaction, Sound and Time. We'll speak about the way those subsystems were managed in the next section.



A few words about the subsystems

I'll give a very brief description of the subsystems here, to let us focus in the game code later.

  • Sound subsystem:
It's the file DMA.cc, that was heavily based in an original source code from Stu Hull (from his famous GCC Faq v. 1.0).
It was basically a set of functions to work with the SoundBlaster, and a class to load the WAV files, and to play them using the SB. Back then, I couldn't have done it without that cool document of Stu Hull.
  • User interaction subsystem:
It's the file Teclado.cc, that just contains a little class allowing me to access the keyboard easily.
  • Time subsystem:
This one (file Speed1.cc) was designed to control the current frame rate. That is, to keep the game speed being always the same even in machines with different capabilities.
It's based in the idea that most of the microprocessor's time happens when drawing the images to the screen (what's true in most of the cases, unless you have very heavy physics, AI or something). For example, to make the game go faster in slow machines, it's enough to skip the drawing of some frames to the screen. In fast machines, you can also slow the game down just by keeping idle some time between frames.
If you do that through exact calculations done runtime, you can get the game running always at the same speed, independently of the machine speed. This subsystem was the one managing those calculations, so controlling the real game speed.
It would be very long to explain (though the concept is really simple), and my intention here is not to explain every technique used in the game, but to focus in more design related discussions.
One interesting point here is that, when developing the game, I had to select a base frame rate in which to base all the future calculations. That value was going to be also the maximum frame rate possible in the game (as faster ones were going to be slowed).
And the interesting point is that, for some real weird reason, I chose a very low FPS base amount: 18 frames per second! For that reason, the game runs always at 18 FPS (even if the machine is able to reach higher frame rates). And as I selected all the speed values of the objects according to this value, now it would be somewhat hard to change it without completely changing the game's nature.
  • Graphic subsystem:
It was with no doubt the longer subsystem (files GraphicX.cc, PCX.cc, Efectos1.cc, Sprites.cc and Letras.cc), and it had basically the following features:
  • Functions to manage Mode X, the palette, and to do blittings (files ModeX.cc, PCX.cc and Sprites.cc).
  • The ability to load bitmaps from PCX files, and from an ASCII simple graphic format too, though the latest one wasn't used in EDIA (files PCX.cc and Sprites.cc).
  • Functions to animate simple effects when changing between screens, like fade offs (in Efectos.cc).
  • Functions to work with characters in the screen, using a special font (in Letras.cc).
This subsystem had a real problem with optimization, some functions (like the blitting ones) were extremely slow. At that time I didn't know how to improve it, but now I know enough about optimization as to see that some loops were unnecessarily big. It's always surprising to me that the game runs ok even with such a slow code in the most time critical parts.

As you have probably seen, no one of the subsystem's exclusive code had too much secrets. It was just a codebase, that even despite its simplicity was indispensable for the game work.

If I were being more strict in the definition of subsystem, I should include pieces of Naves1.cc as part of the Sound, Graphic, and User Interaction subsytems. However, I'm rather considering here as subsystems the lowest level part of every real subsystem. For example, the high level graphic engine is actually working in Naves1.cc, where it has more interaction with the game code: that doesn't count for us as part of the Graphic subsystem, though.

Now we've spoken about the subsystems, it's time for the real fun part. Let's go to see the game's main code!



Game's main structure:

EDIA's main code was placed all inside Naves1.cc (ok, I should have divided it a bit more, but now it's late). It made all the real work, while using the four subsystems mentioned earlier in a more accessory way. Or, to say it in other way, Naves1.cc coordinated subsystems' work to get the appropriate result.

From a very wide point of view, all the program did was to execute the following sequence of steps:

  1. Initialize the data, load some of the files (bitmaps, sounds), while keeping other to be loaded at runtime.
  2. Show the initial presentation.
  3. Show the menus, and the main "Escape del Imperio André" splash screen. Go to step 4 only when the user selects to play, go to step 6 if he selects to exit the game.
  4. Play a current game. When it's lost, go back to step 3. If it's won, go to the step 5.
  5. Show the winning screens. Go back to the step 3 when done.
  6. Exit the game.

This big level of abstraction lets us see a very simple coding structure. Of course, most of the code is part of our step 4, the real game code. The other ones are a lot simpler, just showing splash screens and using character functions to make the menus work.

So, from now on we'll speak about what happens during the step 4, that's also the most interesting one: the so called Game Loop.



The game loop:

We could write, basically, EDIA's game loop as:

  1. Game initialization (set all the game variables in their initial value, and some other stuff).
  2. (Here starts the game loop.)
  3. Look at the keyboard (User interaction subsystem). If a system key was pressed (for example, the T key that shows the cheats menu), act accordingly. Otherwise, it's a game's key. Look at whether it's possible or not to do what user wanted to do, and do it (for example, the main character can't continue moving up once it's reached the upper side of the game screen, or if he's dead and is just falling down).
  4. Move non-player characters, and objects. Add new objects if necessary. Look for collisions while doing it, and if a collision happened, act accordingly. When it's needed, start the execution of a new sound (Sound subsystem). The sound will continue being played in the background, with no further intervention from the main program.
  5. Make time calculations, see whether it's time to draw a new frame on the screen (Time subsystem). If it's time, update the entire screen with the current frame's information (Graphic subsystem). It includes drawing the background, the sprites, the title bars, messages between levels, etc.
  6. If game isn't over, and player didn't try to go out it, go back to the step 2. Otherwise, exit the game loop.

Again, the loop itself is very simple, and easy to understand. In the real game code it looked a lot more complex, but the main idea it was designed around was, exactly, what I wrote above.

Note the way steps 3, 4 and 5 are strongly divided. That was one of the most important design objectives in EDIA: to separate as much as possible the subsystems work of the game code. This way, I obtained a code in which all the graphic stuff had almost no relation with the game physics and AI (what's logic), the same with the keyboard, the time (that was very related to the Graphic subsystem), and the sound (that even when it's placed at the step 3, the game calculations, it was restricted to a few functions).

It made changes in the interface, or in the game itself, very easy to do, so simplifying a lot the development.



Data organization:

Until now we've spoken about code organization, now it's time to speak about the data organization in EDIA. That is, how the different game objects were stored in memory, and how they were managed too.

Looking at the game code, we find the following big data objects used to store the current game state (all of them done through C++ classes or structures):

  • Nivel1Nav: It stores information about the general game state, including score, current level number, and some extra details needed for the background movement (we'll speak about that later).
  • NaveProtag1: This class stores information about the current player state, as the number of lives left, the weapon in use (we'll speak about the weapons later) and some other variables used for the animation / blitting, together with a set of methods to manage the player object.
  • Disparos1: It's a fixed size vector of a struct that stores the relevant data of every bullet in the screen, including speed, current position and kind (there are many kinds of bullets).
  • Malos1: Very similarly to the one before, it's a fixed size vector of a struct that stores the relevant data of every enemy in the screen, including speed, current position, kind (there are many kinds of enemies), and a flag saying whether it's dead or not.

We'll discuss the way those data objects are used more in detail in the next sections.



The moving background:

Ok, I'll admit it: EDIA uses a fake background.

I'm meaning, it's just a moving bitmap that has no relation at all with the real game mechanics (unlike other 2d games as the old Pacman™, where you could even interact with the background). Say it's only an aesthetic detail: it can be easily deactivated without having the game rules changed at all.

There are no more secrets about this aspect of the game. That moving background is just a bitmap somewhat wider than the screen, that moves wrapping itself, at a velocity that varies according to the current level. The data used to make it work was stored in the structure Nivel1Nav we mentioned before.

The bitmap itself is shown below:

(If your browser isn't showing you an image there, just click here to see it)



The enemies:

A fixed size vector named Malos1 contains the current status of every enemy in the screen. Of course, as the amount of enemies in screen at every instant isn't fixed (and it fact it varies a lot during the game), every "node" in the vector contains a flag meaning whether it's storing the data of a real enemy on screen or not (say it's idle). In other words, a static data type (the vector) is used as a dynamic one (linked list), for preventing memory leaks related to the way OSes handle memory.

Enemies are added to the list all the time, generally with semi random coordinates that go to the right side of the screen. Every time an enemy goes out the screen, so that the player can't see it anymore, it's deleted from the list.

Enemy data includes an integer saying what class of object it is, that will define it's appearance and behaviour. EDIA features the following six classes of enemy:

Enemies AI is very simple, almost prehistoric (move forward, shoot with a defined persistence, in some cases try to go the same elevation the player is, etc). However, it doesn't affect the entertaining, in fact the game is really difficult even with dumb enemies, as what cares in EDIA aren't the isolated enemies but the patterns they do.

In conclussion, every time enemies have to be "moved", the program goes through the entire enemy list, and for every activated node, it executes the AI code for the unit. Unit movement can be a change in the coordinates, or a shoot (done by adding a bullet in the bullets vector, explained in the next section).



Weapons and bullets:

Bullets are managed the same way enemies are. There is a fixed size vector (Disparos1) used as if it was dynamic, it stores the necessary data for every bullet on screen (including the player ones). The individual data includes the coordinates, velocity, and bullet class.

There are three bullet classes in the game, that can be seen in the following screenshot (one shot by the player, the other two by the enemy):

There is also an extra bullet class that's the one used for the sinusoidal weapon of the player (because it's moved in a different way). However, it has the same appearance that the common one.

When somebody shoots (being it an enemy ship, or the player), the program adds a bullet in the vector, originally placed at the position next to the ship that's shooting it, and with the appropriate velocity and angle (here determined by two variables, speedX and speedY) for the ship that's shooting it (also considering the current weapon, if it's coming from the player).

The player has 4 different weapons, they are:

  • Single shot:
That's the simpler weapon, and the one the player uses in almost all the levels. Every time this weapon is selected and the player has the shoot key pressed, a bullet is added to the list, with a fixed horizontal speed.
  • Double shot:
That's other very simple weapon. It's identical to the single shot, with the only difference that every shooting frame two bullets are added, instead of just one. Both bullets are, then, independent.
Though its simplicity, this weapon is IMO the most useful one. However, in the game you can't choose which one to use (it depends on the level).
  • Triple diagonal shot:
It's like the double shot, but with three bullets, one with a fixed horizontal speed and the other two with the same speed for X and for Y (so obtaining a diagonal displacement).
Though it can seem useful at first, it's in fact a very problematic weapon, because when it shoots to the ships above you, they die (or whatever is supposed to happen to a ship when it's hit by a bullet) and fall against your ship, so dropping you lives.
  • Sinusoidal shot:
This weapon releases a special kind of bullets, whose movement follows a sinusoidal curve. It works in the same way the single shot does, but the Y position isn't fixed but a value dependant on the current X position of the bullet (calculated with the sine mathematical function).
It's useful in some cases, but most of the times this weapon makes the targeting more difficult.

Those were the player's weapons. Enemy ones are very simple and alike, they all work in a way similar to the way Single shot works in the player.



The collision detection:

The collision detection mechanism was oversimplified on this game, more as a way to make things easier to the player (by letting him do some things he could be not allowed to).

The right way to do collision detection with two rectangles (let's call us A and B) is by seeing whether they minimally overlap or not. In other words, if those two rectangles have an only point as the intersection of both, it should be considered a collision, because they are overlapping (even if the shared zone is very small).

In EDIA, I used a different method, which decides that A and B have had a collision only if the the center point of A is inside B. It gives us a few chances of not being considered collisioning when having a very small shared zone.

When the collision detection is used with the bullets, we take the center of the bullets and see whether it's inside the sprites area or not. When looking for collisions between the player and the enemies, we use the center of the enemies to see if it's inside the player sprite area. When the enemies are big enough, like the green aliens with tentacles, it gives the player a few more chances over the enemy. For example: you can touch the tentacles of one of those aliens without being hit at all.



Score, levels and difficulty:

Score in EDIA is managed the following way: Every time a player's bullet hits an enemy (even if it's death and falling), the score is increased in a value that's different for every enemy kind, and the bullet is deleted from its vector. Also, every time the player hits an enemy with his own ship (so losing a life), the score is increased by the same value. That value is, for example, 10 for the green ships, 50 for the blue shooting ships and so on. The values range is 10 - 100.

EDIA has 16 levels. Every time a new level begins, a message appears and a laugh can be heard. Levels start when the player reaches some fixed score values. For example, the first level goes from the score 0 to the score 200, if the player gets, say, a score of 220 during the game, it advances to the second level (the first level can be passed in very few seconds).

I don't want to kill the fun by saying the value for every level in the game, but I'll say what's the score for the game's ending: 180000.

About the difficulty level, well, I think it's very hard, even for me. When I was developing the game, I tried to make EDIA as difficult as I could, while keeping the chance to beat it by myself (without cheating, that is). When I got this, I added the game a little extra difficulty and voilá! The game reached the point in which even I, the creator, couldn't beat it without cheating.

However, it isn't impossible to beat it. I'm not a hardcore gamer, so what is difficult for me can be easy for you.

And anyway, more or less two years after completing the game, I made a gaming marathon against my brother to see who was going to be the first person in the world to beat the game. I did it and, a few after me, my brother beat it too. So it's perfectly possible.

But could you beat the game?



Bitmap files:

All the bitmaps used in the game are stored as .hhm files in the PCX file format, always using the same palette, and in 256 colors. (Want to make a mod of the game? It's possible! If you are going to do it, contact me and I'll try to help you with the task)

One of the most interesting things I still have from the development time of the game, are the original scanned drawings that became sprites and splash screens. It's very curious to see how did those drawings evolution until being the game bitmaps.

Here there are the most interesting drawings that were used for the sprites (some of them, as the big white ship, weren't used for the final sprites really, as those sprites were done pixel by pixel, in those cases the initial drawings were just used for the enemy design):

Note that the latest two don't appear in the game at all (I decided not to add them), and that there are some whose initial drawings were extremately detailed, and whose details were all lost in the final sprite (for example, look at the flying guy with a green shirt... I even drew him eyes!).

And here you have the first splash screen, how it used to be during early development:

The latest drawings here, a pair I drew when working in sprites and all the graphic part of the game. As you see, a lot of drawings weren't used at all in the game, but were inspiring. The first is the one I used for the current splash screen of EDIA:



Sound files:

There are 8 sounds in the game (the .kkf files, that are stored in the Wav format), of which five are voices speaking in Spanish, that weren't translated for historic reasons. Here follows a transcription of them, explaining the English meaning of every one:

  • At the beginning, before the main menu: "Producciones Hernán Moraldo presenta" ("Hernán Moraldo productions presents").
  • In the main menu: "Escape del Imperio André" (the game title, "Escape from the André Empire").
  • When entering to the Cheats menu: "Trucos" ("Cheats").
  • Every time you are hit by an enemy: "Cretino, eso me dolió" (I haven't found any exact translation, but it means, more or less, "Hey, that hurted!").
  • Every time you die definitely: "Oh, he de morir así, solo y abandonado en el medio del desierto?" ("Oh, have I to die this way, alone and abandoned in the middle of the desert?").

All the voices were mine, though edited as to make them sound funny (my real voice doesn't sound that weird, by the way).



General game mechanics:

As a summary, we can say the game works the following way:

There are three basic groups of objects: the player's ship, the enemies, and the bullets. The game happens as a interrelation between those three. Enemies are automatically added all the time by the program, and they move according to some very simple AI. The player is always in the screen, and it moves according to what the program senses in the keyboard. Bullets are added by the player or by the computer, depending on who's shooting, and they move following simple functions.

Enemies can't interact between them, but some enemy's bullets can kill other enemy ships. Also, both player's ship and player's bullets kill the enemies with a single hit.

Enemy bullets and enemy ships both decrease the lives counter of the player every time they hit him (by hitting I mean a collision happening). If the lives counter reaches zero, the player dies and the game is lost, unless a very exceptional case happens (discover it by yourself).

Enemies are deleted as soon as they stop being visible. Bullets are deleted as soon as they stop being visible, or if they hit something that can be hitted by that class of bullet (for example, player's bullets can hit the player himself).

Every time the player hits an enemy, with his bullets or with the ship itself, the score is increased. Every time the score reaches some fixed values, a new level begins.

Levels define what enemies will appear in the screen, and with what properties (position, velocity, etc). Reaching the 16th level means the player has won the game.

While it all happens, the background is moved around without affecting the game at all.

So those are the general game rules. We've seen the details above in this text.



Developer's conclussion:

It's always interesting to ask developers what they think about their own works, once they are completed. Now it's time for me to answer that question, about EDIA.

I love EDIA, it's my little son. I have fun playing it, even though I know it has no secrets for me, that I have nothing to discover there.

However, it's been two years (at 2001) since I did the game, and now it seems very outdated for me. As time passed, I've learnt a lot about software development and, more specifically, about games development. And now, sometimes that old code seems silly for me, as I can find lack of optimization and better organization everywhere. But it works perfectly (doesn't seem to have important bugs anywhere), and I'm really proud of it, anyway.

To be honest, the only things I currently regret from the development time have nothing to do with the code itself, but with the gaming experience. I always thought it could have been a lot more fun if I would have extended the development time just one or two weeks. In that little extra time, I would have added at least 5 weapons more, maybe 10 enemies and probably some different backgrounds, sounds, maybe big bosses too, all with the intention of extending the gameplay time.

But the game is completed, and despite I feel really tempted to add features to it now, two years have passed and that's enough time as to declare a project ended, for ever. Now I have more knowledge and experience, surely, but it's not here to be used in EDIA.

It's to be used in future projects. I mean, it's time to look forward, and continue walking.



End of file



So that's been all. I have to admit I have really enjoyed writing this postmortem, even though it's so madly big in size. But writing it has made me remember a lot of things about EDIA and about the time I developed it, very cool thoughts came to my head all the time. And I also know this article will avoid me forgetting the way it all happened. Time is evil, but now I have a weapon against it.

Anyway, I hope you enjoyed reading it as much as I enjoyed writing it! That is, a real lot.

If you want to tell me anything about the game, or about this article, just send me a mail, with comments, questions or whatever, and I'll try to reply you as soon as possible. Needless to say I'll love any kind of feedback.

Best regards,

H. Hernán Moraldo



In categories: All English Articles GameDevelopment Personal 2001




Copyright 2000-2008 by Horacio Hernán Moraldo
All rights reserved