angelhill.net/code

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.

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!

So I am using C++. It supports exceptions. Coming from Java, exceptions are second nature to me, but I am still having some trouble with them in C++ since they are not quite as well implemented as in Java.

Since no one complains if you have an uncaught exception, it’s not at all as safe to use exceptions in C++ as it is in Java, so after I solve the current dilemma (separating Sprite container and sprite controller), I shall spend some time coming up with a standard method for handling errors, be it exceptions or the old-school error code way… I prefer exceptions tho.

One thing that annoys me is that I cant return a NULL in C++ if it expects a class or something that does not support the NULL value. In Java every class can be declared null, in C++ this is not the case unless you are returning a pointer. Maybe I’ll just stick with that.

Man, with collision detection, the former 1 pixel deep sprites suddenly feel like they actually have volume. That rocks some serious socks. Of course, right now there are plenty of issues to work out, like the fact that if you collide from the front it works fine, but if you collide from the other side, both objects start to move in strange directions. Funkytown, but the algorithms I am using are still pretty basic so there’s nothing to worry about.

I also added hotspots to the metadata of the image. However I’ve been thinking about maybe starting to store more metadata in the image itself. Like in that article I cant like to right now cause the site is down. Basically you store a one pixel border around every tile or sprite, in that border you add pixels of different color for x and y hotspot, transparency color and other useful information, including perhaps the size of the sprite’s bounding box. This can help out in the future I think, if you change an image, you would not have to edit its metadata file unless you change the number of frames. Of course, even frame counts can be made dynamic, since you could just keep loading files until nothing is found like…

Load angle 000 frame 0000, load angle 000 frame 0001… oops 0001 not found!
Ok, next angle 045 frame 0000. At this point you could store the number of frames that were found in the last run and use that number in the future for that sprite. Maybe do the same even with angles. Some food for thought.

I thought I would share a screenshot (above). It’s nothing to be proud of yet, and I got the graphics here , but they’re hitting each other and stuff…

I got a pretty basic collision detection working. In a way I believe this should be really easy since the boxes are never rotated, so in theory my job should be easy. Tomorrow I’ll look into it.
But before that I am going to spend time getting my graphics and positioning sorted out.
Basically, I have make it so that the world coordinates for an object are applied to it’s hot-spot, rather then its upper left corner. This isnt really hard, but needs to be done before I can continue getting any kind of meaningful collision detection tests.

In the end it might be better to go with grid enforcement, but we’ll see. Collision detection is a fun exercise for my maths brain. Tomorrow I plan on doing some vector problems from my physics book.

Now I am in dire need of falling face down on my pillow. Tudeloo!

Here I was, coding like crazy, doing funky-town things. I compiled and suddenly things stopped working.

The error was seemingly unrelated to what I had been doing earlier. So I was confused for about an hour. Eventually I realised that all I had to do was run a make clean to remove old copies of my code and recompile, which suddenly produced easily fixable errors.

Next time you get a runtime error in your program… clean up and recompile. You might just find the solution (it’s already happened several times to me heh)