angelhill.net/code

I am just sitting here thinking about how to handle various actions that an object can perform and how those actions will affect the object, as well deal with sound.

A thought did occur to me that perhaps a good way would be to have a bunch of action objects, and each of those would in turn have its own sound, graphic and other stuff.

This means that we would in essence be free to choose which actions an object can perform, and simply change to a different action library if we wanted to use a different type of engine for the game.

For example, a text action library might perform actions by returning or printing text, while a 2D action library might use sprites and sounds for different actions.

Now, the trick is to decide how far the actions extend and what kind of default actions each object normally has anyway. Also, where exactly the actions will live, in C++ or in Python?

I will attempt to discuss this topic now.

Now Playing: Gamma Ray - Voice In My Head

Read more…

As I talked yesterday about hierarchies and sounds, all of these things are implemented here.
Hierarchies will be useful for ship formations and large bosses.

Another previously (by me) unseen use of hierarchies is of course for collision detection.
Although it’s probably best to generally let small one piece objects deal with their own collision detection, larger more complex objects will certainly need several bounding boxes or spheres, and they will obviously be children to the object in question. They will pass down collision events to their father.

Right now I am struggling with a little issue here. Torpedoes from my own ship should not be able to hit other torpedoes fired from my own ship. Well torpedoes should not hit torpedoes at all, but if my ship has children, a torpedo fired by me should not be able to hit it (unless otherwise specified of course!)

So far, a child can never harm a parent and vice versa (what a beautiful world!), however a child can harm another child without any trouble (more realistic, less desirable). Of course, one can always go down the tree checking to make sure that both children do not have the same parent, but this might prove troublesome.

One idea might be to provide each object with unique shield frequency. Object that should not hit eachother would have the same frequency. This is a pretty bad idea I think, because torpedoes should not hit other torpedoes, but they should certainly be able to hit other ships.
So that idea falls short. It is a cool idea tho, I might use it for something.

Also, in an ideal hierarchy, each object should be a child of the SUPER OBJECT (in this case, the game world. This would serve a good purpose, such as if the world is moving, it would move all of it’s children. So just because things inherit from the same world, if they can not collide, this is a problem.

An alternative sollution is required.

Here are the variables that need to be considered:
1. Any object should be able to collide with another object
2. Any parent or child should decide if it should collide with its filials.
3. Same as above should decide if the collision will cause damage or do something else
4. Any object should be able to decide whom it can and can not collide with
5. Any object should be able to be out of phase, and thus not collide with anyone.

Solutions to the points:
1. This already works, but might need to be redesigned to accomodate new collision rules.
5. An invisible flag should exist, invisible objects can not collide with anything. Sounds will be invisible.

The other aspects are as of yet unsolved, but they will be in due time. I shall return when I have found a good solution.

Right now I branched my isometric game engine into a sidescrolling spaceshooter ala r-type or ikaruga (you could rotate it to become a sideshooter!).
I am obviously not abandonning the game engine, but at some point I felt that it was getting a bit huge and out of my control, so I had trouble testing new ideas and implementing new features.

Since everything I do in game development and C++ programming is currently my first time, I thought I needed a smaller project to complete, and also a project where I could implement all the features that a game might need. My SpaceShooter is this.

Basicly I need to try tons of different stuff in order to learn it, and the best way to go is to do a few different projects. The SpaceShooter seems simple enough to implement at least on a feature level.

So far I have a ship, which can fire torpedoes, making noises when torpedoes are fired. The torpedoes can hit the computer “controlled” opponent which is flying around the screen and shooting it’s own torpedoes. They can kill it. It also dies if it crashes into you.

Later I will discuss hierarchies and collisions.

I think I got the whole sound thing under control.

I am using OpenAL to play sounds, which means sounds can have vectors to specify velocity and position. This isnt too imporant really since I will probably add the ability to turn off environmental audio. The point is, sounds are now ordinary objects just like you and me. They are labeled not solid so they can never collide with anything, and in order for me to deal with them properly, they are added as children to whatever object produces them.

The only problem I believe I currently have is that the sound objects do not die when the sound is finished, which is not a very nice way to deal with memory

However I am working on that, now that I have dealt with hierarchies. The cool thing about hierarchies is that I can now easily create formations of enemy ships!

I also implemented that thing I talked about in my previous post. There is a method called obeyParent(), which can be overridden by any class inheriting from object, and this method basically takes whatever data the current objects needs to inherit from its father and applies it to itself.

So for a torpedo, this is nothing, and thus the method is empty. The ship uses the default, which is to apply the fathers velocity to the childs position. For the sound, I have not figured it out to 100% yet, but one of the aspects is to set the sounds position to that of its father. I believe i might need to mess with some other stuff because the sound is still not perfect when you move around.

In any case, now its time for bed.

I am now working on building object hierarchies.

First of all, if an object plays a sound, that sound should follow the object’s position (especially when dealing with environmental audio), for this I want to make the sound a part of the object.
But there can be several sounds, and if the object is a robot with 3 arms, you should be able to destroy each arm separately.

The children should inherit properties of their parent, however what properties should be inherited, and which should not?

Obviously the velocity of the father should be the same for all children. Of course, each child can also have its own velocity, and the father’s velocity is simply added to the child’s.

What about hitpoints, and other attributes? The question is if any of these variables should be passed onto the children, and also for example, if the children can survive without their parents. Should this stuff be decided on an object level, or during the joining itself?
Also some children such as torpedoes should certainly not inherit the ship’s velocity.

So this leads me to the conclusion that polymorphism, as always, is the answer.
Each object will have a virtual method for hierarchies, this method will grab whatever attributes the current object wants from its parent. I love coming up with cool ideas out of the blue heh.

There is also the question if children should be part of the object manager or if every father should take responsibility for his children. At this point, I think centralizing basic object management is probably easiest. There is one thing that is important tho, and that is that when a father dies, something has to be done about the children, and the question is if the children can survive without their father or not. I’ll need another lightning bolt to hit me to come up with the solution to that one.

For now, signing off.

In my quest of never being able to decide on something, I am going to get some more abstraction going.

Since my code is very object oriented, I was able to create a second game loop file, which used openGL and drew boxes where game objects were supposed to be. Even the movement worked perfectly.

This is good news because I want to play around with 3D as well as 2D and 3D can also be used to help see things like pathfinding and testing of collision detection, since you can easily draw lines and simple geometric shapes. Who knows, maybe I’ll go with 3D in the end.
The important lesson here is that by modifying the game loop a little to include OpenGL init code and other OpenGL related stuff like rotation (to have an isometric perspective), and removing the loading of sprites (1 line of code) since SDL surfaces do not play with OpenGL, I was able to convert my “game” to a 3D engine.

I plan to continue on this abstract path, basically trying to keep the graphics engine and game objects as separate as possible, so that I can decide later what kind of engine I want to use. Since my main focus right now is on object interaction, I can deal with graphic engines later. And currently, my code allows me to do just that. (well, almost anyway! heh)

I’ve added the ability to target stuff. You click on it, and its targeted.

I had a bit of a problem at first, since when targeting you pass the new target to the targeter, but if the target is deleted, then the targeter still targets it and bad things happen if he tries to do stuff.

So i added a thing which keeps track of who is targeting any mob at any given time, so when the mob is destroyed, it makes sure to set all of its targeteers targets to null, thus eliminating the problem. It still has some minor bugs, but nothing serious.

Now I am working with distances. I need to calculate the distance of one object to another, or more precisely, the vector from one object to another. In itself this is not too difficult, but currently it’s proving to be a challenge because of the architecture I have built for storing coordinates of things.

I am going to read up a bit on 3 dimensional vectors and how to handle them in my physics book hehe. But so far its extremely fascinating. Next I will have to create my own vector class which can do all vector related calculations.

I should try to use vectors for pretty much everything relating to position, since as the physics book puts it: In kinematics, we describe the motion of a particle using vectors to specify its position, velocity and acceleration (I payed a fantastic $176 USD for volume 1 and 2 of these books, plus shipping and fucking taxes). This will be something to do tomorrow. Or maybe later tonight.
Right now I am a little pissed off at the problems with circular dependencies and how to solve them in C++ (object A needs to know about about B, and B needs to know about A, wtf??)
So I am gonna watch some anime to relax…hehe

Next step is to redesign my position classes (Point2D and Point3D) to be more like vectors and matrices, since that’s what we are essentially dealing with…

Oh well.

I just had a little thought and didn’t want to waste it.

Since one game mob will have several objects attached to him which need to follow him, all the objects that are attached to one object will need to update their own children.

Of course I realise now that my thought was off base, since everyone will obviously inherit from the Object anyway, but I did realise that if everyone that needs to be moved were to implement an interface that gave them the same method, they could all be stuck into the same array and just updated as things went along.

A mess of a thought… heh, besides interfaces are a java thing, but I am only now starting to realise how important and useful they can be.

Of course every object that has children will have to make sure that it updates those children. How exactly the process will be streamlined is a matter for another time.

Right now I might have drifted off track, but I am currently kinda working on implementing parts of interaction between objects. (”Because it’s more fun then collision detection!”)

Already can you attack a stationary enemy and cause his death within seconds (isn’t that great?), but there is a lot more stuff then that.

One important step is a turn limiter. Right now, holding the A button for “Attack” will drain an enemy’s hitpoints in less then one second. This is obviously because every time the game loops, 10 hitpoints are taken from that bastard. The game loops at around 30 frames per second or more. So it goes rather quick. What needs to be done is obviously a system which creates kind of tuns or ticks, with every action costing a certain number of said ticks and you can thus not use it again until that number of ticks has passed.

This should of course be implemented at the Object class level. Furthermore, since for example different weapons will have different speeds, the ticks would have to discuss this with the Weapon class..

So here’s the proceedings as I see them….

• You strike, calling attack(target);
• The attack method begins the attack animation, and calls the targets takeDamage(int) method.
• Before calling this method, you call your weapon class and tell him that you are attacking this guy who is 50cm in this direction from you, and you have this many skill points in use of this weapon. Something like: Weapon.calculateAttack(magnitude, direction, modifier).
• The calculateAttack method obviously returns an integer with the amount of damage it thinks you would do. Or it returns something else to let you know that you really cant hit the guy (an exception perhaps, or something).
• If an int is returned, you pass it right along to the takeDamage method, which in turns check to see if his master is wearing any protection, or has some sort of evade bonus… (at this point I realise I would have to pass the weapon to takeDamage maybe), and in turn applies said damage to his master.

So far so good, but now comes the part when someone should prevent the attacker from taking another swipe at the poor target, before it is time. Considering the above, we know that the weapon returns the number of damage. Which is bad since we also want it to give us a delay time. So an idea is either to pass some stuff to the weapon that would be modified inside of it (a reference to an integer)… Or, since each weapon has the same delay stats normally, we would simply retrieve the appropriate delay from the weapon after getting our hitpoints. Then of course we would have to consider other factors such as speed modifiers of the player and shit.. But…. one small step at a time.

I wonder if professional programmers do similar things or if they’re all like “UML Diagrams and Shit”… Normally I do my thing with little planning especially when it comes to things I have never done before. I mean, at this point I am testing different things to see the outcome and learn in the process. Once I’ve done this kind of class design, I will have a better idea of how to do it next time. Once I know that like having a global sprite object controlling an animation is stupid… well you know.

I love this gig. To actually see the enemy fall and die by my sword… wow
Crappy life in the game industry be damned, but whatever happens happens.

Java differs from C++ in a major way, which is the fact that in Java, everything is a reference, while in C++, references must be specifically specified.

Basically I’ll get to the point before my food gets cold.
In C++, anything you specify that is NOT a pointer has space automatically reserved for it in memory during compile time and run time. Even if it is not used. For Classes this OBVIOUSLY means that they are automatically constructed as soon as they are declared (or if they are defined in a header file, as soon as the main file is constructed and/or executed).

Thus if you want to keep a class variable inside your program that might not be used, but has to be there, it has to be a pointer to that Object and NOT the real thing.
I was kinda pissed before that you could not test an object for being null. But now I realise the error of my ways. An object variable can never be null since it’s always created. A POINTER to that Object can however be null if it is declared as such.

This is like… “I SEE! Said the blind man.”
One fundamental piece of C++ that has up till now eluded me, is now within my grasp.

There is also an important thing to remember. If you declare an Object, it will be automatically destroyed upon your program’s death, however a pointer must be manually destroyed, otherwise it will never die. If you declare “Animation animation;” inside your Object class, it will be automaticly constructed along with Object (just like if Object had a parent), and it will die together with the Object. However if you declar “Animation* animation_p;”, you must forcefully create it with new, and remember to destroy it in Object’s destructor. Both methods have advantages in different situations, and I am DAMN happy that I finally got that through my thick skull. Makes a lot of decisions much easier.