angelhill.net/code

How about this idea…. Python is a pilot, and C++ is the ship.

Basicly I figure that I still want to keep most of the object infrastructure in C++ but let python control some objects such as ships.

I did come up with the idea of sending extensive data back and forth via lists rather then separate methods for everything… this will surely save time and code, since I wont have to have a method for every little detail that python or C might need to know about a ship.

In any case, I am still working on this whole integration thingie.

An important thing to consider:

At the moment, most default values for speed, names, hitpoints and such are all set inside unchangeable C code.

And python has no way to change it. This is bad, simply because python should be the one dictating how many hitpoints the Player ship has and what the speed of torpedoes is.

Tomorrow (or whenever i get time to continue with this), I shall thoroughly look over the control that python has over the objects, and try to decide how to give it more control, as well as get the communication between python and C++ code improved.

I believe that C++ should keep track of objects collisions and such, their life or death state etc, and report any change back into python, while python will be the one to set the values.

Still hungry, and tired.

After coding for a few hours, I’ve come to a pretty decent idea of what I am dealing with.

At the moment, sprites and sounds are completely separated from actual objects.

Well, sounds are actually extensions of the base Object, and sprites are stored in a MAP with the object id being the key.

The issue right now is that there is no way for the object to inform the sprite as to what graphic it wants to have.

Earlier this was done with the object type string, however the object type is now an integer and is more a generic type to help with the creation of the correct class in python.

I realise now however, that the reason python was using strings for object type was simply because the strings were equal to the class names inside the C++ code. I think I will go back to that for simplicity.

Also, the whole object type thing, while very useful for torpedoes, still needs some clarification as to it’s role in other instances.

As for which sprite will be assigned to which object, perhaps the addObject method can simply accept the name of the sprite that is needed, or even better, the python code will use it’s newly created Action code to assign a sprite to an object, until such a time, the object will simply be a floating piece of nothing.

However upon first creation of the object the action code will assign a sprite by default so we dont have to do too many method calls for creation of every object.

Basically this post if full of random thoughts, so i can remember this stuff tomorrow.

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