Programming: AI for Following a Target

Recently, I changed my code used in an enemy that follows the player. Apparently I did a huge mistake by using cross and dot products. There are simpler way to do it by using angle values. Here is how it works.

Triangle Wars Coding Guidelines

So I decided to create a coding guidelines since my code is getting bigger (approximately 10k+ lines). I loosely use Insomniac Coding Guidelines with a few tweaks. It might not be the best, but at least it fits my mind. So if you're interested, here is my coding guidelines:

Notes:
libraries (e.g. math and until classes) does not required to follow a coding guidelines to support portability.

REQUIRED PREFIX
m_(variable name) for class member
f_(variable name) for function parameter member
l_(variable name) for local member
g_(variable name) for global member
s_(variable name) for static member
(CAPS variable name) for preprocessing-defined member


OPTIONAL PREFIX
(m/f/s)_p_(variable name) for pointer
(m/f/s)_a_(variable name) for array
(m/f/s)_k_(variable name) for constant value


OTHER REGULATION
put space before and after arithmetic operator
e.g.: a + b // right
a+b // wrong


put space before and after pointer * and address & definition
e.g.: int * thisPointer; // right
int *thisPointer; // wrong


use is(Condition) for method returning boolean method
e.g.: isEnable(), isDrawable(), isColliding(Obj * f_obj)


For commenting, I try to follow Doxygen supported comment. I'm currently developing it. There are others that I would like to put on my list but most of it are just a trivia problem such as always start curly braces on a new line. And I'm curious why Insomniac prefer C type casting compared to C++. Currently I'm converting my codes to support this guidelines, so expect less feature on the next Triangle Wars update.

Triangle Wars: Graphics and Gimmicks

Another 'major' update on the Triangle Wars. I'm not sure whether I'm bored with the black background, but I'm very pleased with the new grayish background. I also add dust path to make the game more 'glowing'. Another major redesign is the bullet is not a circle instead of an oval. It looks cuter (imo) :) I also add a health bar surrounding the player object instead of putting it on top of the screen.

Recently I struggled with sound, but no luck. I've tried SDL_mixer (which features is extremely limited) and OpenAL (which is not well-supported in OSX environment). Currently I'm trying to find another sound engine (gonna try FMOD).

I'm still looking an artist and sound engineer. Contact me if you're interested!

So here is the video of the last update. Watch it on directly on Vimeo for a higher resolution! It should be on HD (720p). I disabled the Player-Enemy collision since there's an error in circle-triangle collision. I'm currently working on it.

Triangle Wars: Font, GUI, and Lights

Greetings Human!

I spent the last week to create a 'decent' GUI. I already created a set of font, exported as TGA and add a few eye candy effect. I added the gloom effect and use a shuffling animation (inspired by Modern Warfare multiplayer intro at the beginning of the game). It uses automatic random generator so it's easy to add new text and automatically have it shuffled.

I also add light/gloom effect surrounding the enemy so the player can easily notice the enemy.

I also define 2 missions on the level: time based Survival and Elimination. On survival mode, the player has to survive at a certain time with one life. On elimination, the player has to destroy a predefined amount of enemy.

Next, I will focus on defining more types of level and fixing the GUI.

Here is the video for the latest update. The resolution is not in HD since I'm trying to see how the game would be on iPad. The GUI (especially the 'start' and 'option') is not final. I use the box to detect the hit, but it won't be there later on.

Triangle Wars: Enemies redefined

In this phase my focus is to fix the broken AI by implementing a simple Finite State Machine and redefining some enemies behavior. Currently there are four type of enemies: Fighters, Runners, Kamikazes and Effector.

Fighters is extremely slow but heavily armored. It shoots rockets which has a light damage but fast and follows player.  Runners is extremely fast when in running mode. It enters running mode when the player is close enough to the Runners. Kamikaze follows the player (slowly) and have massive damage. Once it close enough to the player, it armed itself for a few second and create a huge explosion with devastating damage. Effector is a static enemy. It slows the player if the player is inside its range.

I also add a 'lighting' effect to destroyed objects so it looks like there is an explosion. I did this by creating a shader that (re)draws the background grid nearby the explosion. It also colored the grid/background color to suit the explosion color.

Next phase: fonts, GUI and menu.

PS: Just noticed the disabled health system. That is intentional to make the testing easier.
PPS: Still looking for artist! ;)

Triangle Wars: Graphic and Camera

I'm back! After a few weeks of 'hibernating', I finally can start working on my game again.

This update focus on graphics and camera. I use bloom effect on every object. I do this by creating a 1 byte alpha texture and tell the GLSL to treat this as an alpha value. I also add a few artworks so it's easier to figure out which is what. For the camera, I move it closer to the object so the bloom effect is noticeable. I also add a new movement positions for the camera.

I also put a few animations on the equipment: rotating target for Decoy and radius-decreasing circle for Attractor.  It's not a breath-taking art system but good enough for a programmer ;) I'm still working on the Turret.

The next step is to modify the gameplay (AI, horizontal path) and polish the effects (particles). I decided to delay my work on sounds.

MYOGE 5: Equipments and SDL

I'm back with another update with my OS X mini game: Triangle Wars. I've been busy recently so the updates will be minor.

I added 3 equipments (or secondary weapon) that the player can use: Mini Turret, Attractor, and Decoy. Mini turret shoots enemy, Attractor pulls nearby enemies and bullets, and Decoy acts as a target when an Enemy is looking for a target. 

I also converted the program from GLUT to SDL. Thanks to Me and Mark for the XCode template. However I have problem with performance when I use SDL compared to GLUT. The frame per second is still smooth, but the input (mouse and keyboard) is less responsive. I will look through this problem . 

And another minor update is the particles. Just a minor particle-bounce update, You'll notice on the video.

My next update would be adding the sound, and make some pixels. Anyway, any artist would like to join? ;)

MYOGE Part 4: Weapons Defined

Back again with the MYOGE series. On this phase, I focus on the weapons definition of my game. Currently I have 3 weapons: Gatling Gun, Explosive and Spray.

Gatling Gun focuses on long range shot with high rate of fire, good for attacking a single enemy. Explosive bullet explode at the end of its lifetime, gives damage to nearby enemy. Spray Gun has a short range but devastating damage to nearby enemy.

I also put an upgrade lines on the weapons. At level 10, gatling gun shoots multiple bullet while explosives explode twice.

I also redefine some effects on the scene.  I use a line based effect for the explosion. It looks prettier than the point based but it doesn't match the theme of the game. It looks weird. But I'll decide later.

The next step would be converting the windowing system to SLD instead of GLUT. I had a few troubles with GLUT limitations and it's impossible to use this library for the next step.

MYOGE part 3: Effects

Ola. New progress on Make Your Own Game Engine series. The progress mostly fixed the redundancy loops, hence enhancing the performance. I also added some particle effects. It's still in the rough version. But I like the random generator. The next progress would focus on adding more levels so its actually playable ;)

Meawhile, here is the HD version of my game. I hope you'll like it.

MYOGE part 2: Memory Management and Stuffs

So here we go again with the very development process of Make Your Own Game Engine. haha! The progress mostly dealing with memory allocation which I'm pretty sure by now is leak-safe ;) I changed my engine object management from std::vector to a simple array.

There are also some changes on the gameplay: allowing player to use mouse to point the shooting direction instead of manually using buttons so rotate the direction. It took a while for me to figure out how to convert from screen space to world space. I finally use FBO for this problem. See my previous post for more details.

I also tweaked the camera so it has a floaty feeling making it less rigid. Thanks to Rob for the old tutorials ;)

Finding Mouse Position in World Coordinate

So recently I had trouble finding a proper way finding my mouse position in world coordinate. I'm currently trying to build a RTS-like interface where the player views the world from isometric view and uses mouse to give input to the game. There are a few options for doing this. One option is to develop a ray-tracing alike method to detect the ray from mouse point in screen space to the plane in world coordinate. In my opinion this option is not that effective, especially if the object consist of many planes.

Mesh Data Structure: Memory Efficient Data Structure

Well to be honest, the content is not as cool as the article :D Recently, I spent a few hours to test how to create a good data structure for a vertex information. So my current 'engine' (yeah, rite!) store vertices (and their attributes) with this following structure:

1. There's an array of faces(triangles). Each triangle holds the index of vertex, normal, and texture coordinate it uses.

2. There's an array of vertices. Each vertex holds the x, y, and z value.

3. There's an array of normals. Each normal holds the x, y, and z value.

4. There's an array of texture coordinate. Each coordinate holds the x and y value.

Multitexture FBO in OS X

It's been a while since I put my code in here, thanks to the internet bandwidth around here *sigh*. So here we are, geeking around with graphic source code, and it got nothing to do with Jake Gyllenhaal! *dry joke*. I'm using the oldest Macbook Pro: Core Duo @ 2.0GHz (yup, the 32 bit one), 2 GB Memory, ATI X1600, running OS X 10.6.

Xcode Rule #1: Trust the Code Sense

Recently I used a lot of texture types in my thesis, such as 32 bit Integers, 32 bit RGB, etc. But I did my thesis on Windows-powered-currently-purchased PC. So all type of textures seems to work properly (with a few modification/declaration/asking here and there). But then I switch to my OSX-powered-5-years-old MacbookPro, and hey... it does not work. 

M.Y.O.G.E: Make Your Own Game Engine, Part Uno!

Well, finally I have time to develop my own game engine. It's a 2D game engine, but I chose to use 3D vectors for each position/measurement just in case I can develop it to 3D (crossing fingers). Here is the first milestone:

XCode 4 Pre Review

All right lads, here it is, the long awaited XCode 4. A huge improvement in XCode since Apple choose to adopt single window system. It is definitely BE-A-U-TI-FUL! But is it any good?

C++: Circular Dependencies

Circular Dependencies is an 'error' in programming that involve two files including each other. Here is the example:

// file A.h

#include B.h

class A {

public: 

   A() {

      B b;

   }

}

// file B.h

#include A.h

class B {

public: 

   B() {

      A b;

   }

}

Spherical Coordinate Conversion with up = Y

There are many Spherical to Cartesian Coordinate conversion around the internet. But as I already explained about the confusion, it might be hard for you to find this error if you haven't notice it. My program (unluckily) was made by programmer (me), so the up value is y instead of the mathematician standard z. So I have to change the conversion formula a little bit.

Confusion Coordinate System!

I spent my previous two days figuring out whats wrong with my spherical coordinate system. I checked and rechecked nothing seems wrong with the formula. It looks okay compared to the things we found on the website. But still I cant figure out whats happened to the program. Apparently, my program has become the victim of most common mistake in cartesian coordinate system interpretation. I've been through this confusion back then, I cant believe its happening again. Maybe because I use Maya a lot. Here is the problem.

GLSL: Integer Array

For the last few months I've been dealing with GLSL. Come to my surprise there are many things GLSL capable of doing, but not documented properly over the internet. And the how-to solution is pretty much easy. Not like it contain some kind of hardcore logic stuff, just a few syntax that, if properly put, is easy to do. These are some to name a few: