RTAmoeba is working

I searched my Gmail account for "rtamoeba" and have found the tarbomb that I sent to my old friend Spag for testing. Luckily there was an archived gtalk conversation next to the mail that contained the attachment, which included some "installation instructions", otherwise I would have had trouble with compiling it from source:)

Anyway, it did compile and it did run, so I could play with it. Here's a screen shot.


I'm trying to convince some friends to play it with me. Should be fun. Meanwhile we will see what I can do with the code, maybe it worths saving. The code smells like University, but it might turn into something useful after some heavy refactoring.

Rebooting with RTAmoeba

So I found this blog again. It is sad, and it is beautiful. I don't remember why I failed two years ago, but this project should be revived.

I have learned much in these past few years. I knew that creating a video game has many challenges, but I was naive enough to think I can handle them all. I sort of miss that naivety.

Two years ago I was attending a Linux programming course at the University. One of the criteria was to create something that runs on Linux. It was a good opportunity to create some simple video game and see how it's done. I came up with a game that was the real-time version of Five In A Row (or Amoeba, as known in Hungary). The rules was the same as in Amoeba, but the players didn't take turns, they could place a stone every five seconds. If you couldn't come up with a good move in five seconds, your opponent had the chance to place more stones than you, a serious advantage in Amoeba. It was fast, thrilling, action-packed, it was Amoeba on steroids:)

I coded it in a few days in C++ using SDL. I looked into my code recently, and it was quite a sad experience. It was full of rookie mistakes. I can see why it took away my passion for creating a way more complex game.

What I'm going to do, is revive RT Amoeba. Maybe I will re-implement it in Python using Pygame. The goal is to clean up the code, fix the bugs, and release it in some form. I want to create a simple game that people can actually play. After that, I can start thinking about more grandiose things to create.

The quote in the sidebar is marvelous. If I can find the same passion and will again, I will be able to create something beautiful. I just need get this one right first.

Episode 2: What exactly?

I wanted to get a bit technical in this article, but I figured there is no sense talking about the "how" while we can't even answer the "what". So in this article I'm going to summarize my basic concepts about the game, and what inspired them. This is to get an overall impression on what it is going to look and feel like to play the game.

So we know that we are talking about a tactical wargame set in WWII. How came this choice?

Memoir '44

I have recently bought a set of Memoir '44, a turn-based tabletop tactical wargame, and I fell in love with the simplicity of the core game mechanisms at first sight. This is a game by Richard Borg and it's based on his Commands & Colors system, a beautifully simple and clear system with a really fast learning curve, yet it models battlefield conditions and probabilities quite realistically.

In Memoir '44, to attack a hostile unit, all you have to do is to calculate the number of "battle dice" your unit can throw against it, which basically depends on the distance and the terrain conditions the attacked unit might benefit from. Each battle die has a chance to hit, and it's all as simple as that!

When I woke up one day with this weird urge to create a video game, one of my first candidates was an adaptation of Memoir '44. In the first few weeks I was constantly daydreaming about all the real cool ways of adapting and modifying it, and by this time (four weeks from the beginning of the design process) I can say I have a pretty solid idea about what it's going to be look and feel like.



Real-time

The first thing I decided to change, and also the thing with the biggest impact on the overall game mechanisms was that I wanted to play Memoir '44 in real time. Switching from a turn-based concept to a real-time one is quite drastic (just imagine how a real-time version of chess would be like :) ) and there are many modifications that are needed to be made to facilitate this change.

The one thing I hate about turn-based multiplayer games is that I either have to wait a lot while other players think, or that other players bug me to think faster during my turn. This is a non-issue with real-time games.

Real-time games are really good at conveying the pressure of having to make fast decisions -- you really feel like you're an officer on the battlefield in command, actually giving out orders, not just some theorist having all the time in the world to figure out the smartest move.

Strategy vs. Tactics

It is also important not to confuse real-time strategy (RTS) with real-time tactics (RTT) games. Strategy and tactics focus on totally different aspects of warfare. While strategy concerns grand-scale productional, economical and logistical aspects, tactics is all about optimizing combat effectiveness in given situations.


In RTS games, such as Dune II, Red Alert, and StarCraft, players usually compete against each other by controlling and managing resources, training units in a matter of minutes, which shoot at each other until the green bar above their head runs out. Realism is not as important as a fun, fast-paced gameplay. On the other hand, RTT games tend to be more realistic: players have a set of troops to start with, and gameplay is actually real-time -- units are not being created in a couple of minutes.

Combat is focused around critical locations on a map in both cases, but while in RTS games these strategic locations are potential sources of income, in RTT these are positions that are offering good conditions for attack or defense.

RTT, as a genre is generally not as popular as either RTS or turn-based tactical games.

Back to the Hexes

A concept in tabletop wargames that I really liked and wanted to keep is that the battlefield is split into a repeating pattern of hexagons (hexes). This is a necessity in board-games, to simplify game mechanisms, and there are not too many reasons why a computer game should lock itself inside the boundaries of hexes. Indeed, real-time strategy and tactical games have broken out of the hex-based terrain system many years ago.

Still, I decided to stick with the hexes, since they give you a huge amount of clarity and simplicity. Individual soldiers doesn't get stacked over each other, you immediately see how far a hostile unit is, and whether your units are in harm's way, you can guess how long it's going to take for a fireteam to get into position. It also makes it clear whether you are being covered by a bunch of trees or not. Hexes make things simple, and that, we like!


I believe that this simplification won't hurt realism either. You can perceive a hex as a unit's zone of control. A fireteam of four soldiers can cover the area of a soccer field (about the size of a hex in the game). More soldiers than that in the same spot would be counterproductive -- would not increase fire power, would increase chance to get hit.

Graphics

Since the game focuses mainly on gameplay, instead of fancy graphics (couldn't compete in that area) I decided to go for simple 2-D sprite graphics. You see the battlefield from bird's-eye view, but from a small angle so that you can see things like which direction your units are facing, and things like that.

A great deal of effort should be invested in the design of a clear user interface, meaning that the control of the game should be intuitive and seamless. Many times games fail because the designers didn't bother to make the . Players don't read manuals, so you have to make the controls so easy they grok it instantly, intuitively, otherwise they just give up.

So that's it

In this blog, we are going to learn about the process of game design by following the creation of a hex-based real-time tactical computer game.

I'm doing it for the first time, so I have no idea where it's going to lead, but I'm sure it's going to be heck of a fun! :)

[M'44 battle scenes with awesome customized figures and terrain by Brummbär]

Episode 1: Goals

As Chris Crawford writes in his 1982 book - The Art of Computer Game Design, when deciding to start to develop a video game, the most crucial point is setting the goals.

I guess it's something that gives you focus when you face tough decisions, like having to rule out a feature that you really like from the final design. If the feature resonates well with your goals, you should keep it, otherwise it's garbage.

Taking seriously a book that's 26 years old, especially in one of the most dynamically developing areas in the industry may seem odd, but the principle makes sense to me, so that's what I'm going to do. I'm going to define the goals of my game:


1. Military tactics in modern warfare

The main goal of the game is to let two players compete against each other by figuring out ways to optimize the overall combat effectiveness of their army in given situations by exploiting battlefield conditions and enemy weaknesses, controlling critical locations, managing reinforcements, and many other aspects of modern military tactics.



2. Realism and Simplicity

The game should have a degree of realism that makes it fun to play, yet it is fast to learn. Most people are not playing video games because they want to make difficult calculations, and they don't want to spend too much time learning the game either. Too detailed gameplay asks for a too detailed I/O structure, which results in way too much complexity and frustration.

However, realism helps people find smart solutions intuitively, since they already have guesses on how it's all supposed to work in real life.

So finding the right mixture of realism and simplifications is vital for the game to be fun.

Simplicity and realism are not necessarily contradictory notions, though. Having to order around every single troop on the battlefield is neither simple, nor realistic. Having smart squad leaders do this job for you is much simpler, and closer to reality as well.

3. Choices

A fun game is all about choices. Scenarios and units must be designed in a way that excludes ultimate strategies. Linear map design leads to boredom, so this must be avoided.
Unit types should be balanced and have rock-paper-scissors qualities.

4. Historical accuracy

The topic of the game is the Second World War. Scenarios will be based on historical battles. I think this makes a lot of difference, since reliving actual battles are far batter then blowing up some random fuel depot.

5. Openness

Being a single developer, it's important for me to be able to rely on user-generated content. Adding artwork and scenarios must be made really easy, so that anyone could help.
The game engine must be flexible enough to allow extensions and modifications. The game should be extended to all major theaters of the Second World War, so flexibility is of great importance.
Also, I believe in open source software, so the source code will be available for anyone.
The game shall be platform-independent as well.



This sounds quite strict and formal -- after all we're just trying to make a fun game with yankees and krauts shooting at each other -- but there are thousands of pitfalls in game design, and I think that having a basic concept and a well-defined set of goals as a strong foundation rather than just getting cracking willy-nilly, might make quite a big difference.

In following posts I'll go a little bit into details, like the language I chose, the tools I'm using, my basic ideas of the gameplay, and so on. See you next time!

[bullet skull by skull-a-day]

How to Create a Video Game

Two weeks ago I realized I must create a video game. This blog tells the story of the epic journey I decided to take. Watch me succeed or fail.