I have set up a website which will now serve as a central hub for all my work. It contains a short biography, a CV and a portfolio of my work. You can find the website at www.strawberrycowbear.com.
woensdag 24 augustus 2011
My favourite indie games
In the last couple of years, indie games have grown up. They can now stand tall and proud next to the products of the AAA studios, and often boast better, more innovative gameplay and more imaginative visuals. A lot of my favourite games from the last couple of years are indie games, as I almost completely stopped enjoying (and thus playing) most AAA efforts. The following list contains some of my favourite indie games of the last couple of years. I consider all of them absolute must-plays for any serious gamer.
As can be seen from the list, the number of classics is growing each year. We're only halfway 2011 and there's already three games that I consider an absolute must-play. What more will the future bring? Things have never looked brighter for the game industry...- Aquaria (2007)
Imaginative visuals, interesting gameplay and a compelling story make up this underwater adventure. One of the first indie games that truly showed me how awesome they could be. This game is LONG, but never gets boring or repetitive; you get some serious bang for your buck in this one.
- World of Goo (2008)
An innovative puzzle game that grew out of a game jam prototype. One of the most original puzzlers I'd seen in years, and some great visuals as well. Where have we heard this as well?
- Braid (2008)
Right! In the same year, Braid was released, another puzzle game with excellent visuals and atmosphere. Braid has one of the most jaw-dropping endings I've seen in recent years. One of the absolute best of the best among indie games.
- Amnesia: the dark descent (2010)
Fucking scary. That's a nice summary for this first person horror game. It's truly one if the scariest games I've ever played. One of the reasons it is so scary is that there's no combat; your only option is to run from your opponents, and hide in the dark until they give up their search.
- Minecraft (2010)
Well this game needs no introduction. It's a virtual lego box with unlimited bricks, water physics and zombies.
- VVVVVV (2010)
Retro puzzle platformer with an interesting gameplay mechanic: you can't jump, but instead you can change the direction of gravity at will by pressing space. Short, but excellent and highly creative.
- Super Meat Boy (2010)
My personal favourite indie game of recent years, Super Meat Boy is pretty much the best platform game ever made. It's Mario taken to minimalistic perfection, with only a run button, a jump button and wall jumps as your arsenal to get through the increasingly challenging (and awesome) levels. I love the style of this game, I love the attitude, and I love the design. If you like platform games, this is the one you should be playing.
- Limbo (2011)
This small little black-and-white jewel does so much with so little: a puzzle here, some smart platforming there and some really atmospheric visuals serve to create this gem that is definitely one of the most coherent gaming experiences I've played.
- Terraria (2011)
2D minecraft ripoff? That's definitely what it looks like. But underneath the surface, it's more a side-scrolling Zelda-like adventure game, in which your goal is not to build awesome stuff (even though you can) but to get the best gear by exploring the underworld, fighting bosses and collecting loot. This game suffers a bit from a bad first impression, but once you get past it, you're in for a treat.
- Bastion (2011)
Even though its gameplay mechanics are quite simple and unoriginal, this game has some of the best visuals I have ever seen in any game, easily surpassing modern AAA titles in atmosphere, style and narrative. It has several interesting gimmicks that make it stand out (dynamic voice-over narrater and levels that build up in front of your feet), but the game is much more than that. It's an extremely well crafted fantasy world that is just a complete pleasure to discover.
dinsdag 28 juni 2011
Simple sphere-based collision detection and response
1. Introduction
This tutorial will serve as a guide for implemening a simple sphere-based collision detection and handling routine. There is a lot of information available on these subjects on the internet, but most of this information is fragmented or poorly explained. Additionally, a lot of information is focused on collision detection with polygons, which is not what I am looking for.
The focus of this guide is on sphere-based collision detection in a tile-based 2D world. While the world is tile-based, the objects can move freely in real coordinates, allowing for more realistic movement. However, this obviously creates some new challenges, especially in pathfinding and collision detection. This guide will hopefully explain in a clear manner how to deal with this problem.
Spheres are a convenient way to efficiently do collision detection for large amounts of objects. Collision checks with spheres are extremely fast, and spheres have some very nice properties that make collision response also relatively simple. Additionally, most game objects can actually be approximated with a spherical shape. If this is not the case, they usually can with a number of spherical shapes. This does not change anything about the algorithms in the following guide; just process each sphere individually as if it is a separate object.
Using spheres to represent game objects in collision detection has a number of advantages over boxes. Boxes have very easy collision checks, but are more difficult to deal with in collision response. It is very difficult to compute how to maneuver two boxes around each other without them colliding at any point. When you only need simple collision response such as "destroy one of the two objects" or "bounce back", collision boxes might be a better and simpler choice over spheres. But in cases where you need somewhat realistic collision behaviour, such as in RTS games, spheres are much more suitable.
And yes, I know a sphere is the 3D version of the 2D circle and that this guide is actually about collision detection with circles. But bounding sphere seems to be the general term used for this kind of thing, so I'll stick with it.
This algorithm will look for the point in time (where as location for t=0 is \(L_i\) and location for t=1 is \(L_i + M_i\)) where the collision occurs. It starts by testing for a collision at t=1, and if there is one, the algorithm proceeds. It will first look at 0.5 for a collision, and if there is one, it will then look at 0.25, otherwise it will look at 0.75. This process is repeated with double the accuracy each time. This results in a pretty accurate estimation of when the collision occurs.
After this computation, \(SM_i\) contains the part of the original move vector \(M_i\) that is safe to carry out for both objects without having a collision. This code will cause no objects to ever collide, but does not handle collisions really well. If an object encounters another object that is not moving, it will just stop forever, because it cannot find a way around the other object. This is dealt with by collision response, and will be discussed in the next section.
3. Collision response
There are a lot of algorithms for dealing with collision response, and they can be roughly divided into three categories:
So for both objects, we now define the illegal (impossible) part of the move vector as follows:
$$v_i = M_i * (1.0 - tBestSoFar)$$
This vector is illustrated in the figure below:
The idea is to have the objects "slide" besodes each other without colliding, so that they can pass each other. This can be compared to when you are walking, and someone is heading your way in the opposite direction. To avoid collision, one of you moves a bit to the left, while the other moves a bit to the right. In order to calculate the improved and safe move vectors \(v_1',v_2'\) from \(v_1, v_2\), we need the tangent of the spheres at the point where they collide. The tangent is always the same when two spheres collide at one point, and is perpendicular to the vector from one center to the other:
$$d = p2 - p1$$
$$tangent = [d.y, -d.x]$$
The tangent should be normalized:
$$tangent = \frac{tangent}{ \left\| tangent \right\|}$$
We now need to compute which direction we want to slide to. If the move vector leans more to the right of \(d\), the new movement should slide to the right around the other object. This is achieved by calculating the projection of \(v_i\) onto the tangent:
\[u_1 = v_1.x * tangent.x + v_1.y * tangent.y\]
\[u_2 = v_2.x * tangent.x + v_2.y * tangent.y\]
If \(u_i\) is positive, this means we are trying to move in the direction of the tangent vector. If it is negative, we are trying to move in the opposite direction. The sign of \(u_1\) can thus be used to determine in which direction to "slide".
Putting this together results in the following code:
Note the EPS in the last lines. This is used to avoid the case where two objects are headed straight at each other, and both turn into the same direction. This is the case when u1=u2=0. To avoid this issue, one object will prefer moving to the left, while the other will prefer moving to the right. To take into account precision roundoff errors, EPS is used. EPS should be a very small number, close to double precision. Something like 1e-8 should do.
4. Wall collision
In a tile-based world, objects often also encounter straight walls defined as lines, for example when a tile is blocked. The code above can easily be adapted to work with lines as well, allowing spheres that collide with walls to gracefully slide along them. In the case of walls, the tangent should be parallel to the wall and the rest of the code remains the same. The collision check is also straight-forward.
The following site explains the collision check between a sphere and a arbitrarily oriented line very well:
http://paulbourke.net/geometry/sphereline/
If you only need straight lines (on the border of tiles), the collision check is much simpler, and just comes down to checking the horizontal/vertical distance between the line and the sphere center, and seeing if it is larger than the radius.
4. Conclusion
The algorithm presented in this article will have spherical objects gracefully slide their way through a tile-based world. When they collide against each other, they will attempt to slide along each other, avoiding collision alltogether. I hope this guide will be useful for anyone who is developing a 2D game and needs a robust collision detection routine!
All feedback is of course welcome.
This tutorial will serve as a guide for implemening a simple sphere-based collision detection and handling routine. There is a lot of information available on these subjects on the internet, but most of this information is fragmented or poorly explained. Additionally, a lot of information is focused on collision detection with polygons, which is not what I am looking for.
The focus of this guide is on sphere-based collision detection in a tile-based 2D world. While the world is tile-based, the objects can move freely in real coordinates, allowing for more realistic movement. However, this obviously creates some new challenges, especially in pathfinding and collision detection. This guide will hopefully explain in a clear manner how to deal with this problem.
Spheres are a convenient way to efficiently do collision detection for large amounts of objects. Collision checks with spheres are extremely fast, and spheres have some very nice properties that make collision response also relatively simple. Additionally, most game objects can actually be approximated with a spherical shape. If this is not the case, they usually can with a number of spherical shapes. This does not change anything about the algorithms in the following guide; just process each sphere individually as if it is a separate object.
Using spheres to represent game objects in collision detection has a number of advantages over boxes. Boxes have very easy collision checks, but are more difficult to deal with in collision response. It is very difficult to compute how to maneuver two boxes around each other without them colliding at any point. When you only need simple collision response such as "destroy one of the two objects" or "bounce back", collision boxes might be a better and simpler choice over spheres. But in cases where you need somewhat realistic collision behaviour, such as in RTS games, spheres are much more suitable.
And yes, I know a sphere is the 3D version of the 2D circle and that this guide is actually about collision detection with circles. But bounding sphere seems to be the general term used for this kind of thing, so I'll stick with it.
2. Collision detection
The best way to approach collision detection and response is by splitting the movement process up into three separate loops over the game objects. In the first loop (the update loop), each game object determines the location it wants to go to. After this, each object \(i\) has a current location \(L_i\) and a movement vector \(M_i\). In the second loop (the collision detection loop), all objects are tested against each other for collisions. If a collision is detected, it is dealt with gracefully by updating the movement vectors \(M_i\). In the final iteration, the location of all the objects is updated: \(L_i = L_i + M_i\).
We will now discuss the structure of the second loop. For each object \(i\), find all the other objects \(j\) that need a collision check. You can limit the number of collision checks by working with a quad tree or another space division structure. This is highly recommended if there are a lot of objects in your world. For more information on quad trees, see http://en.wikipedia.org/wiki/Quadtree.
We assume that each object \(i\) has a sphere associated with it, positioned at the location of the object \(L_i\) with radius \(R_i\). In order to check for a collision between two objects, we substract radii of the spheres from the distance of the two objects:
We will now discuss the structure of the second loop. For each object \(i\), find all the other objects \(j\) that need a collision check. You can limit the number of collision checks by working with a quad tree or another space division structure. This is highly recommended if there are a lot of objects in your world. For more information on quad trees, see http://en.wikipedia.org/wiki/Quadtree.
We assume that each object \(i\) has a sphere associated with it, positioned at the location of the object \(L_i\) with radius \(R_i\). In order to check for a collision between two objects, we substract radii of the spheres from the distance of the two objects:
$$\left\| (L_i+M_i) - (L_j+M_j) \right\| - R_i - R_j$$
If this is negative, there is a collision, and it must be processed. In games, time is usually divided into so-called ticks, or discrete time steps at which the game is updated. This means that each object does not move continually but in large steps as well. That the objects collide at the end of the time step does not mean that they do halfway there. To have clean movement, we need to detect at which point in time the collision occurs.
The following piece of code does exactly that in a very efficient way:
The following piece of code does exactly that in a very efficient way:
bool hit = checkCollision(O1, M1, O2, M2);
if (!hit) return;
int n = 1;
double t = 1.0;
double tBestSoFar = 0.0;
while (n < 5) {
// reduce the movement range by a factor 2^n
double piece = 1.0 / pow(2.0, n);
// if we had a hit, we move back one piece
if (hit) t -= piece;
// if we don't have a hit, we add one piece
else t += piece;
// we check for collision at the new location
hit = checkCollision(O1, M1*t, O2, M2*t);
// if we don't have a hit, we have found a better match for our t
if (!hit) tBestSoFar = t;
// next iteration
++n;
}
// change the movement vector for both objects
SM1 = M1*tBestSoFar;
SM2 = M2*tBestSoFar; This algorithm will look for the point in time (where as location for t=0 is \(L_i\) and location for t=1 is \(L_i + M_i\)) where the collision occurs. It starts by testing for a collision at t=1, and if there is one, the algorithm proceeds. It will first look at 0.5 for a collision, and if there is one, it will then look at 0.25, otherwise it will look at 0.75. This process is repeated with double the accuracy each time. This results in a pretty accurate estimation of when the collision occurs.
After this computation, \(SM_i\) contains the part of the original move vector \(M_i\) that is safe to carry out for both objects without having a collision. This code will cause no objects to ever collide, but does not handle collisions really well. If an object encounters another object that is not moving, it will just stop forever, because it cannot find a way around the other object. This is dealt with by collision response, and will be discussed in the next section.
3. Collision response
There are a lot of algorithms for dealing with collision response, and they can be roughly divided into three categories:
- projection-based methods, which adjust the location of the object directly to avoid collision;
- impulse-based methods, which change the velocity (first derivative of the location) of the object in order to avoid collision;
- penalty-based methods, which change the acceleration (second derivative of the location) of the object in order to avoid collision.
So for both objects, we now define the illegal (impossible) part of the move vector as follows:
$$v_i = M_i * (1.0 - tBestSoFar)$$
This vector is illustrated in the figure below:
The idea is to have the objects "slide" besodes each other without colliding, so that they can pass each other. This can be compared to when you are walking, and someone is heading your way in the opposite direction. To avoid collision, one of you moves a bit to the left, while the other moves a bit to the right. In order to calculate the improved and safe move vectors \(v_1',v_2'\) from \(v_1, v_2\), we need the tangent of the spheres at the point where they collide. The tangent is always the same when two spheres collide at one point, and is perpendicular to the vector from one center to the other:
$$d = p2 - p1$$
$$tangent = [d.y, -d.x]$$
The tangent should be normalized:
$$tangent = \frac{tangent}{ \left\| tangent \right\|}$$
We now need to compute which direction we want to slide to. If the move vector leans more to the right of \(d\), the new movement should slide to the right around the other object. This is achieved by calculating the projection of \(v_i\) onto the tangent:
\[u_1 = v_1.x * tangent.x + v_1.y * tangent.y\]
\[u_2 = v_2.x * tangent.x + v_2.y * tangent.y\]
If \(u_i\) is positive, this means we are trying to move in the direction of the tangent vector. If it is negative, we are trying to move in the opposite direction. The sign of \(u_1\) can thus be used to determine in which direction to "slide".
Putting this together results in the following code:
// get the remaining part of the move vector that is illegal // this is V1 and V2 in the figure BM1 = (M1 * (1.0 - tBestSoFar)); BM2 = (M2 * (1.0 - tBestSoFar)); // get the tangent in normalized form d = (L1+SM1) - (L2+SM2); tangent.x = d.y; tangent.y = -d.x; tangent.normalize(); // length of the remaining unsafe move vector double d1 = BM1.length(); double d2 = BM2.length(); // use the projected version to determine the direction in which to slide double u1 = BM1.x*tangent.x + BM1.y*tangent.y; double u2 = BM2.x*tangent.x + BM2.y*tangent.y; // depending on the sign, we move in a given direction // if our move vector is perpendicular with d, we move in opposite directions for each object if (u1 < -EPS) SM1 += -tangent * d1; else SM1 += tangent * d1; if (u2 < EPS) SM2 += -tangent * d2; else SM2 += tangent * d2;
Note the EPS in the last lines. This is used to avoid the case where two objects are headed straight at each other, and both turn into the same direction. This is the case when u1=u2=0. To avoid this issue, one object will prefer moving to the left, while the other will prefer moving to the right. To take into account precision roundoff errors, EPS is used. EPS should be a very small number, close to double precision. Something like 1e-8 should do.
4. Wall collision
In a tile-based world, objects often also encounter straight walls defined as lines, for example when a tile is blocked. The code above can easily be adapted to work with lines as well, allowing spheres that collide with walls to gracefully slide along them. In the case of walls, the tangent should be parallel to the wall and the rest of the code remains the same. The collision check is also straight-forward.
The following site explains the collision check between a sphere and a arbitrarily oriented line very well:
http://paulbourke.net/geometry/sphereline/
If you only need straight lines (on the border of tiles), the collision check is much simpler, and just comes down to checking the horizontal/vertical distance between the line and the sphere center, and seeing if it is larger than the radius.
4. Conclusion
The algorithm presented in this article will have spherical objects gracefully slide their way through a tile-based world. When they collide against each other, they will attempt to slide along each other, avoiding collision alltogether. I hope this guide will be useful for anyone who is developing a 2D game and needs a robust collision detection routine!
All feedback is of course welcome.
vrijdag 24 juni 2011
Dungeon Builder: third makeover & digging
As you might have noticed, the previous posts about Dungeon Builder followed quite quickly after each other. This is because I was writing a report of the first month of development over the course of a week, trying to catch up my blog with the actual development status of the game. Right now we're at this point; the screenshot at the bottom of this post shows the game in its current state.
After the second overhaul, I started working on the digging component of the game: the part where you expand your dungeon by digging more rooms, in order to improve your defense. However, I quickly noticed that the room-centric setup was much too limiting for this. The original engine was built around rooms, and you either had to dig rooms in one piece, or combine two rooms into one bigger room. This can be seen from the previous screenshots, where there are obvious rooms in a grid layout. This did not give enough freedom to the player, so I decided in another major overhaul.
I changed the engine into a more DK-style grid, in which you dig out squares of dirt to build rooms of any shape you want. It took something like 5 days to complete the overhaul, and when it was finished, I quickly realized I made the right call: this was so much better. But this made pathfinding a much more difficult task, so it took me a while to get the heroes and monsters to find their way to each other again.
I also added a brown color palette to make it look more like earth you're digging in, and I changed some of the game mechanics as well. For example, parties of heroes now enter the dungeon about every +- 30 secs, and you better be prepared by then. Previously, you could choose at which point the invaders came by clicking a button when you were ready.
Here's a screenshot of the current state of the game:
The playable area on this map is a circle. Dark brown means that you can't dig through. The light brown areas are rooms. Several imps (pink) and one skeleton (blue) are fighting a knight (cyan) at the bottom. The yellow areas indicate squares the hero hasn't explored yet. When the knight has won the battle, he will head out for one of the yellow squares to explore the dungeon further. Eventually, he will stumble upon the second line of defense at the top right, and will have to fight them too to get to the treasure. The 50's around the dungeon indicate that I am in build mode, and can dig out additional squares for the price of 50 gold.
After the second overhaul, I started working on the digging component of the game: the part where you expand your dungeon by digging more rooms, in order to improve your defense. However, I quickly noticed that the room-centric setup was much too limiting for this. The original engine was built around rooms, and you either had to dig rooms in one piece, or combine two rooms into one bigger room. This can be seen from the previous screenshots, where there are obvious rooms in a grid layout. This did not give enough freedom to the player, so I decided in another major overhaul.
I changed the engine into a more DK-style grid, in which you dig out squares of dirt to build rooms of any shape you want. It took something like 5 days to complete the overhaul, and when it was finished, I quickly realized I made the right call: this was so much better. But this made pathfinding a much more difficult task, so it took me a while to get the heroes and monsters to find their way to each other again.
I also added a brown color palette to make it look more like earth you're digging in, and I changed some of the game mechanics as well. For example, parties of heroes now enter the dungeon about every +- 30 secs, and you better be prepared by then. Previously, you could choose at which point the invaders came by clicking a button when you were ready.
Here's a screenshot of the current state of the game:
The playable area on this map is a circle. Dark brown means that you can't dig through. The light brown areas are rooms. Several imps (pink) and one skeleton (blue) are fighting a knight (cyan) at the bottom. The yellow areas indicate squares the hero hasn't explored yet. When the knight has won the battle, he will head out for one of the yellow squares to explore the dungeon further. Eventually, he will stumble upon the second line of defense at the top right, and will have to fight them too to get to the treasure. The 50's around the dungeon indicate that I am in build mode, and can dig out additional squares for the price of 50 gold.
Dungeon Builder: cistron switch
So I ended up with a lot of objects in the dungeon that needed to interact with each other on a neutral basis (ie no regulating object that takes care of communication - it's cumbersome). I again turned to Cistron, everyone's (well mainly my) favourite component-based architecture! I had to do a lot of recoding to fit the entire game into the Cistron system, but it was totally worth the wait: the final code was much simpler than the original prototype version.
But because of the switch, I have surpassed the time you usually take to prototype, so I guess I'm out of the prototype phase now :). Now that Cistron was in place, it became very easy to set up complex communications between different objects in the dungeon. For example, I experimented with heroes attacking each other once they realize one of them is carrying my treasure back to town, in order to capture it for himself. This resulted in quite amusing bloodbaths of tens of heroes bashing away at each other until only one survived, but it didn't add much to the gameplay, so I removed it (for now).
Because I didn't have any graphics at all, I was getting kind of annoyed playing the game myself. So I took it upon myself to spend a day or so building a somewhat attractive GUI to compensate for the total lack of interesting in-game graphics. Then it took another week to actually implement all the GUI interfaces (menu's, saving, loading, etc) until I finally got back to working on the actual game. Damn, GUI's are so much boring, boring work :(.
Either way, this is what the game looks like after the Cistron overhaul and the GUI added:
You have a hero (cyan) at the bottom fighting some imps (pink) stationed at different rooms. The imps are ranged creatures, so they shoot "fireballs" (red things) at the hero, resulting in some damage. The hero needs to get in close range to attack the imps so he's moving. When he dispatches of the imps, he will go for the treasure (gold) on top and head back to the exit.
Next up: digging!
But because of the switch, I have surpassed the time you usually take to prototype, so I guess I'm out of the prototype phase now :). Now that Cistron was in place, it became very easy to set up complex communications between different objects in the dungeon. For example, I experimented with heroes attacking each other once they realize one of them is carrying my treasure back to town, in order to capture it for himself. This resulted in quite amusing bloodbaths of tens of heroes bashing away at each other until only one survived, but it didn't add much to the gameplay, so I removed it (for now).
Because I didn't have any graphics at all, I was getting kind of annoyed playing the game myself. So I took it upon myself to spend a day or so building a somewhat attractive GUI to compensate for the total lack of interesting in-game graphics. Then it took another week to actually implement all the GUI interfaces (menu's, saving, loading, etc) until I finally got back to working on the actual game. Damn, GUI's are so much boring, boring work :(.
Either way, this is what the game looks like after the Cistron overhaul and the GUI added:
You have a hero (cyan) at the bottom fighting some imps (pink) stationed at different rooms. The imps are ranged creatures, so they shoot "fireballs" (red things) at the hero, resulting in some damage. The hero needs to get in close range to attack the imps so he's moving. When he dispatches of the imps, he will go for the treasure (gold) on top and head back to the exit.
Next up: digging!
dinsdag 21 juni 2011
Dungeon Builder: prototype
I chose C++ with SDL for the project. SDL seemed ideal to create a 2D, isometric/topdown game. C++ is my language of choice for pretty much everything and I have a HUGE library of classes and external libraries that I can immediately employ to get going quickly. I also chose not to bother with graphics, and go for abstract shapes, so I focus on the gameplay. Graphics can be added later.
The first focus was on getting a dungeon structure up, and being able to summon creatures. So after about a week, I had this:
A dungeon with rooms, treasure at the end, some imps (pink) that could be placed and a hero advancing through the dungeon. At this point, I was getting in trouble with my quick-and-dirty prototype implementation, because I needed complex interactions between creatures, heroes, projectiles thrown by ranged creatures, the dungeon itself and items on the ground. So I once again turned to my old workhorse: Cistron. Apparently I always end up using this framework that I developed a couple of years ago in pretty much every project I begin on. It's just such an incredibly natural way to model a world with different objects that interact with each other that I have a tough time imagining how to do it otherwise nowadays. My next post will deal with the transition to Cistron.
The first focus was on getting a dungeon structure up, and being able to summon creatures. So after about a week, I had this:
Dungeon Builder: gameplay idea
About a month ago, I came up with a new game idea that I thought was worth checking out. One of the most popular genres nowadays is Tower Defense. This genre, originating from Starcraft custom maps, became wildly popular in recent years because of games such as Desktop Tower Defense and Plants vs Zombies. The good Tower defense games are a lot of fun for casual and hardcore gamers alike, but there are some things that frustrate me about the genre.
The goal is to survive increasingly strong waves of heroes that attempt to raid your dungeon and steal away your treasure. Heroes will come in parties, and will behave pretty much like a player would in a dungeon crawler. They explore the dungeon maze you've built, kill creatures on the way, and try to get to the treasure.
In order to defend your treasure, you will have to summon creatures and place them strategically as your line of defense. Additionally, each creature has RPG stats that determine its role in combat, and an important part of the game is to position your defenses in such a way as to be prepared for the incoming party as optimally as possible. Place a tank creature at a choke point, with several ranged damage dealers behind it, and watch as heroes attempt to break your defenses with their own tactics.
This all happens in a persistent way. All throughout a campaign (which compares to RTS campaigns), you keep your dungeon. There's no levels to walk through. This makes you feel connected to your construction, as you are stuck with it for a long time. Because hero parties get stronger continually, you will also have to improve your defenses by summoning more creatures, relocating important structures, increasing your dungeon maze, etc.
This basic idea seemed quite appealing to me, so I set out to write a quick prototype for it.
- There is no persistence to your carefully constructed maze. Usually, the games are split up into levels, and you start from scratch each time, starting with the crappy turrets and building up to the awesome ones.
- Turrets are in themselves quite boring and stupid: they don't move, they don't think, they just shoot.
- The opponents are equally stupid: they walk on a pre-defined path to their certain doom.
The goal is to survive increasingly strong waves of heroes that attempt to raid your dungeon and steal away your treasure. Heroes will come in parties, and will behave pretty much like a player would in a dungeon crawler. They explore the dungeon maze you've built, kill creatures on the way, and try to get to the treasure.
In order to defend your treasure, you will have to summon creatures and place them strategically as your line of defense. Additionally, each creature has RPG stats that determine its role in combat, and an important part of the game is to position your defenses in such a way as to be prepared for the incoming party as optimally as possible. Place a tank creature at a choke point, with several ranged damage dealers behind it, and watch as heroes attempt to break your defenses with their own tactics.
This all happens in a persistent way. All throughout a campaign (which compares to RTS campaigns), you keep your dungeon. There's no levels to walk through. This makes you feel connected to your construction, as you are stuck with it for a long time. Because hero parties get stronger continually, you will also have to improve your defenses by summoning more creatures, relocating important structures, increasing your dungeon maze, etc.
This basic idea seemed quite appealing to me, so I set out to write a quick prototype for it.
maandag 4 april 2011
my game design story, part 2: late childhood
After a long delay, finally the second part of the story of my life. This part will somewhat overlap with the previous post in terms of time period, because the first post got a little too long and I could not interweave both parts of my childhood in a coherent story. This part of the story will be split in 4 sections, sorted chronologically, for a better overview.
Paper quests
As I was playing the defining games of my childhood, something in me woke up and decided that I wanted to make games like that myself. Because I was too young to work with a computer properly, nevermind program for it, I started drawing adventure games on paper. My first series was called Castle Quest (might sound familiar to some of you), quickly followed by all kinds of Quests inspired by the Sierra series. I was not pushed in doing this; it grew organically out of my obsession with drawing (and reading) Belgian comic books.
Instead of the linear, uncontrollable nature of comic books, I was more drawn to the interactivity of videogames, and started challenging (pestering) people in my environment to play my fantastic paper-based adventure games. They were just hundreds upon hundreds of pages of drawings if envorinments with puzzles in them that I would explain patiently to the player who was playing the game. I'm not sure the players enjoyed these mastodont adventures as much as I did making them, but they definitely were my first step in game development. I must have been 7 or 8 years when I made my first adventure.
Important games
After my early childhood, which was dominated by computer games and mainly focused on adventures, it was time to explore new worlds, and the Game Boy my dad brought back from a trip to Singapore did just that. With action/platform games such as Super Mario Land, Turtles 2, Mortal Kombat and so on, I discovered that games were more than just point-and-click adventures. I started drawing platform games on paper (seriously). The player would play with his fingers, avoiding obstacles by lifting their fingers in different motions, depending on which obstacle was to be avoided. To my surprise, these games were a huge success on the elementary school playground, and people would line up to play them. This was probably my first success as a game designer.
As I explored new game genres on the Game Boy, so did my dad on the PC. Games such as Sim City 2000, Transport Tycoon, Command & Conquer and others found their way to our home, and changed my view of what a video game could be. Now, I will discuss several of the most important games from this period of time, up until my transition to high school at age 12, which will be the third part of my story, and will start with Warcraft 2, and the introduction of Blizzard into my life.
Superlogo
While I explored these different genres, it dawned on me (and my dad) that I couldn't really keep making games on paper. Adventure games can be somewhat reproduced in paper form, but any of the games mentioned above cannot. When my dad brought home a package called "Superlogo: programming for kids" (1994), it changed my life.
This frankly quite brilliant package contained a Dutch programming language called Superlogo (based on LISP), which was designed to learn children to program. It also came with a very hefty Dutch manual which patiently learned the child step by step how to program complex software and games in the language. It was very well-written and easy to understand, and learned the child complex concepts such as encapsulation, functional programming, recursion and so on. It really got me hooked to not only programming, but game development as well. For more information about Superlogo, please refer to this article (Dutch).
Klik 'n Play
But, because it was a low-level programming language, it was still quite tricky to write complex games in it. My ambitions were too large for what I could realistically achieve with Superlogo. However, this problem was solved by the next game development package that my dad brough thome, called Klik 'n Play. Where Superlogo showed me what was possible but did not bring it within my grasp, Klik 'n Play did.
Klik 'n Play was a visual environment which hid the underlying programming behind a mouse-based interface. Instead of writing functions, you could trigger actions such as "destroy object x" on events such as "object x collides with y". It contained a HUGE library of animated clipart and backdrops for you to drag and drop in your games, and allowed you to write complex interactive games with just mouse clicks and some creativity. Things such as collision detection, platform movement, shooting, animations, and so on were already implemented for you, allowing you to focus on the creative side immediately. In Superlogo, writing collision detection was hell.
Klik 'n Play unleashed an unparallelled productivity in me: I literaly made hundreds of games (and never finished most of them). For years, I dropped "real" programming entirely and focused only on making games in Klik 'n Play and its two successors The Games Factory and Multimedia Fusion. Why? Because it abstracted away the low-level concepts and let you focus on the important and interesting side of game development: the game design. Klik 'n Play and its sequels are so good that even today, some of the most celebrated indie games were made in it. The best example is Knytt, a more than excellent platform game by Nifflas.
While Superlogo was important because it set me on the right track, Klik 'n Play (and its sequels) made it clear to me that there was really only one thing I wanted to do later. I directly credit Klik 'n Play for unlocking my creative side and encouraging me to explore it and actually do stuff with it. I seriously recommend to every parent of a 8-12-year old to get them a copy of one of Clickteam's products (for example, The Games Factory 2 released in 2006). This stuff is better than paint or clay or lego.
Paper quests
As I was playing the defining games of my childhood, something in me woke up and decided that I wanted to make games like that myself. Because I was too young to work with a computer properly, nevermind program for it, I started drawing adventure games on paper. My first series was called Castle Quest (might sound familiar to some of you), quickly followed by all kinds of Quests inspired by the Sierra series. I was not pushed in doing this; it grew organically out of my obsession with drawing (and reading) Belgian comic books.
Instead of the linear, uncontrollable nature of comic books, I was more drawn to the interactivity of videogames, and started challenging (pestering) people in my environment to play my fantastic paper-based adventure games. They were just hundreds upon hundreds of pages of drawings if envorinments with puzzles in them that I would explain patiently to the player who was playing the game. I'm not sure the players enjoyed these mastodont adventures as much as I did making them, but they definitely were my first step in game development. I must have been 7 or 8 years when I made my first adventure.
Important games
After my early childhood, which was dominated by computer games and mainly focused on adventures, it was time to explore new worlds, and the Game Boy my dad brought back from a trip to Singapore did just that. With action/platform games such as Super Mario Land, Turtles 2, Mortal Kombat and so on, I discovered that games were more than just point-and-click adventures. I started drawing platform games on paper (seriously). The player would play with his fingers, avoiding obstacles by lifting their fingers in different motions, depending on which obstacle was to be avoided. To my surprise, these games were a huge success on the elementary school playground, and people would line up to play them. This was probably my first success as a game designer.
As I explored new game genres on the Game Boy, so did my dad on the PC. Games such as Sim City 2000, Transport Tycoon, Command & Conquer and others found their way to our home, and changed my view of what a video game could be. Now, I will discuss several of the most important games from this period of time, up until my transition to high school at age 12, which will be the third part of my story, and will start with Warcraft 2, and the introduction of Blizzard into my life.
- Chip's Challenge (1989) only got to me several years after its release, when I was older. And I guess this is a good thing, because this game is HARD. Probably one of the hardest, most hardcore puzzle games ever made. But also one of the best ones. This is illustrated by the fact that, 20 years later, the game still sports a very active fan community, which are hard at work making new levels, sequels and so on. This game was a top-down game in which you move a guy around collecting computer chips to open up the portal to the next level. On your path are opponents with predictable movements (left-wall huggers, bouncers, etc) and hazards such as fire, water, and so on. One misstep kills you, and forces you to replay a level that might require hundreds of moves in which every single misstake is fatal. Crazy, but surprisingly addictive and fun, and I still recommend playing it today (I replayed the entire game a couple of years ago, and it was still fun).
- Super Mario Land (1990) for Game Boy was a masochistic game for the simple reason that it did not support save games. Every time you turned of your Game Boy, you had to play all from scratch again. And they didn't make the game easier to compensate either; Super Mario Land was quite tough. After months (perhaps years) of practice, I finally made it to the end. I can't recall any game in my life that took so long to finish in terms of years.
- Syndicate (1993) was a surprisingly adult and shocking game for the time, but I was too young to grasp this. Instead, I noticed a totally unique game, with very open-ended, nonlinear gameplay, complex depth and intense action scenes. This game is quite unique, even up to this day, and there hasn't really been a game like it since. It learned me that open-endedness can really add to a game's replayability, and can give the player the illusion that he is in complete control.
- Theme Park (1994) was the inspiration for the superhit Rollercoaster Tycoon a couple of years later, but this one had a more profound impact on me. Again, I was a little too young to understand the somewhat complex research aspect of the game, but it didn't stop me from having massive amounts of fun building, running and ruining theme parks. The theme of the game, which obviously has a great appeal to children, was very well integrated in the gameplay, and the excellent, accessible graphics made this game an easy sell to any child. Bullfrog was in a roll these days, these games (along with Dungeon Keeper and Theme Hospital) made Peter Molyneux my first idol game designer.
- Command & Conquer (1995) had a profound impact on not only me, but the entire game industry. While Dune 2 introduced this new genre called RTS, it was C&C that laid the foundations of the genre so well that it would take 10 years until people started deviating from the basic concept ideas of C&C such as resource gathering, base building and unit training.
- Sim City 2000 (1995) was one of those games that could really get you hooked. Even when you didn't really know what you were doing, such as me at the time (what the hell does a 11-year old know about finance and loans?) Building cities just speaks to people's imagination, and it was so well-done in this game that the only games that ever improved the quality of this one was the second sequel (Sim City 4).
- Civilization 2 (1996) was another game that pretty much fits the same description as Sim City 2000. It was quite perfect in its design, incredibly addictive and was built around an inspiring theme. It appealed to me naturally.
Superlogo
While I explored these different genres, it dawned on me (and my dad) that I couldn't really keep making games on paper. Adventure games can be somewhat reproduced in paper form, but any of the games mentioned above cannot. When my dad brought home a package called "Superlogo: programming for kids" (1994), it changed my life.
This frankly quite brilliant package contained a Dutch programming language called Superlogo (based on LISP), which was designed to learn children to program. It also came with a very hefty Dutch manual which patiently learned the child step by step how to program complex software and games in the language. It was very well-written and easy to understand, and learned the child complex concepts such as encapsulation, functional programming, recursion and so on. It really got me hooked to not only programming, but game development as well. For more information about Superlogo, please refer to this article (Dutch).
Klik 'n Play
But, because it was a low-level programming language, it was still quite tricky to write complex games in it. My ambitions were too large for what I could realistically achieve with Superlogo. However, this problem was solved by the next game development package that my dad brough thome, called Klik 'n Play. Where Superlogo showed me what was possible but did not bring it within my grasp, Klik 'n Play did.
Klik 'n Play was a visual environment which hid the underlying programming behind a mouse-based interface. Instead of writing functions, you could trigger actions such as "destroy object x" on events such as "object x collides with y". It contained a HUGE library of animated clipart and backdrops for you to drag and drop in your games, and allowed you to write complex interactive games with just mouse clicks and some creativity. Things such as collision detection, platform movement, shooting, animations, and so on were already implemented for you, allowing you to focus on the creative side immediately. In Superlogo, writing collision detection was hell.
Klik 'n Play unleashed an unparallelled productivity in me: I literaly made hundreds of games (and never finished most of them). For years, I dropped "real" programming entirely and focused only on making games in Klik 'n Play and its two successors The Games Factory and Multimedia Fusion. Why? Because it abstracted away the low-level concepts and let you focus on the important and interesting side of game development: the game design. Klik 'n Play and its sequels are so good that even today, some of the most celebrated indie games were made in it. The best example is Knytt, a more than excellent platform game by Nifflas.
While Superlogo was important because it set me on the right track, Klik 'n Play (and its sequels) made it clear to me that there was really only one thing I wanted to do later. I directly credit Klik 'n Play for unlocking my creative side and encouraging me to explore it and actually do stuff with it. I seriously recommend to every parent of a 8-12-year old to get them a copy of one of Clickteam's products (for example, The Games Factory 2 released in 2006). This stuff is better than paint or clay or lego.
donderdag 3 maart 2011
my game design story, part 1: early childhood
When I was thinking about what to post on this blog, I figured that it would be interesting for readers to learn how I got where I am now. This might inspire readers with similar ambitions to get their hands dirty, and to start working instead of dreaming. In a series of (possibly long) posts, I will tell you how it all started for me, some 20 years ago. This is the story of my life, and my life-long dream of becoming a game designer. Since my memory is pretty much a swiss cheese with more holes than cheese remaining, my timeline or recollections might be a bit vague; however, I will do my best to be as precise as possible.
My first contact with video games came through my father. He was always obsessed by modern technology, and this spectacular new invention called the "computer" quickly caught his attention. It was no wonder then that, from an early age, computers were prevalent on our houshold, and thus in my life.
My dad, an amateur programmer himself, programmed some basic BASIC applications to let me toy around with the computer, and learn some stuff in the meantime. My first contact with computers was a fact. After that, some educational DOS games followed, as well as the first "real" games I got in contact with: the King's Quest series, the Leasure Suit Larry adventure games, and a freeware (yes, in 1990) ASCII game called Castle Adventure. I, being a wee lad at the time, could hardly understand anything that was happening, and obviously (and perhaps fortunately), the erotic undertone of the Larry games was also lost on me. But these "computer games" surely fascinated me, and I quickly got the hang of randomly clicking the screen until something happened and then clicking some more.
From then on, games would be a constant, but not yet important part of my life. I would be playing games casually all throughout my childhood. Some stuck with me more than others. I will now briefly discuss the games that, in retrospect, influenced me most, in the order in which they were released. This was the golden age of adventures, and adventures were pretty much the only genre my dad played at the time (he also never bought Lucasarts adventures, so I missed those - caught up with them since then though). Most of the games in this list will therefore be adventures.
The Game Boy, while released in Europe in 1990, did not get to me until a while later. It would mark the start of the second part of my childhood, and will be discussed in the next post. By 1992, I had also started making games of my own: on paper. I will also elaborate on this is the next post.
My first contact with video games came through my father. He was always obsessed by modern technology, and this spectacular new invention called the "computer" quickly caught his attention. It was no wonder then that, from an early age, computers were prevalent on our houshold, and thus in my life.
My dad, an amateur programmer himself, programmed some basic BASIC applications to let me toy around with the computer, and learn some stuff in the meantime. My first contact with computers was a fact. After that, some educational DOS games followed, as well as the first "real" games I got in contact with: the King's Quest series, the Leasure Suit Larry adventure games, and a freeware (yes, in 1990) ASCII game called Castle Adventure. I, being a wee lad at the time, could hardly understand anything that was happening, and obviously (and perhaps fortunately), the erotic undertone of the Larry games was also lost on me. But these "computer games" surely fascinated me, and I quickly got the hang of randomly clicking the screen until something happened and then clicking some more.
From then on, games would be a constant, but not yet important part of my life. I would be playing games casually all throughout my childhood. Some stuck with me more than others. I will now briefly discuss the games that, in retrospect, influenced me most, in the order in which they were released. This was the golden age of adventures, and adventures were pretty much the only genre my dad played at the time (he also never bought Lucasarts adventures, so I missed those - caught up with them since then though). Most of the games in this list will therefore be adventures.
- Prince of Persia (1989) was a first in many ways. It was the first game to use rotoscoping (a form of motion capture) for its protagonist, resulting in unparallelled realism in animation. It also invented a new genre of platform games that is highly popular up to this day. It was also the first game that really got me hooked. I recall playing this game with my nephews whenever we were together and a PC was nearby; we played this game for hours on end, trying to figure out each level piece by piece. I played this game so much as a kid, that I can still finish the game at first attempt when I replay it today. For years, this was the game I wanted to make, and wanted to improve on. Many of my first attempts at making a game of my own were (failed) clones of Prince of Persia.
- King's Quest 5 (1990) is the first adventure I recall that I somewhat knew what I was doing. I had figured out how the inventory worked, and how I could solve puzzles to advance the game. The story was lost on my, since I could not read or understand a word of English at age 6, but I understood the main plot line my looking at the pictures. I could follow along with the epic quest of King Graham to get back his castle and beloved family, and boy did I get immersed for the first time! The cursed forest at the start really had me running scared, as did the creepy end sequence where you sneak around the house, avoiding patrols and setting everything up for the grand finale, which was an epic spellbattle with the evil wizard Mordack. Since I did not really know what I was doing and ignored all the hints scattered throughout the game, this was by far the most difficult scene in the game.
It's actually quite surprising that I finished this game at all (I also don't recall exactly how much I did myself, and how much my dad did), since this is considered one of the most unfairly difficult adventure games ever made, full of totally illogical and senseless puzzles which can stop any smart adult from ever completing the game. To be honest, the hint book I found in the box (I still have every game) also might have helped.
- Lemmings (1991) was a very smart puzzle game, which required quick reflexes, out-of-the-box thinking and a lot of patience. This game, developed by what would later on become Rockstar and make one of the most succesful game series of all time (GTA), truly was one of the best games of the time. Along with Prince of Perisa, it had me hooked playing the game for hours with my nephews every Wednesday when we would get together at my grandmother's to eat pancakes and play (videogames). Not so much a huge influence as a huge time sink to me.
- King's Quest 6 (1992). Now we get to the big one. If I would have to give one pivotal video game from my childhood, this would be it. By that time, I was old enough to understand the story and the context rather well (still without understanding a word of English), and I was old enough to immerse myself in the experience completely. This inspired story of prince Alexander, who would set out to a far away island penisula to save a princess, only to get caught in a web of local politics, conspiracies and mythical lore, is lauded as one of the very best adventure games of all time, and rightly so. It contains many fantastical characters, and mashes together some of the most interesting myths and fairy tales of different civilizations into a surprisingly adult game about death, betrayal and love, with different endings depending on how you play the game (a first in video games?).
Playing this game at age 8 was like walking through the fairy tale stories of your childhood, while you were still a child! Whether I was exploring the maze of the minotaur, fixing the relationship issues of the red and white queen of chess, deceiving the seven dwarves or talking to death himself: this game captivated me from start to finish. As much as Prince of Persia inspired my first game design endeavors, King's Quest 6 inspired my creative writing and drawing.
- Eco Quest 1 (1991) and Eco Quest 2 (1993), two somewhat educational adventures written especially for children, also influenced my imagination greatly. The first one was set in a polluted sea, while the second one was set in a polluted rainforest. In both games, the player played a young boy who would set out to solve the problems of the local population and take care of the evil men who were destroying their ecosystem. These games were quite a lot easier than the King's Quest series, and brought me a lot of fun as a kid. Several iconic scenes, such as the one in which you explore the lost Indian City of Gold (called El Dorado) or the one in which you explore a sunken Greek-like city which was re-inhabited by marine animals, have greatly increased my already quite vivid fantasy.
- Robin Hood: Conquest of the Longbow (1992) was another game that really pushed my fantasy into overdrive. This game (loosely) tells the story of Robin Hood, reimagined by Christy Marx. It contains all the parts of the classic Robin Hood story, but imbues it with a rich story, interesting, multifaceted characters and a bit of celtic druid magic. This game was quite dark at times, featuring some pretty dreadful imagery and adult themes (witch burning, oppression of the population, corruption, religion fanaticism). The puzzles were smart, and imaginative, featuring things as hand reading and magic gemstones. (This is probably where my fascination for different gemstones started). This game is also regarded as one of the best games of the adventure era, and is a must-play for anyone to date.
- Laura Bow 2: The Dagger of Amon Ra (1992) is a horror detective game set in an Egyptian museum were suddenly a horrendous murder takes place. The building is locked down, and anyone is instructed to remain inside until the murder is solved by a detective on the scene. However, more murders happen, and eventually Laura Bow (the protagonist) must solve the mystery on her own lest she be killed in a violent fashion as well. This game, while a very good (and absurdly difficult) detective game, is only mentioned in this list because it first confronted me with another emition: terrifying fear. When I watched my father play this game late at night, one of the murder scenes got me so scared that I could not sleep for the entire night. In retrospect, the scene is quite silly, but it really shocked me to death as a child. This is the first and last time in my life that a game, movie or anything else got me so terrified. No horror movie, horror game or shock movie on the internet shocked me so deeply as this game. Which is, I guess, quite an achievement on its own, and a reason to put it on this list.
The Game Boy, while released in Europe in 1990, did not get to me until a while later. It would mark the start of the second part of my childhood, and will be discussed in the next post. By 1992, I had also started making games of my own: on paper. I will also elaborate on this is the next post.
woensdag 9 februari 2011
why java sucks for game development
In my previous post on GWT, I praised how easy it is to develop a complex web application with a server backend with it. You are also saved from having to write code in javascript, which is obviously a very good thing, as javascript is one of the worst languages ever designed. However, you're still programming in java; and java is a terrible language for game development. Defenders might argue that it's a great language to write clean, modular game code; that its performance has greatly improved over the years; that it's different from writing games in c++, but not necessarily worse. I argue that it is. And here's why.
- No stack variables. This is the big one. Every variable (except primitive types) is a pointer, and is allocated on the heap. This is great for large objects, but not so great for smaller ones that are allocated all the time. Allocating an object on the heap has obviously been optimized to a great extent by the java compiler, but it's still orders of magnitude slower than stack variables. And you're also subject to the whims of the uncontrollable garbage collection mechanism of java, which makes it unpredictable.
This issue arose when I was writing an AI opponent for the Line Wars game. Writing AI for a board game comes down to traversing a HUGE tree, repeating the same relatively simple function millions of times in a recursive manner. Up to this point, I was using a Coordinate class, which just contains x and y members and some functions to manipulate these. This is much cleaner than having separate x and y ints for every coordinate you're working with. However, since I was allocating these objects in the recursive functions, the entire algorithm slowed down incredibly, because I was allocating millions of tiny objects on the heap. Additionally, the garbage collection couldn't keep up, and our-of-memory errors quickly emerged, due to leftover, unused Coordinate objects from previous function calls not being deleted fast enough.
To fix this, I had to pre-allocate all the relevant Coordinate objects and re-use them. In some places, I just removed the Coordinate and replaced it by two separate int's, resulting in much less readable code. None of these were a good solution, but at least I could move on.
A second, less obvious consequence of this is that it's impossible to efficiently return two values in a recursive function. In C++, you would just return a struct with the data in it, which would be stored on the stack. Or you could use pass by reference variables to return the data. Since java does not support pass by reference and always allocates on the heap, there is just no way to cleanly and quickly return more than one primitive type value in a function.
- Automatic garbage collection. For many applications, such as desktop or corporate tools, automatic garbage collection means less error-prone code, less memory leaks and an all-round faster development time. In game development, it can cause you nightmares. Basically, you never know when the garbage collection is going to happen, so you are at the whims of the virtual machine. You can suggest to the VM that it needs to garbage collect by means of the System.gc() function, but this is just a suggestion, and nothing tells you that the VM will listen. In highly recursive code with no stack variables, not having control over the garbage collection can cause serious troubles, as described above.
- No operator overloading. This one is pretty obvious. Ever did some heavy duty matrix calculations with java? Then you surely noted how your code quickly started looking like a terrible unreadable mess of getters, setters and other function calls. Operator overloading is great, because it allows the programmer to map functionality to symbols that logically represent this functionality, in a infix notation (the operator is placed BETWEEN arguments). Function calls use a postfix notation: the function is mentioned first, followed by its arguments. This is counter-intuitive, especially in mathematics, where (mostly) everything is infix. ((A * x) + B) / C is just much cleaner and easier to read than B.add(A.multiply(x)).divide(C).
Oh, and just for the record: this method of matrix manipulation in java will assign a shitload of temporary, quickly discarded objects on the heap, once again slowing down the entire calculation considerably.
vrijdag 4 februari 2011
GWT web development
The Google Web Toolkit is an extremely powerful tool for web development. It basically allows you to program a website in java as if you were designing a Swing application, and then compile it to html and javascript and run it in your browser. It comes with all sorts of incredible tools and features, such as:
Setting up a PHP backend is trivial, but interfacing with it is a little bit more of a challenge, as you have to handle the serialization of data yourself. This means a lot of tedious json/xml parsing and object creation. Either way, the choice is up to you, and GWT is fantastic in both scenarios.
The one main advantage of GWT is also its main disadvantage, in my opinion: you are programming in java. Java is a terrible, terrible language for programming games in. In between the total lack of control over your own heap, the lack of multiple inheritance, the lack of stack variables and the impossibility to write readable mathematical code, java is a pain in the ass to program games in. But it's still better than writing directly in javascript and html, so I guess I can live with that problem.
I have been experimenting with several GWT projects in the past month. Line Wars was my first project, and even though it isn't very succesful (nor profitable), it was a good learning school, and it really opened my eyes to the possibilities of GWT development with HTML5 canvas. The canvas context is an incredible versatile and complete drawing environment (much more so than OpenGL or SDL!), and with recent optimizations in javascript, it is no problem anymore to run an entire game in javascript and draw it on canvas. I will write a post mortem on Line Wars in one of the following posts, even though the game is not technically dead yet (I am still working on an AI opponent).
- Support for real-time debugging in your browser. No need to compile to javascript first: with a simple plugin, you can debug your java app directly in your browser as if it's a site. When using Chrome, it also provides very detailed performance and profiling information.
- Built-in webserver so you can test everything locally (use Wampserver to run a local MySQL database on Windows, by the way, it's the best).
- Java interfaces for lots of popular API's such as HTML5 Canvas, Youtube, Facebook, etc.
Setting up a PHP backend is trivial, but interfacing with it is a little bit more of a challenge, as you have to handle the serialization of data yourself. This means a lot of tedious json/xml parsing and object creation. Either way, the choice is up to you, and GWT is fantastic in both scenarios.
The one main advantage of GWT is also its main disadvantage, in my opinion: you are programming in java. Java is a terrible, terrible language for programming games in. In between the total lack of control over your own heap, the lack of multiple inheritance, the lack of stack variables and the impossibility to write readable mathematical code, java is a pain in the ass to program games in. But it's still better than writing directly in javascript and html, so I guess I can live with that problem.
I have been experimenting with several GWT projects in the past month. Line Wars was my first project, and even though it isn't very succesful (nor profitable), it was a good learning school, and it really opened my eyes to the possibilities of GWT development with HTML5 canvas. The canvas context is an incredible versatile and complete drawing environment (much more so than OpenGL or SDL!), and with recent optimizations in javascript, it is no problem anymore to run an entire game in javascript and draw it on canvas. I will write a post mortem on Line Wars in one of the following posts, even though the game is not technically dead yet (I am still working on an AI opponent).
game development models
Thanks to digital distribution and social platforms such as Facebook, a lot of new development models have popped up that can earn you a good amount of money. Since I will be financing myself without any income until my first game is finished, I do need a good business plan to earn this money back. Right now, I am considering the following three models (or game types):
- Facebook/web games: as Zygna clearly demonstrated, facebook games, even without ads, are a viable way to earn millions. However, their business model is dubious to say the least. I don't like games that give you an advantage over other players if you pay money; I have always opposed this approach in Castle Quest. In order to make a succesful webgame, I would need a different business model. League of Legends has an interesting model, in which they offer part of their content for free, but require that you pay for additional content, without giving a disadvantage to non-paying players: they just have less variety in the heroes they can choose and how to customize them. Another option is to go for a subscription fee, or offer the full package as a one-time buy, just like normal standalone indie games.
Advantages:
- Low setup cost: a server is all you need to get going, and you can expand your park or go to cloud services if the need arises.
- I have a lot of experience with this genre through Castle Quest 1 and 2, as well as a huge fanbase which will immediately jump on a new webgame I develop, giving it a head start.
- It's easy to reach a huge audience through social networking sites.
- Games are almost automatically multiplayer, without requiring special effort.
Disadvantages:- For reasons quite unclear to me, people are still very averse to paying for webgames, while they have no problems paying money for standalone games, even though there doesn't have to be a major difference between them anymore in terms of quality. HTML5 Canvas even allows for 3D games played directly in your browser (see the Quake 2 GWT project)! Yet, it seems like, of the three models discussed here, this is the one which is the least predictable in terms of earnings. Will people be willing to pay for your additional content? Who knows?
- Webgames are by definition asynchronous: this disables a lot of game genres. Every (multiplayer) game which depends on twitch action is not an option.
- Mobile games: mobile games are obviously a booming market. Success stories abound, with trivially simple and unoriginal games such as Doodle Jump gathering 5 million sales. The altometer, touchscreen and GPS open up new ways of control that were previously unavailable. Money is earned through direct sales of your games on the iPhone and Android markets, and games are often priced very low (below €1). This model lends itself more to simple, yet creative games that can be played for a few minutes and put down again without losing any progress. Most successful mobile games fall into this category.
Advantages:
- If your idea is good, you can probably earn quite a lot of money with this. Everything hinges in your idea though; a good, balanced game concept will get you less far than a unique and fun idea.
- Huge market ready to be explored, and very easy to get your game to your customers.
- New control methods allow for unparallelled originality. This model is most likely to spawn new genres.
Disadvantages:
- Extremely inaccessible industry. If you want to develop for iPhone (and you do want that), there are only a few options. Firstly you can get a macbook and develop on that. Secondly you can install MacOS on your PC or run a virtual machine, and develop from there, but as far as I can read, this is quite a tricky undertaking. Thirdly, you can use one of the cross-compiler tools such as Dragonfire SDK (tried it, WAY too limited), Unity 3D (you're scripting your game), or Adobe Flash. Of these, Flash and Unity 3D are both sensible options for serious projects, but still have quite a large learning curve, as I have no experience with actionscript of C#. If you also want to develop for Android, again Unity and Flash seem to be the only good options you have. Not ideal at all.
- Some game genres just don't work well on a small screen, or without a mouse. I have played several ports of strategy games on a mobile, and it just doesn't feel right. Basically, you need to avoid clicking buttons repeatedly with the touchscreen, because they feels slow and cumbersome. Any game which requires a repeated hitting of buttons is not a good mobile game.
- Standalone game: the oldest trick in the book, but it still does the job. Thanks to the digital distribution revolution, publishing a standalone game is as easy as putting it up on a website and placing a paypal button next to it. Distribution platforms such as Steam make it possible to reach huge audiences with minor cost overhead, once your game has been picked up. Popular websites such as TIGSource can help your games reach an enthousiastic audience quickly.
Advantages:
- I can develop in C++, which is my language of choice. I also have the most experience with this language, and have compiled and written a huge knowledge and library base over the years. Also, most of my most promising and developed projects at the moment fall into this category.
- The Independent Games Festival seems heavily biased towards this model. This may be because mobile and webgames are just not on par with standalone games yet, but there's no objective reason for them not to be (besides that those industries are not mature enough yet, maybe). Mobile games are even put into a separate category (but are, theoretically, still eligible for the grand prize). Since the IGF is a very important source of income (through awards) and advertisement (through media attention), this is actually a huge advantage for the standalone game.
- Developing a standalone game just gives the most freedom in terms of design.
Disadvantages:
- Requires the largest allround investment of talent: a standalone game cannot go without proper graphics and sound, for example, while a webgame can.
- More difficult to prototype, because it always requires substantial effort to prototype something using SDL or OpenGL.
- Multiplayer is tricky, hard to implement and can be quite expensive. Between dedicated and central server architectures, no one choice is the best. Dedicated servers require a minimum popularity for the game so that people set up their own servers. A central server can cost a substantial amount of money right from the get-go.
the state of the game industry
Five years ago, before I started my Ph.D, I also considered entering the game industry. However, at that time, I felt like the game industry was in a terrible slump, and wasn't ready for what I wanted to do. Indie games sales hadn't really picked up yet, Steam was still mainly a distribution tool for Valve games, and Facebook hadn't even been launched yet for the public. The game industry was a totally different world. I didn't feel like being a small cog in a large sequel-producing machine, and there didn't seem to be any other option at the time. I even got personally disappointed in the game industry as a whole, because all I got were sequels to the same games I had been playing for years.
But sometimes the stars align perfectly. Now, 5 years later, right as I am about to finish my Ph.D, things have changed completely. Whole new markets have opened up with endless new possibilities. Indie games through digital distribution are a viable way to earn money. Facebook games earn millions, and most of those games still kind of suck. The mobile market opens up the game industry to a whole new demography, and enables revolutionary control methods thanks to the touchscreen and GPS. After years of plowing through the desert of mediocrity, we have finally reached the lush shores of creativity. The perfect time for me to join the fray!
I have been doing a lot of research lately, following up on blogs and success stories of other game developers. I am starting up new prototype projects all the time, without finishing them. The idea is that, when I wrap up my Ph.D, I will pick the most promising of all these projects, and develop it for real. This will allow me to make an educated choice, instead of picking a promising idea randomly and going at it without knowing if it will lead to anything at all.
In the next blog post, I will discuss the three development models that I am considering.
But sometimes the stars align perfectly. Now, 5 years later, right as I am about to finish my Ph.D, things have changed completely. Whole new markets have opened up with endless new possibilities. Indie games through digital distribution are a viable way to earn money. Facebook games earn millions, and most of those games still kind of suck. The mobile market opens up the game industry to a whole new demography, and enables revolutionary control methods thanks to the touchscreen and GPS. After years of plowing through the desert of mediocrity, we have finally reached the lush shores of creativity. The perfect time for me to join the fray!
I have been doing a lot of research lately, following up on blogs and success stories of other game developers. I am starting up new prototype projects all the time, without finishing them. The idea is that, when I wrap up my Ph.D, I will pick the most promising of all these projects, and develop it for real. This will allow me to make an educated choice, instead of picking a promising idea randomly and going at it without knowing if it will lead to anything at all.
In the next blog post, I will discuss the three development models that I am considering.
introduction
Hello, and welcome to my new blog! The goal of this blog is to document my adventures (both successes and failures) as I work to become an independent game developer. As so many people out there, I have dreamed of earning my money with game development since I was a child. Many aspire this dream, and few succeed: I am well aware of that. I do, however, believe that several things set me apart from the typical "I have a great idea for a game, can anyone learn me 3D Studio Max so I can make it?" guy you see all the time on the gamedev.net forums or other similar websites.
First and foremost, I have been programming games since I was 11 years old (I am 26 now). Over the years, I have programmed hundreds of small to medium sized projects, but left most of them unfinished. My first experience as a coder was learning Superlogo, a programming language developed specifically for children. Then I moved on to Klik 'n Play, a graphical programming tool that has since spawned a lot of sequels (The Games Factory, Multimedia Fusion), which are still used today to succesfully develop commercial games (see the Knytt games, for example). I then moved on to scripting languages such as the mIRC scripting language, in which I wrote an entire RPG, and then finally PHP. In PHP, I developed Castle Quest 1 and 2. The second game was released to great success in 2002, and is still played up to this day, peaking at 2000 active players a couple of years ago. Today, about 800 active players remain. Since the release of Castle Quest 2, I have developed many small projects, most of which have been unfinished as of yet.
I also have a master's degree in computer science and will soon (hopefully ;)) have a Ph.D in computer science as well. I have a lot of experience in C++, having developed several libraries and games in it in the past (see, for example, the Cistron component-based architecture). I am by no means a newbie to programming, and am quite verse in most of the relevant modern programming languages and paradigms.
And finally, I have a real, genuine passion for computer games. And true passion and dedication can get you far. I hope that my passion, combined with my computer science experience and experience developing and finishing games will be enough to make this undertaking a success!
First and foremost, I have been programming games since I was 11 years old (I am 26 now). Over the years, I have programmed hundreds of small to medium sized projects, but left most of them unfinished. My first experience as a coder was learning Superlogo, a programming language developed specifically for children. Then I moved on to Klik 'n Play, a graphical programming tool that has since spawned a lot of sequels (The Games Factory, Multimedia Fusion), which are still used today to succesfully develop commercial games (see the Knytt games, for example). I then moved on to scripting languages such as the mIRC scripting language, in which I wrote an entire RPG, and then finally PHP. In PHP, I developed Castle Quest 1 and 2. The second game was released to great success in 2002, and is still played up to this day, peaking at 2000 active players a couple of years ago. Today, about 800 active players remain. Since the release of Castle Quest 2, I have developed many small projects, most of which have been unfinished as of yet.
I also have a master's degree in computer science and will soon (hopefully ;)) have a Ph.D in computer science as well. I have a lot of experience in C++, having developed several libraries and games in it in the past (see, for example, the Cistron component-based architecture). I am by no means a newbie to programming, and am quite verse in most of the relevant modern programming languages and paradigms.
And finally, I have a real, genuine passion for computer games. And true passion and dedication can get you far. I hope that my passion, combined with my computer science experience and experience developing and finishing games will be enough to make this undertaking a success!
Abonneren op:
Posts (Atom)