angelhill.net/code

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…

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)

I need to start thinking about how to get the main idea of a tile based system to work.
In a tilebased system you are supposed to be forced to walk around in a grid. Right now my guys and objects can be placed pretty much anywhere. This of course makes several things look weird, like when characters are standing too close to each other etc.

The point is to enforce a grid. The best solution is to have a multi-size grid, one that adapts itself to different objects. So like a guy would have a grid of maybe 20×10 while a tile is like 64×32…(I believe this is how it is done in Diablo and Starcraft) However this is a lot more complicated then just having the same grid size for all objects (which is what Ultima Online is like).

The advantage of a multi-size grid is of course that you can create large objects that take up more space and small objects which take up less space. In Ultima Online, large monsters only took up 1 tile, even huge ones like dragons. This created numerous graphical oddities like the one you see on the right here with the horse looking like it’s ass is inside the wall.

Implementing a multi-size grid means you need to store the size of every object and somehow use that information for collision detection. I plan on giving it a try in any event. You still need to store height, so why not size. In the worst case, I’ll go with one size grid.

The question is still how to enforce the characters to move within a preset grid. I think normally this is done with screen scrolling. My character currently moves around on his own, while normally in these games, it is the screen that scrolls, and while the screen scrolls, I assume that the walking animation is played.
In mouse-based games where you move to where you clicked, your character obviously moves towards the “grid point” that you clicked on, so that’s easier.

Anyway, some food for thought!

I just realised that there is a slight problem with some of my code.
I am using a Sprite object for every animation (it stores the graphics and controls the flow of the animation), and that object is usually passed around as a pointer to every guy who needs it. This of course causes a problem when two guys are playing the same animation. It becomes synced!
The idea is of course to reduce the number of new objects that need to be created.

Right now the ResourceManager loads graphics and creates a new sprite object for every different animation (for example an attack animation for a guy), these sprites are stored in a vector and are given to any object that requires them at the time. I suppose I will have to create an animation control class that will be part of the object class and the sprite object will simply contain image data… I’ll think so more, but this is probably the best way.

This is not the first time I have done this kind of thing…I really need to get used to the whole idea of shared memory. LOL

Today I thought I needed a lesson in OpenGL. It begun because I had trouble finding good enough info about the isometric perspective, so I thought… “Hey wouldn’t it be nice to have a coordinate system you could spin around in 3D and find out what isometric is all about eh?”

Then my quest for a tutorial on OpenGL begun, and quickly ended here.

Lo and behold, a short while later I was pumping out triangles and cubes and… a coordinate system which I could freely spin around.
Now I have a much better understanding of the system, and can also test out various cool things directly in the 3D engine, like placement of objects and stuff.

Eventually I am surely making a game using OpenGL, the power seems limitless. So now I even took out my physics book along with my maths book, both have joined the pile of opened books all over the place.

Anyway, so far I’ve been mostly streamlining my code, and no new major developments have can be reported today (aside from the 3d engine stuff). I am learning about overloading operators (which is some seriously KICK ASS SHIT!), and basically just doing a lot of refactoring so I can once again start to add new stuff.

Although I really wanna do that thing I wanted, with the clicking on a point and moving the character towards it. I might do it now if I have the brain-power.

Here are some pics of the 3D stuff (first outside the cube, then inside, note the coordinate system) and my desk.

I will probably take a break from engine coding tomorrow (i tried today but failed, maybe tomorrow I will have better luck).

However, here is a list of things I did and should focus on tomorrow or day after:

- Finished basic what-you-clicked-on functionality, it does not however check for transparacy yet. Got the basic idea from this article but did it a bit differently. The basic idea is the same however, simply add objects as they are being drawn into a C++ list container (in reverse order, push_front) and then go through it after all sprites are blitted.

- Check if the pixel you clicked on in the current object is transparent or not, if it is, continue checking… this is not yet done, but will be a fun challenge.

- Work more with tiles. I have done basic ISOmetric tile blitting, now the next step is to adapt movement to the isometric perspective (NE is not 45 degrees in isometric terms), and find some tiles on the net to play around with.
The movement aspect has basicly been fixed with some calculations, I will post them later when I actually understand how they work.

- Work on perfecting image metadata structure. I think my image metadata structure is a little stinky and needs to be redone. I’ll deal with it as the time comes, but now I also need to start working on a map storage structure, collision detection and object to object awareness…

- As I was playing around with the game just now, I realised that while my tiles are printed correctly in regards to who’s on top of who, but the objects are not. At first I was thinking that a static sort order was the way, but now as I was playing around, I realised that I would have to dynamicly change the sort order based on the objects position in the game world. So if unit A is lower then B, A should be printed last.
This has been solved, I created a separate array into which objects are sorted based on their position in the game world, however this will probably require more work since its quite basic at this point.

I think that’s all I can think of right now. Far off notes include networking and sound, but I’ll leave that for later…. Saying only that Sounds will probably be their own objects that extend the standard object class, and can be somehow connected to graphical objects when needed.