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.
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!
Problem with current system:
When you delete an object from the vector, it probably becomes so that
the index numbers are suddenly shifted, right?
So if we have a monster who is 3, and 2 dies, then 3 becomes 2, and
monster 3 is left without object… we’ll need to test it.
Perhaps I need to rethink it more fundamentally, or use hashtables.
[SOLVED] Also right now the whole thing bugs out if you delete something
from the vector, obviously this is due to the fact that when you empty
one piece of a vector, it is still there when the program tries to
display it or delete it when you quit. Need better solution.
[SOLVED] Also in Python, right now we remove the reference to the monster
object to kill it, IE assign a 0 to its host variable. This is great,
but not safe. The best way is probably to delete it first, then assign
a 0, making sure that its really gone.
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 
