AI in Swords & Soldiers (part 1)

My blog has passed the 12,500 visitors mark! Awesome! And that in just the first four months! Thank you for visiting, and I hope my posts will remain interesting enough to visit here! ^-^

Creating good AI for a strategy game is a notoriously difficult task. AI design is of course never easy, but for strategy games, the complexity of options and situations is incredibly high. I think Swords & Soldiers is the first game for which we achieved really good AI in one of our games, so I figured it would be interesting to see how we got there.



When I was studying computer science, I had high expectations of how AIs worked. I expected there would be these awesome learning and analysis algorithms, and AIs would make incredibly smart decisions. Then I finally got to an actual AI course...

It turned out that the field of AI either solves really simple problems, like chess (yes, chess is incredibly simple in comparison to a realtime strategy game, let alone in comparison to the real world!), or only offers a huge number of nice and efficient helper algorithms, like pathfinding. Real decision making in complex situations is in essence an unsolved problem and as far as I can tell, it won't be solved any time soon.

Totally disappointed, I wondered how actual game AI was made. It turned out that most game AI is completely scripted. There is nothing intelligent about it. Just long rows of if-then-else-if-then-else. To spice it up and add some variation, some randomness may be put in, but that is not worth the term artificial intelligence either. Games where an AI can really make smart decisions, which were not explicitly scripted by an AI designer, are very rare (Black & White's Decision Trees spring to mind).

So, scripting. Swords & Soldiers is no exception. The trick to scripting an AI is to simply add as many specific situations as possible, and script a smart reaction to each of them. If you can define hundreds of different situations and their reactions, then you can achieve the quality of AI that is seen in most games today.

Now the trick is to script in a smart and manageable way. For a school project I have at some point scripted AI by programming long if-then-else structures in C++, but this was terrible. It takes a long time to program and it is incredibly difficult to have a good overview of this, so it is also very difficult to keep it free of bugs.



So for Ronimo's first official game as a company (which was cancelled, by the way), we wanted to do things differently, so we put in the LUA scripting language. Adding scripting to your games is all the hype and big games like World of Warcraft contain tons of script code like this. Scripting has the benefit that you don't have to compile any more, and that a game designer can write the AI scripts.

However, I have concluded that LUA is terrible for this purpose. Scripting complex AI in LUA is just as difficult as in C++, so you basically still need a good programmer to do it. Luckily, though, one of our designers has some serious scripting skills. But you still don't have any overview of the structure of your AI, and it is a lot of work to expose all the necessary data from C++ to LUA. As our enemies became more complex, it became more and more difficult to find and fix bugs in them. So that didn't work out either.

Around the time that I was totally fed up with LUA, I discovered a great article by Bungie on how they had built a Behaviour Tree system for Halo 2. At the time, Halo 2 was well known for its great AI, which would do things like flanking the player and working together as a team.



The basic idea of behaviour trees is that you have conditions and actions. If conditions are met, then certain actions are executed. In many ways, they are just a graphical representation of an if-then-else structure.

So, we set out to build a graphical behaviour tree editor. (Note that in this case, when I say "we built", I actually mean "an intern built". ;) )



We are really happy with using behaviour trees. Our designers make the coolest things with them, and as a programmer, I don't need to be involved in everything they want to make anymore. We are using them again in our Secret New Game, even though that is a game in a totally different genre than Swords & Soldiers!

Next week, I'm going to zoom in a bit further on how those Behaviour Trees work exactly in Swords & Soldiers and how they accidentally also became our story event scripting system.

Edit: here is part 2 of this blogpost: AI in Swords & Soldiers (part 2)

The endless possibilities of art styles

Last Wednesday I did a five-minute presentation at Ignite Amsterdam 4. Since I care a lot about the point I was making there, I have created an online version of it. Enjoy!

Eufloria

Proun

Zonderling by Marissa Delbressine

If you yourself are experimenting with unique styles, then please post a link below, since I would love to see them! ^-^

Ow, by the way, while sitting behind my computer I heard/hurt rumours that today is Christmas, so:

(Awesome image by Elsje Bakker)

Designing levels without tools

One of the most interesting challenges I constantly meet when developing games, is to make cool things with a minimum effort. For Proun I am all alone and at Ronimo Games we have relatively too few coders to really work comfortably. So getting the maximum result out of a minimum effort is incredibly important.

When we built Swords & Soldiers, we didn't have a level editor yet. We have our own 2D engine at Ronimo Games, the RoniTech, but the RoniTech 1 that is used in Swords & Soldiers was still very bare bones at the time. We are currently working with and on the RoniTech 2 and have lots of cool in-game level editing and graphics editing tools, but for Swords & Soldiers we had to come up with some smart workarounds to design level graphics without having a real tool to do it with.

The core information of a level is where goldmines and towers are, what the height of the landscape is, and what type of ground it is (rock, snow, grass, etc.). We made designing this possible in a crude and simple way: in a Notepad file, each line contains information about one of these categories. Since the game essentially plays on a line, this is actually very simple to understand and edit and worked really quick for our designers.



To give our artists some room to create places of interest in the level, I gave them the possibility to define the exact position of props as well. They had a couple more lines for this and a prop sheet with a character per prop. By typing these characters in Notepad, they placed props in the level. This has an incredibly hardcore hacking feel to it, but I simply didn't have the time to create anything better (creating an entire console game with only one full-time programmer is, euhm, interesting...). It did give our artists enough freedom to make some fun areas, though, so the results were good.



The final part of the levels is the backgrounds (and foregrounds). We have lots of parallax layers and each layer is at a different distance from the camera. Also, the background layers often contain loads of objects per level. Since perspective is involved here, Notepad was out of the question. And without a graphical tool to design that, we had to choose a different solution here.

We came up with a procedural system where artists would create background elements for different layers, and the game would place these elements at random positions in their layers. Artists described to me which layers they wanted (nearby trees waving in the wind, medium distance hills, far away mountains, clouds, etc.) and I created code to place them. I did give our artists the possibility to remove layers or make them extremely dense, so that they could create deserts, mountain areas and forests.



The obvious downside of this approach is that it is very difficult to create unique places per level. With a real graphics level editor, artists could have placed specific eye-catchers in certain levels, like a city in the distance, or a palace just behind the field of war. This was impossible with the lack of tools for Swords & Soldiers.

Since we have a limited amount of background elements to generate levels from, repetition looms. So the artists requested two forms of control over that: one is simply a background gradient per level. The other is an atmospheric fog gradient, also per level, that is overlayed over the objects that are further in the background.



Despite the limitations, we managed to create a game with rich graphics that got great review scores. The smart choices described above made it possible to achieve that with only one programmer, which I am really proud of. Obviously, though, the real credit goes to our art team, who made some really compelling artwork. To quote IGN: "One of the best-looking games on Wii."

(Did I already mention I feel very proud of Swords & Soldiers? ;) )



PS. For those interested in some of the most hardcore programming topics: Jelle van der Beek, lead engine programmer at Vanguard Games (formerly known as W! Games) made a cool tool to analyse memory allocations and memory fragmentation. Although I have to admit that none of the problems he solves with this tool are relevant for the scale of games that we make at Ronimo (even though we do make real multiplatform console games), he shows some clear examples of the complexities of the topic, making this a very interesting presentation indeed for hardcore coders: Heap Inspector Demo video

All the settings

An important part of being a programmer at a game development company, is creating things in such a way that game designers can do their job. They get to fiddle around with the gameplay, while programmers build the technology. At Ronimo Games we have built a whole suite of tools for designers to work with, and I personally think the settings system is the most important. The nice part is that it was also the easiest to build.

At its core, this is a very simple thing. We have a text file with lots of values that our designers can tweak. For example, for each unit, the designers can set the health, price, walking speed, weapon's range, and a lot more. In Swords & Soldiers, we have some 600 gameplay settings like that.



A programmer creates these settings, and then a designer experiments with them to choose the right value for each of them. To do that, the designer needs to see the results of his changes quickly. Now I would like our designers to work with that as fluently as possible, so I built the feature that by pressing F5 in the middle of the game, they can reload all the settings. So they can constantly switch between settings and game using alt+tab, and use F5 to reload on the fly. Usually there is no need to restart the game all the time.

Technically, this is very simple to do. The key aspect is to use a struct for the settings and keep pointing to that. Never copy a value from the struct, because the copy won't change if the struct does. Thus when F5 changes the values in the struct, all the gameplay immediately uses the new values.

Depending on your needs, lots of variations to such a settings system can be chosen. In Proun I don't have the F5 mechanism, but I do have the possibility to change all the settings per level. So in the third track, I could easily make boosts last twice as long as in the other tracks, which happened to fit the track design better.

One of my first implementations of this system was De Blob. There we even implemented sliders in the game to allow designers to quickly modify properties, but we learned that as the number of settings explodes, these sliders didn't work that well. Since they were also a lot of work to build, we have simply used Notepad to modify settings ever since.

I would like to also talk about Ronimo's Secret New Game here now, since we have a much more advanced settings system for that, but that will be for another day. After all, the game is still Secret (tm) right now.

A settings system like this is so simple to build, that I think you should even create something like it for the smallest student games. It is also something that you can build once and then reuse in all your games after that. In my opinion, fast gameplay tweaking options are an absolute requirement for good game design.

The horror that is PC development

Swords & Soldiers is now out on PC and Mac on Steam! Buy it from SwordsAndSoldiers.com and use the coupon-code "sinterklaas" before December 5th to get a 30% discount!

In the past two years I have released my first games as a programmer on the Playstation 3 and Nintendo Wii. As I was told beforehand, the most evil part of console development are the certification requirements. Sony, Nintendo and Microsoft have long lists with hundreds of demands that you must meet in order to be allowed to release your game on their platform. These are all purely technical and are about topics like: "Pause the game if the controller runs out of batteries", or: "Show this message when the harddisc is corrupted."

Going through those lists and implementing all of it is incredibly boring work and has little to do with making cool games. However, last week I learned that PC development is actually a lot worse! On consoles, at least all of the requirements make sense, and since you know exactly on what hardware your game will run (all Playstation 3s are essentially the same), it is quite easy to test for. How unlike PC development...

Last week we launched Swords & Soldiers on the PC and the amount of things that can go wrong on all these different combinations of videocards, drivers, Windows versions and user settings is just terrible. Knowing the hardware on consoles suddenly makes them seem incredibly simple to develop for!



The main culprit on PC is the videocard, so I figured it would be interesting to have a little look at the kind of issues we came across during development of various games.

One thing most graphics programmers know, is that you should use power of two (PoT) textures, so resolutions should be like 128, 256, 512, 1024 and 2048. However, this is only relevant for pretty old videocards, since all modern videocards can handle other resolutions as well. Because of our animation system, we often have to round values up, so an animation sheet of 600*512 pixels becomes 1024*512 pixels. That is a huge waste! So to save a lot of space, we don't use power of two textures in HD. Since older computers also need to run Swords & Soldiers, we added a low-res SD mode where all textures are power of two.

Now I would like to detect whether the videocard can run in HD, and then hide that setting if the videocard cannot handle non power of two textures. But how do we detect that? There are some OpenGL extensions related to it, so I tried checking for those. However, some videocards don't have these extensions, yet they can run in HD anyway. I wasn't able to find a definite way to detect this (although I guess greater minds will know one), so I ended up allowing everyone to select HD and showing a message that tells the user to play in SD if the game looks broken otherwise. Pretty lame, but at least it is a clear solution!



A weird issue I came accross while working on Proun, is that certain really old onboard Intel videocards cannot handle objects with more than 65536 vertices. This only happens on some very specific old Intel cards and is okay anywhere else. Since Proun is a hobby project and splitting meshes for this would be quite some work, I ended up not fixing this one.

One of the simpler hardware differences to work with is shader versions. Vertex and pixel shaders can have all kinds of features, depending on the videocard and the DirectX version. However, programming for these isn't that difficult, because shader versions are always backwards compatible. So if for example you would write a shader for version 2.0, then it will definitely also run on 2.x, 3.0 and 4.0. There are no weird combinations here!



However, there are those videocards who think it is okay to lie. While developing De Blob, I learned that there are videocards that claim to be able to do shader 2.0, while they really don't. So I asked that videocard, "Can you do shader 2.0?" and the videocard said: "Yeah, sure, no problem!" I then tried to load the shader, and the videocard simply refused. How is one to program for that kind of weirdness?



The final example I would like to discuss here is one that I am a bit ashamed of, because Swords & Soldiers actually launched with this issue and I had to release a patch on Steam yesterday to fix it. Swords & Soldiers has a dynamic font rendering system, which means that we only load those characters that the game actually uses into video memory. This way we can handle the enormous number of characters needed for languages like Japanese and Chinese. Now we only implemented this after we did extensive tests on all kinds of videocards and we totally forgot to test again, so it turned out about 1% of users could not see any texts in the game at all. Pretty lame.

I haven't been able to figure out why this happened on those videocards, but I do know that the OpenGL function glTexSubImage2D was the cause. So in yesterday's patch I built a workaround that doesn't use that function. For more technical details on this problem, have a look here.

So, I conclude that PC development is actually more difficult than console development!

If you have any fun or interesting examples of rare hardware/driver/OS differences that break games, then please share them by commenting beneath this post. I'd love to hear about your experiences! ^-^

Coloured light in Proun

(At Ronimo Games, the Dutch game developer where I am lead programmer, we are currently looking for a coder with experience on the 360 and/or PS3. Interested? Have a look here for more information!)

Last weak I talked a bit about the technical side of lighting in Proun. This week, let's have a look at the more artistic side: the strange light colours I chose for each level.

A very common lighting setup among 3D artists is to let the sky emit a soft blue light, and the sun a bright yellow. This of course makes sense, since these are the colours that the sun and the sky have in the real world.

The fun of having these different colours for the skylight and the sun, is that the sun's shadows become a subtle blue. Brightly lit spots, on the other hand, may become slightly yellow. This fits what my highschool art teacher used to tell me: never paint a shadow with black, always add colour. (Of course, I didn't really understand her at the time...) Since I like this setup, I used it for Proun's first track.



For the second track, I wanted to use a totally different colour palette. Now I am not very knowledgeable in colour theory, but I did notice that yellow and blue are exactly opposite colours. So again I chose opposite colours and after a lot of experimenting with the colour scheme that I had in mind, I came up with a cyan/blue sun and an orange skylight. That is one really weird lighting setup, but I do think it looks good:



The third track is probably the weirdest. A greenish/blueish sun is combined with a pinkish skylight. I think this mainly proves that as long as two colours are chosen that work well together, the colours can be as crazy as you like. So no need to go for the standard lighting setups any more!



So, as these images show, the bright colours of Proun's objects are combined with much more subtle colour effects from the lights. Having just the bright colours worked perfectly well for many works by Kandinsky and Mondriaan, but I think in Proun's case, the subtle colours and shades that the lights add are what really make the graphics shine.

Lighting in Proun

Proun is getting a lot of very positive responses to how it looks. Most people seem to think that the depth of field blur is the core reason for this, but the game still looks pretty good when that is turned off. What really makes the biggest difference, is the careful lighting.

Since most of Proun's environments are static, the lighting is calculated beforehand and stored in lightmaps. Calculating lighting beforehand is called baking. Baking should not be confused with cooking, which stands for saving memory directly to disc (this is used to speed-up loading times, because you don't have to parse cooked data). Interestingly, I have heard rumours that the terms baking and cooking are also sometimes used for certain algorithms that are used in kitchens, but I don't know anything about that.

Lightmaps take up a lot of space (one third of Proun's total size), but they have some big benefits. Because lighting is calculated beforehand on the developer's computer, it doesn't matter if it takes a lot of time. This means that much more complex lighting can be used than when it is calculated in real-time. In Proun, I use this a lot. I think calculating all the lightmaps for just the second track cost my laptop about 30 hours!



The further a shadow is from the object that casts it, the blurrier is gets, especially if the light source is large. Lights that cast shadows that get blurrier with distance are usually called area lights. In practice, it is hardly ever possible to calculate this in real-time, so most games have either fully sharp shadows (as if the light source is infinitely small), or a fixed blur that ignores distance.





(On a sidenote: as soon as Proun is finished, I am going to implement a technique that I have come up with that makes it possible to render real-time area light shadows in games with a Diablo-like perspective.)

In the real world, a lot of light does not come directly from the sun: part of the light is scattered by the atmosphere and comes from all directions. Such light from all directions is called skylight. Skylight makes shadows less deep and add a lot of subtle shadow effects to the world.



Objects reflect light. So if light falls on a red object, then this object will reflect a little bit of red light onto the objects around it. This is called global illumination. This is a very subtle effect, but because of Proun's bright colours it is clearly visible in a couple of places.



All of these things are only possible because in Proun, lights don't move and almost all objects are static. I could not have used lightmaps otherwise. The levels are also small enough to store high quality lightmaps of all objects.

The things I discussed here today are pretty technical. In a future blogpost I will talk a bit about the artistic side of Proun's lighting: crazy light colours.

Sun rays

Writing shaders is one of the things that I enjoy most in making games. Kind of surprising, really, because generally I dislike doing low-level coding and optimisation. Shaders are among the worst in terms of dirty hacks and hardware specific code. So why do I enjoy writing them, then? I think shaders attract me because of this: they are so limited, that science and optics become totally useless. The way real light works is so much more complex than what you can do in a shader, that you need to just make something up that kind of looks similar, although it is often totally unrealistic. Physically, most shaders are utter nonsense. So instead of being all about knowledge and math, shaders centre on creativity and experimenting. Now that's fun! (At least, to a special kind of people, also known as Joosts.)

One of the nicest examples of creativity in shaders is how light shafts are rendered in games. Light shafts are also known as god rays, volume light, sun rays or Jacob's ladders. They are what you see when a light shines through misty air. The microscopic particles in the air are lit and become visible.



Rendering volume light realistically takes a lot of computation time. You need to trace rays through air, take into account the density of the mist, and for a large number of points in the air you need to calculate whether the particles there are illuminated by your light. This includes doing shadow calculations for each of these points in the air. This is way too complex to do well in real-time.

So, some clever programmer somewhere (not me) came up with a trick that looks great and is a whole lot simpler to do. The idea is really simple: you just walk over the image from the pixel towards the sun, and look how much light there is in the image.



Click here for the original article about this technique, which is also the source of these images.

Things like volume, fog density and shadow are completely ignored. There is hardly any relation between this technique and how real volume light works, but somehow it looks very similar and really convincing. Games like Far Cry 2 and Crysis use it to create beautiful lighting effects through the leaves.

There are some limitations to this technique, though. Most importantly, it only works if the light source itself is actually in view. For example, using this technique, it is impossible to render the effect of a flashlight that is pointing away from the viewer.

Rendering light shafts this way not only looks awesome; it is also one of the most beautiful, simple and ingenious shader techniques I know of. Since I like this effect so much, I couldn't help myself but add it to Proun's third track. The track's graphics are far from final, but the light shafts are there. The little video at the beginning of this post shows how dynamic the effect looks in motion.

Stereoscopic 3D

Stereoscopic 3D has been all the hype of late. You know, with those black shutter glasses and expensive televisions, or on the new Nintendo 3DS. Although I usually totally ignore these kinds of hypes (I don't have an iPhone, for example), I somehow already ended up making two games for 3D: Swords & Soldiers for the Playstation 3 and Proun for the PC. The latter will be playable in 3D in a few weeks at the STRP festival in Eindhoven.

I won't bother you with the technical aspects and the weird camera math of stereoscopic 3D, since I think the implications of stereoscopic 3D for graphics are a lot more interesting and not as straightforward as one might think.

The first thing to realize is that you should really consider the monitor to be a window into another world. Things may come out from this world, through the monitor towards the player, but if this happens, then these objects should not be cut-off by the edges of the screen. If an object is behind the screen in the 3D space, then the viewer's brain easily accepts that it is partially behind the monitor's edge. However, if the object is in front of the screen, yet is cut-off by the edge of the screen, then that is really weird to watch: how can an object be hidden behind something that is further away? This is called a window violation. A design implication of this is that in a first person shooter, the gun cannot be in front of the monitor and thus cannot be really close to the player.



However, it is a lot of fun to have objects fly towards you. This looks so real, that as a player, you will want to duck to evade that coconut that is being thrown at you. So it is a good idea to put some of these effects in the game. Unfortunately, both Proun and Swords & Soldiers lack such effects, because I didn't have the time to add additional special effects just for 3D.

For pure realism, one could argue that the distance between the left and right eye in the game world should be the same as on a real person. However, as a programmer, you have control over this. Moving the virtual eyes further away from each other essentially makes the depth effect stronger. The stronger, the more spectacular, but making it too strong causes headaches.



A difficulty of 3D is that your eyes always focus on the screen, even though your brain thinks you are seeing objects that are behind the screen or in front of it. Because of this difference between your brain and your eyes, switching from where you are looking takes longer for stereo 3D than it does in the real world. Even worse: doing it a lot causes headaches, especially with certain people who are sensitive to this (like myself).



This is especially important to think about for the GUI. For example, in Swords & Soldiers, the healthbars are deliberately placed at the same distance as the soldiers. I would have liked to also position the map and the player's gold at this same distance, but because we also have foreground graphics, I had to place the interface in front of the foreground graphics.



A very cool effect in Swords & Soldiers is that because all the objects are themselves 2D, making the entire scene 3D means that all objects look like cardboard cut-outs. In a normal game that wouldn't be cool, but it works really well with the cartoony art style of Swords & Soldiers and looks awesome!

Finally, stereoscopic 3D means that certain cheap tricks cannot be used any more. Many games create rain by simple placing a rain texture on the screen, instead of having actual rain in the 3D world. With stereoscopic 3D, this trick becomes very obvious, so you need to somehow do better rain.

So, even though it is pretty easy to get 3D to work at all, it definitely takes some extra design work to make a game that works really well with stereoscopic 3D!

Designing against motion sickness in Proun

Last week Proun was shown on Kotaku and Gametrailers. Most reactions were extremely positive (awesome, woohoo! ^-^ ), but there were also quite a few remarks about people fearing motion sickness when playing the game. I totally agree that this is a serious issue with this kind of game, so I constantly took it into account with a lot of design decisions. I tested Proun on large flocks of people at different occasions and the nice result of my work against nausea is that it is pretty rare for people who actually play Proun to get motion sickness.

The emphasis on the word play in that previous sentence is important: watching someone play the game or, even worse, watching a video montage of it, is actually a lot more nauseating then playing yourself. The reason for this is simple: the camera only rotates when you steer, so when you play yourself, you see the camera movement coming. This really makes a huge difference, so playing the game yourself is a lot better than watching that trailer.

Preventing motion sickness was an important argument for a lot of design decisions in Proun, especially concerning the camera. A great help is that I have designed and coded quite a few camera systems in other games already: De Blob, Swords & Soldiers, Ronimo's secret new game and the cancelled 3D game that we were developing at Ronimo before we made Swords & Soldiers. Those camera systems weren't necessarily great, but at least I learned a lot while programming them!

In general, an important cause for motion sickness is camera smoothing. Without smoothing, camera movement may look very blocky and ugly. However, smoothing also means that the camera does not directly follows the player's movements, since it must add a little bit of delay to smooth things out. I experimented with smoothing a lot for Ronimo's cancelled 3D game, and it turned out that certain types of extreme smoothing cause almost instant nausea, but that even the tiniest bit already has this effect to a small extent. With a lot of smoothing, the camera may never stand still. So for Proun, I chose not to have any camera smoothing at all. I did experiments with it, but all the smoothing schemes I applied caused too much nausea for Proun's own good.

The reason motion sickness is so important for Proun specifically, is that there is no up or down. The camera constantly rotates the world around and there is no horizon to focus your eyes on. Even the cable whooshes and curves by real fast. So I chose to position the player's vehicle at the centre of the screen and to always keep it there, without zooming or looking around it. This way the ball replaces the horizon as the stable factor on the screen.

Proun may still result in motion sickness a bit quicker than other games, but because of the counter-measures I took in the camera design, I think this is solved well enough. Playtesting shows that most people can play this crazy rotating game as well as any other 3D game. :)

Dirty collision detection trickery in Proun

Some people seem to read Pr0n instead of Proun. I think this may be due to the dirtiness of some of the coding tricks I used in Proun.

Or maybe it is because these words are written so similarly. No, really, I don't think so.

Anyway, programmers who worked with me might agree that I have pretty radical ideas on what good programming is, especially in comparison to how large console games are usually made. I almost always choose simplicity and understandability over performance, over memory use and often even over amount of work.

Most coding interns need to get used to the idea that sometimes when they consider something done, but there is still a way of structuring it in a better way, I actually make them go back and change their already working code, just to make the code itself better. Since the games at Ronimo are around 100.000 lines of code, keeping the code clean is very important. No way will we find our bugs if such an amount of code is also a mess!

An extreme example of choosing simplicity over performance can be found in the collision detection in Proun.

Collision detection in games is usually done per frame. So 60 times per second, all objects are moved a bit and then the game checks whether they collide. This means that the time between two frames is completely ignored!

This becomes a problem when fast moving objects (e.g. bullets) pass through thin obstacles: in one frame they are on one side of the obstacle, and in the next frame they already passed it.



Common solutions to this problem are to cast a ray between the position at the previous frame and the current position. An alternative is to do sub-steps just for the collision detection and only when moving really fast.



Both of these solutions share that they would need additional work in the collision detection of vehicles in Proun. When doing the solution with subframes, the collision detection would run at a different framerate from the rest of the game, which increases the complexity of the code. Not dramatically, but it is more complex nevertheless.

For Proun, I implemented a simpler solution: all gameplay in Proun runs at a fixed 3000 frames per second. Three thousand. Three thousand! The graphics still runs at 60fps, of course (or less if your videocard is too slow).

The result is that even when you race extremely fast (grab a turbo on Impossible difficulty to do that), you still don't move too fast to pass through objects without collision detection detecting this.

Any reasonable programmer would say this is idiotic. So much performance wasted! I even update all obstacle animations at this framerate. Unnecessary! However, Proun's performance is almost entirely in the graphics. The gameplay is very simple and can be processed really quickly, so why would I bother implementing something more efficient and more complex? Doing a lot of gameplay updates per frame is really simple to implement and everything just works. I don't need to add any math for the time-in-between or anything like that, I don't need to think about having different framerates for collision detection and for other gameplay aspects. Any other solution would have made the collision detection code more complex than it is now.

I tested the actual performance impact of this and it turns out that this only impacts the framerate in a relevant way when a really slow processor is combined with a very fast videocard. No one actually has such a combination, so I don't consider that relevant.

So. Simple! Clear!

(And in fact not dirty at all, so maybe the words Pr0n and Proun do look pretty similar...)

Camera mapping tips and tricks

While experimenting with camera mapping, I learned a lot about how to use this technique, so I figured I'd share some of what I've learned here!

1. The Camera map modifier

This is the cheap and simple hint: 3D Studio MAX has a modifier specifically for doing camera mapping and it is called, surprisingly, the Camera map modifier.

2. Do not model object edges

The edges of the object should come from the image itself, not from your model. The reason for this is that polygons have straight, hard edges, while drawings have more blurry and zigzagging edges. You cannot really create a blurry, brushed edge using polygons. Using the image's transparency for the edges also makes modelling a lot easier, since you don't have to model the objects as precisely. The image below shows that you can even just stretch the polygons as far as you like.



I guess with sharp photographs of buildings it may work to model object's edges, but with the kind of art I have been working with, doing object edges exclusively through image transparency looks way better.

3. Split into many layers

To use transparency, you will need to split the image into a lot of layers. This greatly depends on the type of scene you are doing, but in general, the more layers you have, the easier it is to make your 3D scene. For the Evil Pope I used three layers (head, body, thorns), while for Captain August I used a whopping 28 layers! Splitting the original image into all those layers and drawing the parts behind layers was a lot of work, but was also absolutely necessary to make it look good.



4. Put a curve on everything

If you map an entire character to a flat plane, then it will look like a cardboard cut-out as soon as the camera starts moving. Putting the arms and such in separate layers is important, but it also works wonders to simply bend objects to roughly mimic the shape of the real character. Don't overdo this, though, for if you look too far from the side at an object, it will squash the lines of the original drawing too much, decreasing the 2D effect.



5. Animating after the mapping

Once an object has been camera mapped, you can animate it any way you like. For the little video of August, I rigged the bodies and arms of the characters with bones to be able to rotate and bend their arms and heads. This works surprisingly well, without breaking the illusion of a 2D drawing. For the Evil Pope, I was even able to change the character's expression without using any new drawings. This was done by morphing the mesh of the face into different expressions. The only things that I animated with extra textures are blinking and closing eyes. Everything else is just morphing, bending and moving the 3D models.

Last words on camera mapping for the moment: I'm thinking of trying camera mapping in a small real-time 3D game prototype to create a totally unique and awesome graphical style. I'm looking for a concept artist to design that with, so if you think you can draw a lively outdoor environment in a rough, colourful impressionistic style, maybe a little bit like this or this or this or this or this, then please do contact me at joost@ronimo-games.com!

In the meanwhile, I've headed back to working on Proun for a while! :)