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. :)
Saturday, 30 October 2010
Wednesday, 20 October 2010
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.
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...)
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...)
Saturday, 16 October 2010
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! :)
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! :)
Sunday, 10 October 2010
Captain August got camera mapped!
Last week's camera mapping experiment tasted like more, so here we go again! What lured me back to camera mapping is the possibility to do 3D animation and 3D camera movements, while the end result still looks like a real 2D drawing. No lame cell-shading effects here, this looks like real hand-drawn awesomeness!
This time I picked an image that doesn't get much more 2D: one from Captain August, Roderick Leeuwenhart's webcomic! This image features lots of things that look gorgeous in 2D, but are incredibly difficult in 3D. For example, it features a completely broken perspective (just look at the dome at the top!) and thick white outlines against groups of objects (instead of per object).
For this image I wanted to emulate the subtle animations in Anno 1404's beautifully animated story screens. This is all about breathing life into a still image.
So, in short: I modified a still image and turned it into this animation:
The 3D version of this scene is pretty funny to look at it, since it is difficult to even recognise where the characters are:
Those who know my work, may know that I already visited Captain August a couple of years ago. At the time I made a full 3D model of him and it's fun to see how that type of 3D results in a totally different style. I like both techniques, and they serve totally different purposes.
While doing these camera mapping experiments, I learned a lot about how to tackle that stuff, so next week I will post some tips and tricks for the technique!
This time I picked an image that doesn't get much more 2D: one from Captain August, Roderick Leeuwenhart's webcomic! This image features lots of things that look gorgeous in 2D, but are incredibly difficult in 3D. For example, it features a completely broken perspective (just look at the dome at the top!) and thick white outlines against groups of objects (instead of per object).
For this image I wanted to emulate the subtle animations in Anno 1404's beautifully animated story screens. This is all about breathing life into a still image.
So, in short: I modified a still image and turned it into this animation:
The 3D version of this scene is pretty funny to look at it, since it is difficult to even recognise where the characters are:
Those who know my work, may know that I already visited Captain August a couple of years ago. At the time I made a full 3D model of him and it's fun to see how that type of 3D results in a totally different style. I like both techniques, and they serve totally different purposes.
While doing these camera mapping experiments, I learned a lot about how to tackle that stuff, so next week I will post some tips and tricks for the technique!
Sunday, 3 October 2010
Camera mapping the Evil Pope
I recently discovered a technique that is used a lot in 3D graphics: camera mapping. It makes it possible to do 3D movement with a 2D image without having to recreate the entire image in 3D. I greatly enjoy playing around with this method, so I took a drawing by Marlies Barends and turned it into a 3D animation with facial animation and such.
The cool thing of this technique is that the result really looks 2D. Pause the animation on any frame and it may have been a drawing. Recreating something in 3D rarely maintains the 2D feel of the original, so I think this is pretty cool. :)
Also, all the examples of this technique that I have seen use environments. I guess others have tried animating characters this way as well, but to me this is a new usage of camera mapping.
It's a bit of a weird technique to explain, so please just have a look at the video and the image below to see how it works.
By the way, the music under the video is a quick track I was playing around with and felt like putting under it. Its main sound is a choir with a lot of distortion. Somehow my distorted mind thinks almost anything sounds cool with distortion...
The cool thing of this technique is that the result really looks 2D. Pause the animation on any frame and it may have been a drawing. Recreating something in 3D rarely maintains the 2D feel of the original, so I think this is pretty cool. :)
Also, all the examples of this technique that I have seen use environments. I guess others have tried animating characters this way as well, but to me this is a new usage of camera mapping.
It's a bit of a weird technique to explain, so please just have a look at the video and the image below to see how it works.
By the way, the music under the video is a quick track I was playing around with and felt like putting under it. Its main sound is a choir with a lot of distortion. Somehow my distorted mind thinks almost anything sounds cool with distortion...
Subscribe to:
Posts (Atom)