Chaswick.net

So I cleaned up some memory leaks that I figured would probably be trouble later.  I may still have one or two lying around, but it is order of magnitudes better now.  I used Visual Leak Detector for assistance.  New updates include extracting the level into a view port so that levels bigger than the screen can be accommodated by a moving window.  This was actually surprisingly easy to do.  It acts as a translator, taking the level-relative locations of cells and glyphs and turning them into screen relative points.  Also added rudimentary random level generation, as you can see in the new flash movie.  Currently it generates randomly sized square rooms with an open end in the center bottom.  Expect more complicated layouts in the future.  The walls also have hit points, like entities do, but the whole hitpoint / combat system is just a place holder for more complicated stuff.  Like, metal swords breaking down wooden walls, but only scratching concrete ones.  I also started setting up the game logic to accomodate multiple levels, as evident from the debug “level respawn” feature in the video.

Next up in the development track, items that entities can pick up, carry, and use.  I’d like to get jack equipped with some kind of ability to temporarily boost his speed.  His framework is all set up for that already, but I need to decide how to give him the choice on when/how to activate it.  As for the player, I’d like to get him wielding a weapon (or not, at a button press).

I have uploaded a new Flash video.  The latest changes include improve sensory input for the AI.  It can now smell a range of squares, and it’s brain will attempt to figure out the best way to chase unidentified entities.  The behavior at this point is hostile, but that can be changed easily to any number of defaults.  While you watch Jack’s behavior, it is easy to imagine him guarding a nest, for example, with only a minor tweak here or there.  I have also improved the status bar so that it could be used to display the stats for any entity, as for example when the hero imbibes a “switch bodies” potion and uses it to [temporarily?] become a ultra powerful vampire.

I also have a very basic “end game’ screen, although I did not showcase it in this video;  If you die, it tells you so, and quits automatically.  Incorporating final statistics would not be too difficult.  Starting a new game after dying should be easy as well.  Saving/Loading the game is probably beyond my grasp at the moment.

I am hoping that by working through all these little issues with the smells I will be able to use some of the code for the other senses (vision in particular).  Essentially the plan is almost exactly the same for vision, with the caveat that of course the “images” left on the various cells (like the smells are left) will not be left under the same conditions as the smells, and probably would not incorporate something like a vector (though that may make sense).  By creating maps of what each entity can sense, and tying that to its current state and individual brain (behavior), I believe it will provide a more in depth play experience.  Poking eyes out, color blind monsters, one eyed monsters, and monsters that hunt solely by smell (Jack for instance) are possible in this approach.

I have a new video demonstrating a revamped look, some more demos involving rudimentary effects and AI, a debug mode which I hope I won’t need much of, and a message window prototype.  To talk about the AI for a moment, where before it was blind, deaf and dumb, now it isn’t (quite).  What I mean is that it has a “sense” (like sight, smell, sound, taste, feel, etc), which its brain consults before decisions are made.  And, yes, now you can see there is at least one decision being made, namely “Do I follow the yellow dots, or go around in a circle?”.  If there is a yellow dot in its square, the AI follows the trail, otherwise it goes in a circle.  It is not difficult to imagine an almost infinite variety of AIs which could be developed just based on this one “sense” and the simplistic “A or B” decision making process.

The debug mode I coded in because it was becoming clear I needed a quick way to consult what a given area of the level “looked like” in code.   The windowing system and display redesign kind of came out of that.  The display is essentially a copy of Nethack or ADOM.  The single yellow number “3″ is Chas’s primary stat.  Unlike some other games, I am planning to employ a good deal of information hiding and discovery in this game, and the idea is that this stat is all you start off “knowing” about yourself.

The movie is again in untimed mode, because I find that easier to test in.  Untimed mode means the game pauses indefinitely for user input, as opposed to a “real-time” game where game time elapses independent of user input.

Well, I managed to add a prototype for entity “brains”.  Plug a brain into the entity, and away we go…This BasicBrain (as I have so creatively named the class) sets up a movement queue that tells it to run around in a circle.  If for some reason it can’t move where it wants to this turn, it skips that movement.  This is a “feature” of the current game logic engine, which doesn’t yet notify entities of things like “couldn’t move;  @ blocking way”.  I expect to handle some of that when the combat engine work starts, which should be soon.

I also changed the way the curses color pairs were managed, putting them into a singleton color manager.  Check out the Pages link under MyRogueLike -> ScreenShots for a cool .swf video of the AI in action.  The game mode is set to untimed turns, so the movement may appear jerky as I input keys in odd intervals.  I am not the Cyan @ symbol.  Rest assured, I have not (yet) noticed any performance problems.  From the movie, you’d think I was making RoguePaint v.01!

The latest screen shot represents many hours of blood sweat and tears spent hassling with std::sort() on vectors of pointers to objects, among other things.  Fortunately, it turns out I am not completely stupid.  Again, the screen shot does not show much in the way of difference, except for one obvious thing.  However, I was able to code in stats for entities, and also even begin working on effects. Currently the stats support permanent and temporary values, with the temporary values consisting of ordinal pairs where x is number of turns the temporary effect should last and y is what the effect is.  I anticipate in the future making the class a bit fuller in order to support various rates of degradation.

As you can see from the screen shot, entities (including the player) have statistics broken down by color.  The on screen avatar is displayed in the color of the highest statistic.  I prototyped a movement effect, which currently leaves the vacated square of a moving entity the color of that entities highest attribute, but I can envision other cool effects that can be done once I sort out how these effects will integrate.  The nice thing right now is the cell basically just asks for any effects, and it could theoretically treat those effects afterward much like it treats the entities.

I managed to get some more work done on the myRoguelike engine.  I implemented a user input model wherein all entities on the map are notified of user input and take appropriate action (currently just moving in the 8 compass directions).  I did the movement in a way that involves using the map to decide whether it is possible, not the entities (although may decide for themselves whether status effects, etc prevent them from moving).  I also implemented movement blocking, which is on by default, so that entities can block each other from moving over certain squares.  So far, it was pretty painless to implement the blocking and the extra inputs.  Because the map level coordinates the movement, it was also easy to set boundaries on movement to the restrictions of the level.  And since all entities (including the player) are treated the same, that movement should hopefully be a relatively bug free issue going forward.

Well, I made some progress, even though you won’t see much difference in the below screen shot.  I set up the basic data structure for levels, and filled a sample level with “cells”.  Those cells currently don’t do anything except display the roguelike equivalent of basic ground, however there is more to it under the hood (I hope, anyway).  I also set up a basic Command class (ala GoF) and started tinkering with user commands.  “Move left” is the prototype.  When I sort out how I want to expose all the various objects and values the commands will need, I can move on to making a basic playground level.

Three new pages were added to the Pages link at the right.  More info to come as work progresses on the project.