Entities and linked lists…

The overall system of the game is going to be built roughly similar to the pygame version. However, with switching to a language where memory is actually important, managing a dynamic number of entities requires managing a dynamic chunk of memory. Not having linux/being too lazy at the moment to get a linux worksetup going means I dont have valgrind to profile the memory usage either. 😦

Ah well, at the moment, a basic linked list is in place for entity management. Put simply, the plan is that anything declared to be “on screen” or, very close to the screen (within a z level, or two adjacent maps, X number of tiles away from the border, what have you) will be processed using this list.

You can find plenty of linked list tutorials out there, so I won’t go into too much detail, but put simply a linked list is a list (or array) of objects/items that are linked via pointers. To iterate through them, you can simply make a pointer (called ptr), and traverse through the list by setting ptr equal to some root or head node, and then repeatedly calling ptr = ptr->next, where “next” is itself a pointer to the next item in the list.

Pointers (and linked lists…or some form thereof) are necessary because arrays require you to know how many elements you want. With a list and dynamic memory, you can (efficiently) make an arbitrarily sized array, at the cost of some mental complexity in juggling around pointers.

On the actual game end, I’ll end up using this list to handle entity processing, as already said. For each entity determined to be on screen, change their location according to their AI package.

In addition to this, I want to add in some basic collision detection – which is tricky. Currently “collision” is handled via checking the heightmap, but that’s obviously not going to work when you’re wandering around a city.

I could have another 2d array that is populated with ints corresponding to tiles (and collision information by extension), like the pygame project had. But, I could make perhaps a 2d array of pointers, each of those pointing to a linked list representing everything on that tile.

Even when I get collision in, eventually I’m going to have a dynamic array of monster-entities floating around the map, item-entities taking up cells, and tiletype definitions. Having multiple arrays for each would be aggravating, but so might be juggling around pointers to handle movement… Pointers seem like the most logical solution, though.

Game design itself is going to be rewritten away from fantasy, at least for now. Zombies might be quicker to implement. But I’m still just getting the ‘machine’ itself running, so I dont have to worry about that too much at the moment.

Short-term future.

I’ve since updated the map algorithm to provide rivers and more “whole” landmasses. I’ve also now got mouse support included into this “roguelike”, as controls now are WASD for movement, and the little guy will face the mouse location.

I think one of the next directions is to begin dealing with AI. This will require (roughly in order of importance):

dynamic queue for entity processing
AI packages:
AI schedule implementation

as far as schedules, a first pass attempt will likely be a schedule consisting of sleep->work->eat->play, where each state consists of a location to go to (sleep = bed, work = behind an NPC shop table, etc), time spent at each state, maybe special anims for working, and get that running. This largely depends on the follow/go_to implementation, which underneath that requires a good fast pathfinding algorithm.

Posted in Uncategorized. Leave a Comment »

Rebuild incoming…

Code’s been moved over to http://code.google.com/p/pet-project-code/. Use TortoiseSVN to download the code. For now, Windows only.

I’ll be rebuilding this in C with allegro, and things are now moving quite a bit faster as I’ve already done a good chunk of this before. One significant halt on my development is that pygame (and SDL) use an event queue to handle keyboard inputs. Allegro handles input in a brute-force kind of way, sort of like a while(c = getchar() ) type of system, plus some flags that tell you when keys are pressed or not. I’ve got a rough idea of how to go about fixing that, and for now I’m happy with what I’ve got.

Time is a completely different matter. If anyone uses microcontrollers, time systems in allegro are handled like an interrupt. Every Xth time increment, a special function you write gets called that you can use to manipulate time.

What changes will come? Gameplay-wise, things are going to be partially turn-based – basically an evolution of moving this thing into real-time, without it being too different from the standard fare. There’s going to be some hand-built maps, and I’ll try porting in my old python level generators into this current project. I’ve already got a worldmap generator that suits my purposes.

Time-wise, I’m going to try to do short stabs at the code throughout the semester, and see how that goes.

I’d write a post about the level generator, but it’s just an application of the diamond-square algorithm. This explains it pretty simply especially the picture:

Why C? I spent a summer playing with C, and in theory I can write code that runs faster/more efficiently, as I have a decent idea of how C operates ‘under the hood’, rather than python.