Slow days, they have been.

Not too much to update on.  At this point the project is getting a tad crazy, just because there’s a lot of different things I can tackle now and I still havent really settled on which one to work on yet..  Off the top of my head:

Visual inventory
GUI elements
Monster pathfinding
Monster combat
NPC template
Container objects
Item interaction

Kind of burns me out when I think about everything I still have to work on and so many choices at this point. Blah. Spent a few days thinking about some of the later systems I plan on implementing as well; not sure if I’ll even use them though. There’s something to be said for simple games being better than overly complicated ones.

0.0.5 Release

Minimaps and AI.

Minimaps and AI.

My small attention span just kicked in.

This isn’t as significant of a difference compared to release .4, but adding in wandering monsters made me feel all happy inside. Rudimentary combat is there, meaning I have something that kind of sort of not really resembles gameplay! Collision detection isn’t all there just yet–creatures seem to ignore doors and will land on the player tile without doing anything, and their movement state is processed only when on-screen, and if they go offscreen sometimes they enter a black void area off the map, but that’s because I dont have full collisions implemented yet. I also have not yet implemented that collaborative diffusion/scentmap pathfinding yet, but I soon will.

Oh and I have a working and speedy minimap now.

Movement

So going along with entities, I think now I’m finally ready to start introducing basic AI into the game. And by basic AI, I mean “stuff needed to prepare for actual pseudo-state machine behaivor”. A series of posts here went through a bit of discussion about the A* algorithm for path finding and alternatives. Well after trying A* and, though this explains it really nicely, I couldn’t fully wrap my head around implementing an astar(start,end,gridmap) function and examples of it had a significantly lengthy set of code.

So looking at that other thread, it looks like a ‘scent’-based tracking system might work better. Specifically what I’m thinking of is that collaborative diffusion method talked about in that very first link. It seems simple enough, in that you just recursively flood fill an area to a certain depth with values, and other entities walk through the lowest/highest values it comes across to reach the player. Now the collab link overhypes the design a little much–the 2 pacman ghosts appear to be collaborating because each time anything happens, pacman’s “scent” map is updated and takes into account the moving entities to block off the scent paths, and an A* algorithm that is continually called like that I imagine would have the same effect.

That said, implementing this scent pathfinding is already proving to work with–I’ve already got something up that generates a very basic map, and to create boundaries, simply give the boundary tiles a very high scent value–anything higher than the currently examined value is ignored in calculating the scent map. The net result from just a plain area with no obstructions yields:


000000000000000100000000000000
000000000000001210000000000000
000000000000012321000000000000
000000000000123432100000000000
000000000001234543210000000000
000000000012345654321000000000
000000000123456765432100000000
000000001234567876543210000000
000000012345678987654321000000
000000001234567876543210000000
000000000123456765432100000000
000000000012345654321000000000
000000000001234543210000000000
000000000000123432100000000000
000000000000012321000000000000
000000000000001210000000000000
000000000000000100000000000000

Where each number is the ‘scent value’ of the tile. Adding in obstructions works, but representing it with 0-9 is hard to read. From there it’s a simple matter of if Entity.IsOnAStinkyTile: FindStinkierAdjacentTile;MoveToStinkierTile.

Grab it here.

Entities

So I’m pretty close to getting objects/npcs/creatures working in this thing, at least on a preliminary level.  Trees are back running under this entity system, and I have some hardcoded items that make use of specific assignments to create the effect of picking up an item and having your stats modified.

The meat of the system is the Entity() class, which controls worldmap-related entities–trees, monsters, and so on.  In terms of a top-down tile based game like this to create an entity there’s a few things you need:

An image to represent it on the screen
worldcoordinates
any important statistics
what happens during a collision
some sort of update package

This is all in terms of worldmap-based entities; inventory items, once they’re in the inventory is simply an array of data and nothing more.

But essentially the above items are created and tracked through the Entity class; initialisation sets a self.type parameter to indicate what type of entity we’re talking about–currently a tree, item, and closed door are the 3 available item types. A tree doesn’t do anything–it acts like a fixed sprite on the gamemap that matches the worldtile it should be on with each update pass.

However the closed door entity, for example, is a little more useful–it has a certain set worldcoord pair, it has no update package, and when the player bumps into the closed door, it deletes itself and reveals the underlying tile–that of an open door picture–thus giving the effect of what looks like a door opening. So what really happens in the game is that when you open a door, you aren’t actually setting a door’s status to Open–you’re deleting the door instead. Closing the door can be handled by creating a closed_door type Entity above the open door tile when the player presses say, C to make it look like the reverse just happened.

Similarly, when you run across an “item” type, “item” has a property of self.stats, which is a simple string of say, “136”. When the player bumps into that, you call player.inventory.additem(“136”), and the 136 is essentially an address to a config file defining what item type to add: 1 is the item’s equip location, 3 is the armor material, and 6 is the armor quality. Then a separate process handles playing with Player.inventory to add the right stats and names. Once that gets loaded into player.inventory, we delete the “item” entity from the gamemap, and print a message saying you picked up something. To give the effect of dropping an item, we simple reverse the process–create an address for the item, create an Entity.item, give it the id of “136”, and set it’s position to a nearby tile and pop out the data from the player’s inventory stats.

Though I havent yet implemented it, this will give rise to a really flexible entity system after I generalise all of this out. Instead of having a .type of “door” and .type of “item”, we can give an Entity the properties of “disappears when collided” for a door, and “disappears when collided” and “call additem(addr) when disappearing” for an item on the ground. Later on, I imagine I’ll be able to add an Entity with properties of “disappeared when collided”, “call additem(random) when disappearing”, and “move towards player during update” (or perhaps a more general “figure out what to do during update” function) to simulate creature behaviour and getting stuff off its body afterwards.

0.0.4 Release

We have liftoff!

I now have a working pseudo-GUI in this release. This one has a fairly lengthy list of changes.  Also, all screenshots have been migrated over to this site.  Check the tab up top.

Full changelog:

Code has been expanded out:
-Trees are now considered Entity objects (which will soon branch into moving creatures, hopefully), although they are not yet spread around grass as random noise.
-A working text window is there
-All print statements are handled through this window
-Going along with this, implemented text usage with Liberation open fonts (https://www.redhat.com/promo/fonts/).
-Though you cannot see it, a framework for player equipment is there.
-Collision detection has been solidified with a new Tile object property “blocking”
Graphical/Tile related:
-The environment tileset has been pared way down to the tiles that are actually used in this thing.
-Grass is not as ugly and repeats in 3×3 patterns instead of 1×1, independent of map generation.
Misc:
-Outdated files in subfolders have been removed

When bored, make tiles.

New tilesets

Or try, anyway. Nothing really noteworthy about this as it’s just a few tiles, but I can comment that making a 32×32 square with enough details to clearly show what it is you’re looking at AND making it fit within a visual style is difficult, and I’m not fully certain I even accomplished this with these tiles.

Now one easy way to cheat that is to make more tiles. Case in point, the grass. There’s really a 3×3 grid of 32×32 sized tiles being blitted repeatedly, and it essentially works by giving each tile a value of 0-8 and translating that number into an XY offset of where to pick up the rest of the pattern, and then when it blits said tile, before it does that it checks to see if it’s supposed to do that–ie, don’t offset when it’s a wall or floor or what have you.

Other thing is that I’m no longer using that 1.2MB png to load up all 8-9 pictures and instead am using a sheet that has only the ones I’m using on it. Yay.

Aaand the final result.

tadaa!

With working transparent drop-shadows, too! Gotta mess with it a little more as currently I’m just hard-coding blit calls when it could be done somewhat modularly, but..eh. It works. 🙂

Screenshots have been moved over to this blog, so you know. Also, fixed pagewidths are a pain. -_- I think this will be the layout for the time being.