February 20, 2010

I haven’t posted something for the last couple of days because I was too busy with coding. Here’s a video in a far more progressed state in comparison with the last one. The level is an automatically generated maze using the depth-first search algorithm. By increasing the size and changing the theme of the graphics, any kind of maze-based levels can be generated such as dungeons.

Note the transparency on the walls. The controls are also improved - in this video I’m playing using a Xbox 360 controller. The second part of the video is real-time debug information rendering, such as the bounds and the name of the object printed on the world, the scenegraph tree and various other debug information.

All content, including music, models and textures (except the floor) created by me.

2:27pm  |   URL: http://mesartian.tumblr.com/post/400556173/i-havent-posted-something-for-the-last-couple-of
February 18, 2010
Collision and rotation again, skinned mesh animation and A* pathfinding

While I’ve mentioned in my previous posts that I’m trying to avoid complexity so I can succeed in having a playable demo game fairly soon, there are some things that after all can’t be avoided. While working on solutions for a serious physics bug, I’ve ended up having a rotatable world that actually works with the current AABB collision model. Still that was not enough to persuade me that I should do it this way.

What was the final drop in the glass though was this website which is a Korean website that specializes in getting a games developing job in Korea. After taking a look at the jobs there, it gave me the motivation to push myself further and show these people (the companies I’m applying to that is) something impressive. And having a full 3D world - like the ones you will find in most Korean MMO games - is after all an important piece to the puzzle.

Then I’ve started coding an experimental 3D mesh Drawer. As predicted by the initial design this was far easier and cleaner than it usually is. For the time being only basic mesh is supported - that is no skinned/animated meshes. The complexity rises exponentially in this case but it’s a requirement for my game so I’m working on it. As it’s something I’ve already done before a few times (not in C++ though) I’m confident I can have this part implemented relatively soon. Usually it takes some experimentation to find a working combination of how you export your 3D models and how you load them in your game. In any case I already replaced my box hero with something a bit more interesting I’ve quickly hacked in on a 3D modelling software.

Regarding the 3D models, from my previous experience, asking from somebody else to make them can delay things a lot, since it’s dependant on the other person’s motivation to work. I rather quickly make my models on my own - although might not be as good - than trying to explain to somebody else what I need and how I need it and still not being sure if I’m getting anything in the end. Besides most of my models will be using shaders and finding a person that can do all these for me is quite hard. Most importantly though, this is the most important project of my life so far and I wouldn’t like to rely on anybody else since that raises the risks a lot. I’m currently trying to find some free 3D modelling solution that works for my case and I feel comfortable working with. Blender is not really my type and there are chances I could end up using 3D Studio Max instead that I know how to do things properly and of course it works.

Except from the practical part, I’ve been studying a lot to gain the required understanding around all the physics and AI required for the game. So I discovered the A* pathfinding algorithm, which is the most used pathfinding AI in games. The idea is creating a grid that covers your level and using the A* algorithm for estimating the cost of travelling from one point to another. It might sound relatively simple but unfortunately it isn’t that straight forward. Nevertheless it’s what I’m probably going to use as it’s actually the solution I’ve been always thinking, just well defined and explained.

Apart from that, there are a few problems here and there with the most annoying being an arithmetic bug during the integration that can cause some instability on moving objects. I’m yet to find a good solution for it as the integration algorithm is not that simple anymore as it involves a lot of steps like checking for collision after calculating but before applying the physics and applying drag on objects - not to mention gravity. The order that these stuff need to be calculated is a nightmare and books won’t really help here as it’s a practical problem of putting everything together - at least in the clean way I liked them to be.

2:55am  |   URL: http://mesartian.tumblr.com/post/395833919/collision-and-rotation-again-skinned-mesh-animation
February 16, 2010
AI, alteration in physics and camera

I have been doing some research the last couple of days, especially on the AI of my game. Since I haven’t ever done any real AI before, I need to gain at least the basic understanding of it. While the AI system structure that I’m going to follow is the one found in AI Game Engine Programming by Brian Schwab, I have also been reading the detailed presentation of AI algorithms in Artificial Intelligence for games by Ian Millington. Both are great books that guide me through the hardest part of this demo project.

One of the main points I found out is that the game as I’ve designed it, it doesn’t need support for objects with dynamic steering - objects with varying acceleration that is. While this is what I’ve been following for the past few of my projects, I now fully understood why this was complicating things far more than it was required. Introducing acceleration makes things appear more realistic as it takes in variables as the mass of the objects; then forces are applied on the objects.

There are other two ways to do this. One is directly altering the position of the object. This method is totally out of question as it’s too unprofessional and can usually be found only on some uncompetitive assignments or such. The other is directly manipulating the velocity of the object. This is the way that most Japanese action RPG games are programmed even to this date. Nihon Falcom has been producing some excellent games such as YS Origin and Zwei2 using exactly this kind of physics. Since when I’ve designed this demo game, I’ve envisioned something similar to these two games and since they are doing it this way, I don’t see why I have to do it any different.

Does this mean I have to remove acceleration and alter all my code though? I’ll have to experiment a bit about this and think about how this would alter the other game components. Most likely acceleration would still remain in but it will be manipulated directly.

Another point is the camera I’m going to use in the game. Of course the camera will be rotation-fixed (remember this is done with AABB collision - and rotating camera would cause all kind of problems) and the character will rotate only in 8 directions but the camera is going to be facing π/4 (45degrees) counter clockwise to give the 3D feeling, otherwise the game will lose its depth. This is how most games of this kind are made as well.

10:03am  |   URL: http://mesartian.tumblr.com/post/392531691/ai-alteration-in-physics-and-camera
February 14, 2010
Bugs, bugs, bugs

Getting things working doesn’t mean they will work everytime. That’s how I’ve spent the day while trying to fix bugs here and there - and in fact there are still a lot. These bugs occur not because of problems in the code but rather in the design or the logic of some problems. Collision response is now bug free and works fine for the current situation but I really don’t like the code. While it’s very practical, I know there are other better ways to do it.

Nevertheless I’ve designed some basic mechanics on paper yesterday and hopefully I’ll be implementing them during next week. I’ll be quite busy since I need to catch up with my final year project meaning I’ll have to spend some time at the labs writing some PSP code - which is as bad as it sounds.

10:53pm  |   URL: http://mesartian.tumblr.com/post/389659102/bugs-bugs-bugs
February 14, 2010
Moving to basic game mechanics implementation

After finishing the basic physics, I’ll move on to implementing some of the game mechanics such as firing and Entity characteristics (hitpoints, experience and such) of my game. That will allow me to start implementing the enemy mechanics and do some AI tweaking which I expect it to be the hardest part of this prototype, maybe even of the whole project. This will also give me the chance to test the gameplay design and possibly change some of its aspects.

The level generation algorithms are also of great importance but not before I complete the basics of the elements above. The main gameplay mechanics have been designed years ago when I was trying to make this same game - but with much less knowledge and determination. Luckily back them I’ve documented everything into nice design documents that I can use today and derive my gameplay from.

Next week I’ll be also resuming my final year project which has to do with a Particle engine for the PSP. The current PC version of it, is built on areiadne1 and should be very easy to transfer its capabilities to this project as well. This will allow for nice particle effects that under other circumstances I wouldn’t bother programming but since the component will be perfected for my final year project, it is a good chance to beautify this game as well.

5:34am  |   URL: http://mesartian.tumblr.com/post/388445747/moving-to-basic-game-mechanics-implementation
February 13, 2010

So, here’s the outcome of the past few days working on collision detection and response. In games, usually the player is not trying to go through the wall, it’s most likely a touch by mistake, meaning he’s pressing two directional keys at the same moment. Zeroing the velocity towards the wall direction and leaving the rest intact allows for smooth gameplay. Jumping onto the platforms was also quite tricky as you have to compare the height of the player and the platform to determine if the player is on top of it so you cancel only the velocity at the Y axis preventing the player from sinking into the platform. Then leaving the XZ axes intact despite the collision allows for walking on them.

6:40pm  |   URL: http://mesartian.tumblr.com/post/387552277/so-heres-the-outcome-of-the-past-few-days
(Notes: 1)
  
February 13, 2010
The collision monster

Yesterday I took the day-off from programming and I’ve gave the collision-related part a deeper thinking. As I’ve said on my previous posts, collision detection and response is not a joke. While I’ve managed to build the rest of the engine in less than a week I knew it would take some good amount of time to get this right.

When physics and maths come into play things start getting serious since there’s no way of “just” doing it; it has to look and feel right in every aspect or the gameplay will be broken too. In fact by closely observing my previous projects, I’ve never done what I’m trying to do now, at least at that level. That’s why it got hard.

The physics from my previous projects just don’t work this time as I don’t want a specific hacky solution to a problem. Instead I’m looking for a more generic system that will cover the whole game mechanics. Perhaps I’m doing this the wrong way at the moment by trying to combine everything in a good looking system but there is no other way to this than repetitive trial-and-error.

While the detection worked fine and it’s at the right spot, I wasn’t quite sure about the collision response. The most important breakthrough into this though didn’t come from my expensive games programming books but from my university slides. In fact, the order that everything takes place in the engine is of crucial importance. A magical slide that explains when exactly collision detection and response should take place in simple terms has saved me from nightmares and gave me a very good push forward. Today I’m going to work more into this and put more detailed information later on.

4:14pm  |   URL: http://mesartian.tumblr.com/post/387362006/the-collision-monster
February 11, 2010
OBB brings back feature-creep nightmares

After spending all day yesterday implementing collision detection using oriented bounding boxes (OBB), I woke up this morning and started thinking if it’s really that necessary for my game. The practical difference between OBB and AABB (axis-aligned bounding boxes) is that AABB remains static on rotations and therefore you can’t have rotated collision checking on your objects. The technical differences though are surprisingly huge. Where for AABB checking it takes a couple of transformations and a few simple checks, there is only one way that OBB collision detection works and that’s using the axis separation theorem, resulting in a much more complicated and computational intense algorithm.

Nevertheless I’ve pushed myself a lot this morning and after reading a lot of hard maths and physics books, I’ve managed to complete the OBB collision detection implementation. But then I sadly realized that having things rotating with their bounding structures makes things much more complicated. That’s because in that case, collisions don’t just occur on moving but also on rotation bringing into play rotational dynamics and much more advanced physics.

My game actually doesn’t have any rotational mechanics. The initial design (as I’ve defined it during the first days of writing to this blog) was to allow for fast action with move-per-key controls, meaning when you press a key, the character automatically rotates and moves towards that direction. The other system is moving only forwards and backwards and rotate left and right, which is not what represents fast-paced action RPG games.

Eventually, after playing around with the prototype I’ve concluded that this is how I really want my game so I’ve decided to use the simpler AABB algorithm instead. So I’ve removed the complex OBB code, easily implemented the AABB collision detection and I’ve already moved to collision response which I’m currently tweaking. Getting collision response working properly is quite hard as well and there are not many alternatives other than using the proper physics for it.

Thinking about the whole OBB situation though I realized that I’ve lost important time and energy for my project. Trying to get OBB working was a classic example of falling into the feature-creep trap and over-engineering the problem. I can totally imagine my game using OBB and that would also improve the gameplay in a million ways. But it’s really easy losing track by adding new features in and that’s not how successful projects really work. Implementing OBB, brings rotation in, then rotation brings rotational dynamics and this brings full-scale rigid bodies physics in, ending up writing a full scale 3D physics engine. That would probably take a few months alone and all I would have would be a really hard to tweak and work with engine resulting in a broken uncreative game that I can’t show to anybody.

Getting the initial idea working is the essential point here because it’s really easy to get tired and lost and end up doing nothing at all. It has happened numerous times to me before and I won’t let it happen again. In fact almost every single of my previous programming projects (at least 20) have ended in exactly that way. I think this is the most important aspect in whatever project - getting the thing to work before altering or adding anything else to the original specification. OBB was a good lesson so from now on I should be more careful and just get my job done the easy simple way so I’ll have a nice demo game to show-off.

4:06pm  |   URL: http://mesartian.tumblr.com/post/383891868/obb-brings-back-feature-creep-nightmares
February 10, 2010
Collision detection structures

Everything has been going quite smooth up to now but here I’m running to the first problems. The complexity of my code has raised a lot after adding the physics in. The problem is not making things work but maintaining and accessing all the required data in a logical, efficient and safe way. A very important point is always having the understanding of what exactly is going on, meaning what object contains what, what functions are called, in what order they are called and so on.

Collision detection is a small monster itself. My game is going to use bounding spheres for first level checking and Oriented Bounding Boxes for more precise checking. Putting the geometrical problems aside, it’s also important to create that data at the right time and the right location so it can be accessed when and from where it’s required. They are many possibilities that seem sensible and making sure the one I choose won’t give me any headaches later is quite challenging.

For generating bounding data obviously an object needs access to the original vertices. Those vertices though are held inside the drawers that if you remember they are attachable components. This creates the problem that some object might not have a drawer attached to at all. What happens then? Should I give some default values to my bounding data or just leave them empty?

7:04pm  |   URL: http://mesartian.tumblr.com/post/382214574/collision-detection-structures
(Notes: 1)
  
February 9, 2010
Basic physics and control system implemented

As you can see on the video below, today I’ve been working on the basic physics components such as applying forces on objects and the main control mechanism for moving things around. This involved a rather large structure of classes allowing for a flexible modular system. I’ve also added support for the xbox controller which feels much smoother to play with.

The engine’s structure has been becoming more and more complex but everything is going according to the initial plan and design. Collision detection and response will be implemented next so I can move on to applying some game mechanics such as firing and killing enemies.

10:54pm  |   URL: http://mesartian.tumblr.com/post/380656438/basic-physics-and-control-system-implemented
(Notes: 2)
  
Liked posts on Tumblr: More liked posts »