Q: Could you introduce the Dawn 2 project to our readers?

Søren: Dawn 2 is a Real Time Strategy (RTS) game, multiplayer only, of clans figthing over the resources on a tattered Earth. These clans usually live underground due to their susceptibility to sunlight, and comes out at dawn, when the shadows are still long. It's a diploma thesis for both of us, and is as such an attempt to do a game in a genre that hasn't really been done in flash before, not real time anyway.

Q: How much time did it take to develop the game and how many people worked on it?

Søren: A little under a year, on and off, but the biggest part of the game was done in the last six months. I did the concept and the design and Benjamin did the programming. Three other people are also contributing to the project: Andreas for sound/music, Florian for linux server setup/maintenance and Jan for an alpha testing questionnaire.

Q: Is Dawn 2 free to play?

Søren: Yep, it's as free as can be.

Q: When are you going to launch the game?

Søren: Heh... When we're ready! In august/september I guess, but it depends on how many changes we decide to make when the alpha tesing (going on as I write) is done. There're some small things we still need to implement, and these things, small as they might be, have a habit of taking a bit longer than expected. :-/

Editor's note:
At the time of publishing this interview the alpha testing phase is already started and you can play the game at this url:

www.dawn2.com/alpha
user: dawn
pass: alpha

Q: What are the games that influenced you the most for this project?

Søren: Modern RTS'es aside, Julian Gollop's Laser Squad (nice turn based game with small squads), Games Workshop's Warhammer 40k and the late Westwood Studios's Dune 2 (RTS with dangerous terrain, nice feel). This game is hard to compare with games like Warcraft or Dawn of War (we didn't rip the name from that game, it just so happens that a few games with the word Dawn in them came out while we were developing this one) – everything in flash has to be so small and slow, so we had to look elsewhere for inspiration.

Q: The graphics looks great and have lots of details. How did you work on it and what tools did you use?

Søren: Thank you! Most everything is pre-rendered 3d, heavily edited and composited afterwards. I used Softimage XSI for the 3d part, mostly because I'm well acquainted with that app, and my school have it ;-) I rendered most things with multiple passes and composited them together in Photoshop, often with hand-drawn stuff and photos as well – 3d often has a way of becoming too clean, and I wanted to dirty it up a little... For the main colouring of the game, a lot of that is done real time in flash using the ColorObject – the colouring changes throughout the game, and this was the only sane way of achieving that.

Q: What bitmap format did you use for the images? Which one do you recommend?

Søren: Mostly png's. The nice thing with png's in flash is that you can use jpg compression on them. With 1500+ bitmaps in the game, compression becomes very important! The alpha channel doesn't compress so well though. Using gif with a 1-bit alpha channel would have halved the game size – I just couldn't live with those jagged gif-edges for this project.

Q: What were the main influences for the game graphics?

Søren: Illustrations from old story books, art nouveau style graphics (Alfons Mucha, for example) with a thrashy edge to it. Like, a late modern take on romanticism. I was quite influenced by the paintings of, for instance, Waterhouse and Turner, too. I didn't want it to look too much like the other RTS'es out there, but with the orthogonal god-perspective that's hard. It was quite fun at least to try and make it look a little different, although I think it first and foremost looks like an RTS...

Q: Let's talk about the gameplay. What are the main characteristics of Dawn 2?

Søren: It's a classic RTS in the ways of Command & Conquer and such, just smaller and simpler. It is not solely about annihilation, though. The primary goal is to gain control of all the Energy Cells on the map. These cells produce energy that you use to buy units, which are also ordered from the cells. We had to limit the number of builings, units etc. for performance and download size.

Nearly everything that constitutes an RTS is still there: Artillery, close combat units, fortified buildings... Just not base building. As this game has a time limit, spending a lot of time builing a base just makes no sense. The special thing is the color and shadow engine. You play as the sun comes up, the shadows shorten, and the sunlight becomes increasingly dangerous to stand in. The shadows can then be used as a tactical tool: Units are harder to hit and recover from damage while standing there. We tried to make the graphic elements in the game world useful and meaningful from a gameplay perspective, not just eye candy.

Q: What are the basic requirements for playing the game? (cpu, network etc...)

Søren: The game can be played on a 1 GHz Intel with 256 MB RAM and a 256 Kb/s connection. The scrolling will be quite jerky, though, and we recommend a computer with specs twise as good. Scrolling a large map in flash while a lot of units are walking around is just heavy!

Q: Did you use Actionscript 2 for this project? If so what advantages did you find over AS 1 ?

Benjamin: We used Actionscript 2 for Dawn 2. Even though Actionscript 2 compiles to Actionscript 1 and then to Bytecode I think that I would have been not able to develop Dawn 2 without Actionscript 2. Actionscript 2 and a clear oop structure helps me tremendously to keep my coding structure clear and to keep an overview of the various elements.

Q: Do you use an external editor for Actionscript? Which one would you recommend?

Benjamin: At the time we started this project (nearly one year ago) Primalscript was the one I liked most. So that is the editor we still use for editing our Actionscript files. I think it’s a great editor with lots of cool stuff. I tried to move the project over to the famous eclipse combos like FAME, FAMES, etc. (http://osflash.org) but with no luck. If I had to recommend a code editor I would for sure go for these environments.

Q: What were the main difficulties you had to overcome in developing the game?

Benjamin: Coding wise, the biggest problem was to find a structure that works. There are so many different elements in an RTS game which have to communicate with and depend on each other.

As this is my first RTS game (actually this is my first serious game), I had to read through some books about game programming in general (e.g. "Windows game programming Gurus“) and about RTS games in special (e.g. "Real time strategy game Programming") to get a grasp of how the pro's do it.

These books were all written for c/c++ programmers so even though I am able to read and understand the source code I am not able to just port it over to Actionscript because that’s a whole different story.

But what makes these books so valuable even for Actionscript coders is the overall idea of game programming.

Once I had a clear picture of the various elements of an RTS game and how they interact with each other in mind I had to dig deeper into some of them, for example artificial intelligence (finite state machines, path finding) and networking. So in addition to my books I also read through a lot of online articles at that time.

After that I began to port my ideas to an Actionscript friendly environment and drew some diagrams. Some of these diagrams described the structure of the whole game, some of them were more specific and class diagram like (e.g. the units logic, see the last picture above).

This whole research phase took nearly 3 months. After that I could finally get myself into coding. ;)

So as you see the biggest problem was to get an idea of what I want to do and how to do it. If you are an experienced Actionscript developer it's not that hard to write a lot of Actionscript code to make things work. It’s more about getting the idea behind.

Q: Did you develop special tools for creating maps or debugging?

Benjamin: We do not have the need to develop a tool for creating maps yet.
For debugging we actually have a tool in place which gives us in depth info about various aspects of the game. The aspects of the game we can monitor in our debug tool at runtime are:

• grid (show paths of units, show waypoints for path finding engine, show depth grid, show occupied, free tiles)
• units (the unit’s ai reports every single state of every unit to that window)
• projectiles (various info about generated projectiles like damage, source of projectile, damaged units etc...)
• structures (info about entering / leaving structures or taking over energy cells, possibility to show the underlying structure grid)
• shadows (shows which unit is at which time how much in shadow, info about the shortening of shadows)
• network (shows info about incoming xml packages)
• sound (shows which sounds get played on which channel at a given time)
• server (shows info about server load and memory usage)

Q: Talking about the multiplayer side of the game, how did you develop the game logic? Is it on the server side?

Benjamin: The game logic is on the client side. This gives us some advantages and some disadvantages.
Advantages, Client side:

• faster response times (e.g. when you order a unit to move somewhere it goes there immediately)
• no server side coding required
• faster development cycle as I am an advanced Actionscript coder but a beginner c/c++, java coder.

Disadvantages, Client side:

• it's insecure
• synchronisation of both clients is hard to achieve (and there is a very slight possibility of < 0.2% that things look different)
• client has to take care of all CPU intensive calculations (e.g. path finding, line of sight algorithms, etc.)

The main reason for developing the game logic client side was the faster development cycle and the fact that we were able to achieve a synchronisation of both clients.

With our chosen model and implementation there is no 100% guarantee that the game behaves the same on both clients, but I guess the possibility is somewhere around 99.8%. That’s good enough for now.

Q: Did you use any particular "tricks" in your multiplayer code to allow smoother interaction? If so, could you describe some of them?

Benjamin: Well, no tricks at all. It has more to do with which things need to be the same on both clients and which do not.

For example it’s not absolutely necessary that all units are at the same places at a given time, but it is very important that events like taking damage, overtaking structures and dying is the same on both clients.

So, if you have a high network lag, things might look strange to you. A unit might take damage by your opponents unit which is on your screen not even close to it. In a scenario like that the faster client (smaller lag) is always right.

But that is nearly the same if you play any commercial multiuser first person shooter. If you have a high lag your movement will become very slow and you will not be able to defend yourself or attack properly.

Q: Developing a multiplayer game is quite a long work. What would you suggest to developers willing to create their first mp game?

Benjamin: Start small! The first prototype of dawn2 started two and a half years ago. It was done with a self deployed java socket server which consisted of 2 java classes. Play around with some of these free socket servers to get used to it.

Søren: Same here. There's so much production work, so starting off simple gives you more time to worry about the concept, and not whether or not you are going to get those thousands of pics done in time.

Q: Can you tell us about your future game related projects?

Benjamin: No idea yet, we’ll see.

Søren: We'll see. Probably something strange.

Q: The new Flash IDE and Flash player are awaited in a few months. What do you expect from this new release?

Benjamin: I’m not interested in the new IDE, the old one works well for me as a developer. I actually hope I can get rid of the IDE at some time ;).

But there are some things I expect from the new flash player:

• faster code execution
• faster graphics rendering
• load a swf/image into a movieclip and being able to dynamically attach or duplicate that

Søren: Everything should just be faster! Since flash is so slow, you spend a lot of time making workarounds, which is really silly. Other than that:

• finally, different blending modes (I hope they are as fast as in Director)
• a timeline and layers that are easier to manipulate.
• variable framerate (that'll be the day; one can only hope)