Large-Scale Real-Time Strategy (RTS) for the iPad & iPhone 

Twitter LinkedIn YouTube E-mail

Closed Beta Application

Galactic Conflict will soon enter closed beta. We’re looking for passionate RTS fans that are willing to test the game for an extended period of time. A strong RTS background, an iPad 2 or later and the willingness to hook up with other beta testers to get some multiplayer games going are required to enter the beta. You’re expected to provide valuable feedback about the gameplay especially w.r.t. the single player campaign’s difficulty curve and the multiplayer experience with the focus on game balance.

Please read more about the terms & conditions and rules of the beta in the closed beta section.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 

Do you hear the Voices too?

Published on November 5, 2012 in Game Design

I’m happy to announce that the voice acting for the game has taken shape. It’s incredible how much voiceover can add to the immersion of a game and inspire life into the game world.

Not only do the units report back when clicked or ordered to do something (which is pretty standard to provide some kind of latency masquerade), the space ship pilots will also provide feedback about the current combat status or any special achievements.

To illustrate this, let’s say, for example, that a big warship has taken a lot of damage and is about to be destroyed. The ship captain will not just sit there and take it like a man, he’ll voice his situation getting the attention of the player and resulting in a much better immersion.

Likewise, blowing a threatening enemy ship out of existence is worth cheering, isn’t it?
Do you think that the citizens on your planets will just silently endure any prolonged bombardment without calling for help?
You are sending strikecraft into defensive turrets or near enemy flak frigates and they are sustaining heavy losses. The strikecraft leader will not wait for the whole squad getting wiped but call for assistance or alert you to this situation.

Now, I hate it when the units in an RTS keep saying “Yes sir!” a hundred times in a row. That quickly gets annoying. Therefore, I’m having a whopping 500(!) lines included in the game.

Voice acting in games can be dangerous, it’s better to have no voice acting than bad voice acting. However, I can happily announce that the voices in Galactic Conflict are fantastic.

Overall, I’m very happy with the results. It just sounds awesome. Together with all the other cool sound effects, the dynamic music that starts our eerie in times of peace but quickly becomes more driving when there’s more action in the game, with engines humming, weapons firing and ships blowing up the whole sound experience is pretty cool.


To give credit to everybody who’s provided his or her talented voice, here’s the list of the main voice actors (and a few samples):

Voice Actor Role
Chris Escalante Terran space pilot (m)
Michaela Laws Terran space pilot (f)
Warren Reid Pyros space pilot (m)
Kristyn Yearington Pyros space pilot (f)

They all did a fantastic job!

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 

Early Preview Video

Published on October 1, 2012 in Uncategorized

An early preview video of Galactic Conflict is out.

Galactic Conflict Preview from BitmenStudios on Vimeo.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 


Published on September 3, 2012 in Development

Artificial Intelligence. I still remember when the AI gurus were bragging in the 80ies what AI would be able to do ten years from then. Not even a fraction of these visions have become true, not even 30 years later. AI programming is difficult and none of the IT domains have failed more in achieving their own proclaimed goals than they have.

I remember visiting an international robocup a few years ago. This involves robots playing soccer against each other, or to be more accurate, usually totally failing at doing so. Most of the time, they were erring around on the field, or they were experiencing some kind of hardware failure and were out for “medical treatment”.

A particular humiliating situation was when all players of one team were out but the other team still failed to score. I don’t want to question the countless hours the teams from all around the world had put into these robots but from a mere spectator view, it was truly disappointing.

At least it shows that AI programming is hard. Unfortunately, an RTS game involves a lot of AI programming, on various levels. In addition, AI algorithms can be computationally expensive and a mobile device – despite being a small computer – is no desktop PC or console and only has limited resources.

I had already a lot of AI challenges in my last game, Air Force vs Luftwaffe, when it came to the AI opponents. I had to throw several implementations into the bin because they didn’t provide the game experience I wanted.

For implementing the final AI, I was studying flight manoeuvres, like Immelmann, Split S, and such, trying to come up with a good AI. After all, for a game like that the quality of the AI makes the difference between a boring action game and a challenging, entertaining game.

Eventually, the game had like a dozen different manoeuvres to pick from. All airplanes were constantly thinking how to react in their situation, trying to shake enemies or getting a good angle of fire on them. This is what I usually call the Unit AI.

Unit AI

Unit AI means each unit having a small brain and it’s definitely needed in each and every RTS. After all, in an RTS, you don’t really control every single thing of your potentially hundreds of units. They need to be intelligent enough to do some basic decisions while you concentrate on the big picture. So, each unit needs to be aware of its surroundings, pick a suitable target (knowing its strengths), fire at it and generally come with some common sense.

While as a player, you often don’t notice the unit AI, it clearly gets noticeable when it is lacklustering. Nothing is more frustrating than a stupid unit AI where you really have to micro manage every single unit or it would stand there and get shot looking stupid or chase targets it isn’t supposed to go after.

Ontop of it, multiple units must act as a group. If I select a couple of units and issue a move command, then they should not move around like headless chicken and then end up stockpiled ontop of each other but move in formation. This is typically referred to as the steering AI. Pathfinding is another well-known AI challenge. This sounds easier than it actually is and needs some AI brainwork put into the game so units behave in a sensible way.

Some units also have special needs, like strikecraft in my game needs to dogfight other strikecraft. They are not stationary in space but constantly moving, evading enemy fire and hunting down targets on their own. Ships also need to aim and lead, taking enemy ship movement into account. Large ships with multiple weapon mounts must pick different suitable targets. A destroyer will be firing a heavy homing missile at a nearby frigate, working on the ship in front of it with a front-mounted ion beam cannon while trying to take down fighters with a rotating turret. So even the weapon mount points have their own brain!

In addition, unit AI is also a performance factor. The more units on the field, the more valuable CPU time is used up for controlling all these units.

Skirmish AI

Obviously, in a pure multiplayer game, you can get away with just a unit AI implementation. After all, everything else is done by human beings playing against each other. However, if you plan on a single player experience then somebody must take over the opponent – or things tend to be rather boring I’m afraid.

Making a good Skirmish AI is more than a challenge. Actually, if you look at today’s RTS games, they often come with a pretty good opponent but overall, it is pretty apparent that a lot of things are scripted.

I now have come up with a Skirmish AI implementation that makes for a worthy opponent. Sure, RTS veterans will be able to crush it with ease but if you are new to the game or genre, then you are in for a challenge. It uses a multi-layered system with different AI submanagers fighting over the resources. The Military AI’s goal is to come up with a good fleet to counter the enemy. It doesn’t care about the rest. The Construction AI works on buildings and also tries to boost our economy (by building more eco buildings). The Tech AI wants to advance in tech.
All these individual AIs are very one-sided so an overall Strategic AI controls how to distribute the available resources to the sub managers. If we want to be aggressive, then the Military AI gets a lot of resources at its disposal. If, however, it finds out that we are not able to keep up our production, then it will decide to boom, then the Construction AI will be preferred so it can build more metal mines and crystal processors.

The AIs will also flag their needs to each other. The Military AI will request factories to be constructed or request a new supply depot to avoid running out of supply. It may also ask the Tech AI to research new ship types it wants to use against the enemy.

Internally, all these AI parts are rule-based. There’s also some kind of battle simulation going on behind the scenes that tries to find out what units are needed. A lot comes down to fine tuning some key values to give a credible behaviour.

For example, one of the hardest decisions is what ships to build or whether to build any at all (and tech instead for example). In this case, each spaceship will get a utitity and a threat calculated. The utility reflects how useful it would be to have that ship around, the threat basically sums up how hard that ship is countered by the opponent.

The AI must now straddle the fine line between not building ships when it should do so (overvaluing the threat against them) and building ships that get owned instantly (overvaluing the utility).

There’s a lot more to it like deciding when to build more factories to double produce, resource management and what to tech to, all about decision making. With a bit of tweaking and adding exception rules, the AI now plays pretty reasonably in most situations.

Tactical AI

While the Strategic AI and its subordinates operate on the strategic level, the Fleet AI operates on the tactical level.

The Fleet AI is controlling fleets on the map trying to do damage to either enemy ships or infrastructure, scout or expand. To do this job, it needs to have good info on the map so the game maintains an influence map that knows how much influence each faction has at a particular location, separated into different ship classes. That way, the Fleet AI can plan effective attacks.

A Battle Simulator simulates battles between teams on a regular base. It doesn’t do an accurate simulation taking position into account but compares stats and tries to guess the outcome of a confrontation. This information is used by the Military AI to build the right ships or ask the Tech AI to research new ships to counter the enemy.

Campaign AI

I haven’t started on that one yet, the campaign may introduce additional challenges to the AI ontop of what the pure Skirmish AI does. Campaign AIs are usually more scripted but may reuse parts of the Skirmish AI but impose restrictions like certain tech not being unlocked.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 

Back from Outer Space – err France

Published on August 20, 2012 in Game Design

I’m back from my four weeks of absolutely great vacation and fully motivated to shorten my (ever growing) todo-list. Skirmish AI is up and running and I must say: after several tweaks and a lot of testing, it plays pretty well. It can beat casual players with ease but what’s more important: it usually plays a pretty sensible game. It can arrive at times that it needlessly suicides a ship or does something stupid but it’s pretty rare. Most of the time, it’s play style is pretty compelling. It is also able to adapt to changing situations or different strategies. I’ll keep you posted on more details shortly.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 

Taking a Short Break

Published on July 21, 2012 in Uncategorized

It’s summer, it’s hot and it’s vacation time! I’m taking a break from the game and go to France for three weeks to enjoy French food, a camp-site with view sur la mer, good wine and good company. It will definitely do me some good to not have to worry about this project for a while, spend some quality time with my family and replenish my energies.

I’ll be back mid-August with fully recharged batteries to continue working on Galactic Conflict. I’ve finally managed to post some screenshots and after vacation, I’ve planned to do some demo video so everybody can get a first impression.

Current status is that everything looks good so far: the game mechanics are implemented, it is totally playable already and really fun. Multiplayer seems to be working fine right now, I’ve ironed out the last desync bugs this week (crossing my fingers). Single player has also made big progress, Skirmish is working and the AI definitely puts up a challenge.

Last week, I also did a quality offensive and have dealt with memory leaks and stability problems and seems to run stable now.

So, the feeling of leaving it in really good shape will make my vacations all the more enjoyable.
Stay tuned for more information coming to you mid-August.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 


Published on July 15, 2012 in Development

Ah, multiplayer. First you make the actual game then you add multiplayer support ontop of it, right? After all, multiplayer just means that the game needs to run on different devices simultaneously and somehow show the same game.

We all know that things are not as simple as that. I’d daresay that you either plan for multiplayer from the get-go or you’re going to be in a hell of trouble later on. It’s not like you can just get your normal game going and then add it later on without having planned for It in the first step.
Also, a general rule of thumb is that a multiplayer game takes three times as much effort to realize than a corresponding single player experience.

I knew pretty much that multiplayer would be part of my game since RTS is pretty much all about multiplayer competition. Obviously, when you first start your game, it will initially be a single player experience. But, whenever I was working on a part of the (early) game, I was always keeping multiplayer aspects in the back of my head for all design or implementation decisions.

Multiplayer is not Multiplayer

One of the key messages is that there’s no such thing as the multiplayer support. If you have coded multiplayer for a turn-based game, you don’t really have a whole lot to build upon when you next start a FPS shooter.

Similarily, if you’re doing an FPS shooter (or any other action-based game), you’ll have to use a totally different model and solve other problem than I had for my RTS game.

That having said, all my experiences are obviously from an RTS multiplayer game. By no means I’d be able to carry over the code to an action-packed game without substantial modifications.

Challenges of RTS Multiplayer

Still, when I started the multiplayer part of my game, it was really a challenge. First of all, I got to say that I had a pretty clear picture in my mind how I wanted to implement the multiplayer aspect of my game. A lock-step simulation dynamically adapting to changing network conditions (latency adjustment) and frame rates. I got a pretty solid understanding about network programming and having a professional history in VoIP, RTP and QoS, terms like lateny, jitter and packet loss, network protocols like UDP or implementing custom protocols ontop of it was nothing new for me.

I’ve even written a pretty detailed design document describing the lockstep model I wanted to implement, the protocol exchanged between the clients and the used algorithms to adapt for changing network conditions and such.

Still, I was running into real challenges. Basically, when you want to deal with real-time multiplayer, you need to deal with:

  • Synchronization: commands sent from one client must be synchronized to all others and replayed “at the same time”.
  • Latency: sending (and receiving) commands takes time but this delay should not be noticeable if you can help it. You need to adapt to changing latency.
  • Jitter: the time it takes for transmitting packets is not constant, it may change rapidly from 100ms to 500ms and later go back to normal, and you need to deal with that.
  • Packet loss: guess what, packets get lost in the Internet and you need to make sure they are resent or you’re missing out on crucial information. Ontop of it, packet loss causes additional latency (you first need to detect that the packet wasn’t received, then resend it and all this takes time).
  • Determinism: simulation on all clients must be deterministic or the games will quickly start diverging between clients.
  • Frame rates: different devices can sustain different frame rates but slower devices will drag faster ones down if you don’t take it into account.
  • Matchmaking: how to make players connect to each other?

Is Life Deterministic?

While my initial implementation was able to handle most of the challenges (thanks to the detailed design doc), I was particularly running into quite a few problems with making the game deterministic. Even though I was planning for multiplayer support and therefore opted for a fixed simulation timestep, no out-of-sync random number generation and generally deterministic behaviour, a few subtle sources of determinism were causing me a real headache.

I remember that a particular (efficient) implementation of line-of-sight calculation had a very subtle side effect that resulted in non-deterministic behaviour: a fighter would pick a different target on one client than on the other one for a few frames and eventually go totally out of sync between different devices, causing side effects to other fighters and within a second or two, two devices would show a totally different scenario.

The fact that it is hard to debug multiplayer games means that you have to trace down these sources using endless trace files trying to figure out why the heck the game desyncs. I was really blaming floating point arithmetic or generally starting to think that computers may have become non-deterministic lately (Turing, where are you?).

Multiplayer programming can also provide some more philosophical insights into time being relative, for example. If on one device your frame rate drops, and as a result, you cannot keep up your simulation, then you need to avoid the spiral of death (simulation takes even longer and your frame rate drops some more which makes the simulation take even longer). You do so by cutting off (real-)time and not use your whole real-time for simulation, so simulation time and real time diverge (the game will basically slightly slow down instead of getting totally frozen). In addition, adjusting the simulation rate will remedy some of these problems (but end up in more jerky but at least steady movement). On another client, things may be fine (e.g. better hardware) but it must do the same simulation or it will be ahead in time.

The other device may, however, experience network issues causing latency to increase. This must be taken into account to avoid jerky movements or the game getting stuck for noticeable periods of time. However, other devices must be aware of this even though they may not experience the same problem. When the network conditions get better, we may improve response times but only gradually so things stay predictable for the player.

Very funny situations you run into! Obviously, things get a lot easier if you’re doing a turn-based multiplayer game so many challenges do not apply there.

Anyway, over a couple of weeks of hard work, I must have ironed out these problems but the multiplayer code in my game still gives me the creeps. Every now and then, I got to do some regression testing on the multiplayer part and the simple fact that I might discover a new nigh-impossible-to-track-down bug really scares me.


Testing multiplayer games is a lot more difficult than testing single player games. First of all, you need quite a bit more test devices or how are you going to test a 2v2? Ontop of it, you can’t play on 4 devices simultaneously, heck not even on two for a challenging game.

Even more difficult is testing for different network conditions. Overall, you can’t always get a real game going with real bad network conditions. After all, who has a friend in all corners of the world at his fingertips he can test with anytime?

That means, testing means simulating bad network conditions and we all know simulation is often only half the truth. I’ve simulated quite a few varying network conditions, like high latency (1 second of round trip latency means the game will have really noticeable lag), high random packet loss, high consecutive packet loss (yuck, game gets unplayable but not a realistic scenario), or network conditions that vary a lot (alternating between low and high latency).

I’ve also connected devices with one (artificially) slowed down to low frame rates dragging down the other to check out whether frame rate adaptation can compensate for changing frame rates.
Overall, the testing aspect means a lot of extra effort and I still can’t be sure how the game will react in all situations it will be exposed to when the player base really grows and people across the world need to connect to each other.


Security always takes time both, on the programming side and the execution side. However, multiplayer means there’s always the risk of players trying to score an unfair win by cheating. Usually, this needs some technical background but without any measures, it is totally possible to cheat if you are creative.

I don’t plan to totally encrypt everything because encryption and decryption is too much of a performance hit. However, I’ve used digital signatures to make sure that the content is not tampered with, neither while it was sent over the network nor on the device itself (e.g. configuration files holding balance changes).

Game Center

On iOS, multiplayer usually means Game Center support and I was counting on Game Center supporting me in getting crucial things done, most importantly matchmaking and NAT punch-through.
In fact, Game Center is fantastic, I wouldn’t want to do my game without it but it still has quite a few short-comings that were hard to deal with.

First of all, matchmaking in Game Center offers you little control on how to match teams up. I really would have loved to see an arranged team setting where I really have control who’s gonna play against who. Teams do not show up in Game Center. Apparently, Apple thought all games are going to be cooperative.

Also, it is extremely hard to implement a League concept ontop of Game Center where you can be matched based on your skill.

Scores in Game Center are another issue. In contrast to OpenFeint, they can only go up which means you cannot implement an experience system where you’d lose some of your points after losing a game.
Overall, Game Center still provides a lot of functionality that I wouldn’t have wanted to implement on my own but a few things could be improved.

Multiplayer Conclusion

It can be said that multiplayer adds a lot to your game. You can play with/against your friends, the replay value dramatically improves, you can socialize with other players, invite friends and it opens up new game modes.

However, it can also be said that you need to add a lot to your game as well to make multiplayer happen. So the bottom line is: even if you have a pretty good clue about network programming, I still came to the con-clusion that real-time multiplayer is not for the faint-hearted.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 

The Motivation

Published on May 29, 2012 in Game Design

Before going more into other details, let’s briefly talk about the motivation to develop your own game. I mean, game development is not just fun, it is also means going through a lot of trouble to come up with a good game.

The basic question is: is making this game worth my time? After all, (life-)time is a limited resource, you better spend it on something important.

Different people have different motivations why they are developing games. Some are attracted by the ever-lasting rumour that making a game will make them rich. A few success stories, mostly on Apple’s AppStore, have attracted many people trying to make a fortune (a lot of time by making a bad clone of other successful mobile games).

Let’s get realistic, the chance of getting rich from your game is extremely low. If that’s your motivation, you better reconsider. It is hard to keep motivation up if for months, you won’t see any money but have to keep your spirits high or you’ll abandon your project before it’s done.

Or you end up releasing a “greedy” game, i.e. a game without enough playtesting which ultimately means unpolished work (and probably bad reception).

The Inner Urge

I have often wondered myself why I actually am doing this. It is a time consuming hobby, it can get frustrating, and it is not exactly easy either.

I’ve found that somehow, I have an inner urge to develop games. These are the reasons driving me:

Self Expression
A game gives you the opportunity for self-expression you often don’t have in your “normal” life. It is a wonderful experience shaping a medium such that the experience you want it to provide gets real.
In my daytime job, I’m not in the creative business. While you sometimes need to find “creative solutions” in every demanding job, it’s not what I really call creativity. Man has an inner need to be creative (or at least I have). Making a game let’s me be creative in life which is very satisfying.
Many people who know me personally have assumed that this is my main driving factor. It is true that I like coding and it is also a fact that I don’t get to code in my professional life anymore because they have more important things for me to do. I tend to think of myself as a very skilled developer and it is a shame wasting such talent.
Don’t get me wrong, when you are developing your own game, you don’t find the time to play a lot of games. And if you do, it is for inspiration more than anything else. When it comes to your own game, you’re going to test it to oblivion and testing is not playing, not even close. Still, games are a wonderful thing (ask the kids) and working on one is great, too.
Historic Reasons
I’ve already been developing games when I was a kid. As a teenager, I was writing games on C64 and Amigas. It took forever to make one since the machines were so weak so I was essentially developing them in Assembler and had to set every bit of the gfx hardware myself. I stopped doing so at some point because it was extremely hard to distribute your game (the www did not even exist in its current form). But now, with good distributions channels and powerful technologies (like OpenGL), things look a lot better and I’m back.
It’s not high up in my list but I’m no fool: I’ll gladly take any money I get from the app development. Ultimately, we always use figures to measure all kinds of things in life and the success of a game is proportional to the money it made. However, I do not optimize the games for monetization. I’m pretty sure my current project wouldn’t have made it through our company’s decision boards due to the nature of the AppStore: quality games mean long development cycle which means high risk due to potential lack of exposure.

So, the inner urge is there and pushing me and who am I to ignore it.

What this means for my current Game Project

One of the reasons why I was daring to start developing my new game is: it seems like I got to develop one anyway. If I’m not developing that one I’d have to search for another idea so I may as well do the one I find intriguing, even if it takes some time. Basically, since the journey is the reward, I may as well go on a longer journey.

The Financial Side

Let’s be honest, as far as the business case is going, the game is going to be a financial disaster. 🙂

Ontop of the money I’ll have to spend to cover aspects of game development I don’t have the skills for, if I’d sum up all the hours I’ve to pour in and then (virtually) pay myself the hourly rate of, say, a baby sitter then it will take like forever to break even.

RTS games are a niche and they are quite the opposite of what people often refer to as a casual game. Almost all successful titles on mobile devices are casual games, easily accessible, no learning curve, and cooperative. RTS games are quite the opposite, you need to learn the basics of an RTS game before you can enjoy it, it is therefore less accessible and more on the competitive side rather than cooperative.

I could probably do a casual game in a fraction of what it takes to make my complex RTS game, but frankly, I can’t bring myself to do so.

If the financial side of things would be in my focus, then I’d probably have to build a free-to-play game with purchasable in-game items. That’s where the money is. The problem is, I have no affinity to those types of games, I don’t want to play a game where you can buy a shiny new blue hat for your character for $0.99. I don’t want to go to a non-immersive world and collect my coins every day.

I wouldn’t be able to muster enough self-motivation to go the long way of developing a game that I wouldn’t even enjoy myself. So, I’m sticking with traditional games for the time being. Call me old-fashioned but my interest lies in what I refer to as real games. So I’m determined to make that one real.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 

The Vision

Published on May 18, 2012 in Game Design

In the beginning was the vision, and the vision was in your head.

All games start with a vision. A cool idea, something you think would make a good game. Without a vision, there’s nothing to aim for, no intended experience for the future players.

Obviously, most game designers want to make cool games. Professional games like we like to play for ourselves but as an Indie, you need to be careful not to overextent. You can only do so much with limited time and resources.

Second, Indies are often limited in terms of skills due to the fact that there’s often only one person on the team. This can be somewhat remedied by contracting others or buying pre-made assets but since most games run on a shoe-string budget, you can’t really get around your weaknesses.

That means, whenever you have a vision of a game as an Indie, you need to make sure it is doable, not on a technical level only, but doable for you, taking into account the time you can afford to spend on the project and the skills you can bring to the table. That will already rule out quite a few cool ideas.

For example, I’m not very good at character animation I had to find out. I once wanted to make a game featuring a sexy lady as the main character. I came up with a nice rigged 3D model, but I was ripping my hair out trying to animate her, even though I tried to use motion captures, I eventually figured that I can’t do a game involving extensive realistic character animation on my own, at least not in reasonable time.

The Vision of my new Game

After having released Air Force vs Luftwaffe, I wanted to do a totally different game. I spent some months thinking about an ant game, where I’d use scents to indirectly control a growing ant army but I couldn’t get the game design to a level where I thought it would be a fun experience.

So, I moved on to another idea. Basically, I’ve always been a fan of the RTS genre (real time strategy), I played most of the PC-based titles from Age of Empires to Starcraft 2. Ontop of it, when I was a kid, I initially wanted to be an Indian (now at least I made it to an “Indie”) but then Star Wars came out and everybody moved over from the Western to the SciFi trip. Me and my bro were designing our own spacehip models on paper with accurate details and kept dreaming about their stats (“this corvette beats that fighter in direct combat”).

On a similar note, my own kids of 5 years really love Star Wars The Clone Wars, the animated series. So I figured, why not make a SciFi based RTS game? The vision in my head featured huge battleships and smaller frigate class ships ducking it out in space with lots of visual effects. Small strikecraft would fly around like bees and put their stings into the hull of the big ships which in turn try to fend them off with flak cannons. Explosions, laser beams, missiles and torpedos everywhere. It sounded like a blast.

Ontop of that, since it is going to be an RTS, you’d be able to colonize planets, develop their infrastructure, gather resources, conduct some researches to unlock more powerful tech and build up your fleet.

Obviously, RTS is all about multiplayer, why play against the AI if you can play against others who will bring their own creativity (in terms of strategy) and make the game a ton more fun? Obviously, you can’t do without a single player experience either.

Is it doable?

I have made many software development projects in both, my professional and private life. In the last 15 years I’ve been setting up and managing software devlopment projects with a budget exceeding the million dollar mark, so I’m not an over-optimistic idealist who just jumps into a project guns blazing only to run out of steam a few weeks later.

Basically, I made a rough plan of tasks that would need to be done to complete just the development part of it (not including any balance/beta tests and promotion and whatnot) and unfortunately, if I were true to myself, I’d have to tell myself: this is not gonna be a casual game you can crank out in a few months.

I figured that the biggest challenges are going to be:


Whoever has tried his hands on a multiplayer game (not a turn-based, a realtime multiplayer game) will agree that it is a nightmare to develop. You gotta fight latency, jitter, packet losses, NATs, frame rate drops and sync problems to name a few. Debugging a multiplayer game just adds to the challenge. It’s enough to give me the creeps.
In my vision, there wasn’t just 10 measly spaceships flying around in endless space, I had several big ships in my mind accompanied by dozens of smaller fighters. Ontop of the rendering, I was particularly concerned about the need of CPU power, esp. for the unit AI, collision detection, etc.
I soon found out that RTS is one of the most difficult genres to develop, mostly due to the AI challenges. Squadron movement, pathfinding, unit AI on the unit level, and a skirmish/campaign AI on the game level are non-trivial tasks. This one I was dreading even more than multiplayer.
Playtesting & Balancing
It is inherently hard to balance an RTS game and it requires a lot of playtesting. Where do you get good testers who will give valuable feedback? Proper playtesting and adjustments can make or break the game and is therefore one of the most critical items.
I hate doing campaigns, esp. since they introduce quite a few more AI challenges.
Sounds & Voice Acting
Music and sounds effects add a lot to a game but are often underestimated. In addition, for my game, a multiplayer technique called latency masquerading requires extensive sound effects to be used. Ideally it would be voice acting to give more life to the game. Where the heck do I get voice quotes from? I’m not even an english native speaker after all.

Can I do it?

It takes a lot to write an RTS game like that with a skilled team. It takes even more to do it as a one-man Indie as a side business.

Can I do it? The biggest advantage of a one man show is the efficient communication. The number one reason for project failure in software projects is communication (or the lack thereof). I’m pretty good at communicating with myself, hardly do I have to argue about things with my alter ego, and we never have any misunderstandings. Also, I can cut down the time allocated to communicating design decisions to the team to roughly 0.

In my day-time job, I spend the majority of my time doing some form of communication, be it writing emails, talking on the phone or sitting in a face-to-face meeting.

According to researches, a good software developer can be as productive as a team of 10 average guys. I tend to believe that I’m a good developer, remains the fact that I have a day time job, a family, social life, hobbies, … 🙂


So I have embarked on this adventure, I may have to strip off some minor things if it really gets to the point that I can’t get everything done (I can’t gurantee that it will really contain a campaign since my focus is more on multiplayer and voice acting is certainly optional, too). It will probably take somewhere between 1-2 years to develop depending on the amount of time I can afford and the balance test.

Fortunately, at the time of this writing, I’ve already made some considerable progress, so we are already half a year into the project.

In my next post, I’ll talk a bit about Motivation and explain why I think the game has a chance of getting real despite the fact that it requires a huge effort.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments 

The Life of an Indie

Welcome to Bitmen Studio’s Indie Game Developer Blog. What’s this all about?

My name is Mark and I’m an Indie. I’m developing games for iOS devices, so basically for iPhone, iPod touch and iPad. Being an Indie is an interesting experience, it is very rewarding (less so money-wise) but also very challenging.

Why am I writing this blog?

The reasons why I’m doing this are manyfold. I basically have three intended audiences.

Other Indies

First of all, like most Indies, I’m a one man army. Being an Indie means covering all aspects of game development, from early game design to promotion alone. That’s a challenge and requires a lot of different skills. During game development, a lot of decisions need to be made, some are quite hard.

But what makes this even more challenging is the fact that being an Indie is a lonesome job. It is hard to discuss decisions and design issues in a one man team. By writing this blog, other Indies can see what troubles I’m dealing with and it will sure help exchanging experiences or just simply realize that others are facing similar challenges.


To most gamers, games just magically appear on, say, the AppStore. Without a development background, it is sometimes hard to envision what is behind “making a game”. This blog will provide some insight what it takes to write a game. It is not a technical blog (you won’t be able to write your own game after reading it), but it will show what challenges Indie game developers face, how they deal with them and how what originally is just an idea slowly shapes into a real game.

Alternatively, the blog obviously will contain information about my new game if all you care is the result.


I’m also hoping to draw some inspiration and motivation out of this blog. While it takes time writing things up (and time is something an Indie does not have in abundance), I’m hoping that publicly sharing the experience means that I can carry on when I feel like retiring my project or generally get some feedback whether things make sense in my head. On a meta-level, I may even find out why I am doing this? 🙂

Last but not least, the blog is a testimonial that I’m busy on some stuff and I haven’t dropped dead. 🙂

The Game

When writing a game development blog, there needs to be a game to write about, otherwise it is going to be pretty academic. I’m currently working on a SciFi based RTS (real time strategy game). For those not being familiar with RTS, think Starcraft, Age of Empires or Command & Conquer.

You can find some preliminary info in the Game Info section. It doesn’t contain a lot of pictures yet but I’ll gradually improve it.

About me

In real life, I’m a software engineer working for a major international software company. While I used to be a developer long time ago, I’ve since then moved to management duties. My current role is IT architecture but I’m also doing project management and that means I spend most of my daytime in meetings, coordinating, communicating, managing.

That having said, ever since we have off-shored development, I haven’t done any coding for the company. Still, coding is what I love most and what I’m best at, I’m known for pretty fast development speed with crystal clear code. I’ve been coding since I was 13 (back than in Assembler on a C64) and needless to say that for the first years, I’ve been writing games.

Ontop of that, my 15 years of experience in the software industry means that I’ve a structured approach to things. I’m not just sitting there and hacking in lines of code, crossing my fingers and hoping for the best. I write down a game design document to know what to achieve, I write specs for non-trivial implementation tasks (multiplayer comes to my mind) and I’m writing down the storyline before I try to put it into code. I also have the habit of organizing my projects and tasks in order to streamline development. This saves me a lot of time in the long run.

No strengths without weaknesses and the list of weaknesses is long: I’m not an artist, I’m not a composer, nor am I a sound engineer, writer or an experienced game designer. On a similar note, I’m not a salesman, PR and marketing pro or anything like that. Still, all these aspects need to be covered.

 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
3 Comments  comments 

© Bitmen Studios