angelhill.net/code

I added a new method to the base object called destroyAllChildren. This one not only makes children into orphans, but also kills them, meaning they are garbage collected and removed from the object manager upon the next loop.

This has proven useful when we add sounds as children to objects. Because as the object is destroyed, so are the sounds and any other children that are associated with it. However it is also a problem because even though a ship is destroyed, it’s torpedoes live on. So I think this method will surely not live inside the constructor. I think the best way to get rid of all useless sounds is to make their isAlive method return false when the sound is done playing.

Also I just noticed how cleverly (I think) I handled the sound issue. By making sounds into extensions of object class, I have simply been able to add sounds into the very same object container that holds all the other objects. Making sounds into children of objects, I am able to give sounds position data from their parents without relying on specific functionality in the object manager.

This seems to work extremely well, and the only downside is that right now sounds are not automatically garbage collected because their isAlive method always returns true. If I could simply make it return false when the sound is finished, garbage collecting sounds will be a piece of cake. Or rather, it will be done automatically since the function is already there.

Perhaps a similar method could be used for graphics. To create a Graphic or Animation extension of the object class, and assign this graphic as a child to whatever object it should be assigned to. Then make it’s obey parent obey the parents every move (not just match velocity), and we’re good to go. This might be the best idea I’ve had yet.

The cool thing is that with this method, we don’t need too much special functionality in the object manager, and we can also extend the Graphic object with more details such as multiple layers and whatnot.

Hungry. Must eat.

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…

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 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.

Been doing a lot of code refactoring and its been partially driving me crazy. Most of my code is obviously still on a testing level, and I suppose it shouldn’t be so strange that stuff gets fucked up if you fix one thing.
There was some seriously dirty stuff in there, part of it because of my ineptitude with C++ and part because I just wanted a quick fix to get it done.

Although I now have fixed the sprite issue mentioned earlier by embedding one Animation class in every object (the Animation class in turn calls up whatever sprite it needs and controls the animation on a per object basis), there is still plenty of class design issues to go.

The Object class is the first one in line I think. The key is of course to make it as barebone as possible and just extend it with classes for different types of objects.
Here’s a list of some derived classes that I can think of:

• Mobs
• Containers
• Walls
• Doors
• Floor (water, carpets, roads etc)

Of course they will all have their own derivatives too, but those are the base sub-classes.
I am currently in the process of trying to design the process of interraction between Python and C++, and trying to decide whether I should create base sub-objects in C++ and allow python to use them and also extend the super object, or if I should create all sub-objects in Python and go that route.

To decide that I will need to map out the game loop and see how objects will be controlled and by whom (C++ or Python that is). Right control is split 50%, and it looks really messy.

So the question is where to start.
I think I’ll start by cleaning up the Object class and Game Loop. I also need to clean up the Sprite class a bit and the Object Manager.

Each object needs to know where it lives. Man it’s complex. I’ll think about this more tomorrow. Right now I am gonna watch some GunGrave and go to bed.

Kyou wa gokurosama deshita!

Wow, today big day.
At this point you can create new characters on the screen, while for
now the python script does not have enough influence over the c++
stuff to actually control the new object (except for animation), we
are closer then ever.

Here are some problems that I have to solve:
- How to access a method inside a class instance?
- How to deal with input and effect?
I suppose the best way would be to send keys to the python script,
but that means python will need to handle all that processing. The
solution must be somewhere inbetween. Perhaps a table of keys and
their respective methods?
- If current animation is already the same, don’t do
anything. Performance tip.

So tomorrow:
Make it so python can control characters on the screen.
Implement a host of standard functions in C++ which will for example
perform complex maths operations (like movement) and other stuff. Try
to limit Python code to simply calling methods and text processing.

One annoying thing:
It would be nice if I could find a way to allow Python to call methods
directly within an object, because as it is, I need to create
duplicates for every method. Although I just realised that it is good
from a security point of view. Since it means that all commands from
python must first be approved by the python caller…hmm indeed.

Memory and Destructor concerns:
Gotta do some work on destructors and things. But so far so good