Multiple sized actors, menuing, interaction cursor

- Multiple-sized actors means, the creatures you interact with can be different sizes, to a single block, to human-size (three blocks high), to bigger.  This also means multiple-sized players, which will come in handy for things like crawling through low passages... or shrink rays?
- Menuing is working now.  The beginnings of inventories (both player and other) are in.  Item classes are progressing.
- The interaction cursor, which never did much in the prototype, is back, and has a wider array of movement than before and is more flexible, and easier to control.
- Up until now, world generation has been accompanied by flashing colors, just to indicate that something is happening and nothing has crashed.  Now it displays a log-style progress report.

Step by step, inch by inch....

Working menu

I got a menu working.  The difficult part of this isn't creating a menuing system it's making it work with the overall state machine, which affects display, setting up its own state machine, and so on.  I'm not real used to this frame-based, event-driven business, dangnabit.

Menu coding continues

Trying to track down some state bugs in menus.  Also, menus are appearing (in their clumsy current form), but the selector arrow doesn't appear to be moving.

Menus

I haven't done a whole lot of menus in a state machine driven kind of design before.  I keep trying to design something sensible and modern, and I keep noticing how my idea for approaching the problem are deficient.  The perfect is the enemy of the good, I know, but I'm just aiming for fairly acceptable at this point.  I'm going to describe what I'm designing right now, not just to stay public about things, but also because it'll help me keep it all straight.

At the moment the program tracks what state its in in a global variable called basis.  basis is actually an object that links to almost everything about the program's progress for easy saving and loading later, but it tracks overall state too.  Two of those states, and probably more in the future, involve menuing: the title screen, and the inventory screen.  Additionally, some of the menu entries may spawn additional menus according to what's chosen: does the player want to pick up an item, or drop it, or use it, or equip it?

So we actually keep a stack of menus; if we open a submenu, we create a new Menu object and push it onto the stack.  That part is fine.  But the code that actually does things with menus, that is still in the state handling routine that is called every frame, and so that's got to track which submenu it's in.  It seems like I should be able to design this in some better way (maybe the code for handling the menus should be part of the item itself?), and that possibility is distracting.

Hard drive replaced

Well it came down to it, and I had to replace the laptop's hard drive.  Fortunately full backups were already made, and it just took time to do it all.  A surprisingly large amount of time: I apparently have one of the few laptop brands that doesn't make the hard drive easily accessible, and I damn near had to take the whole thing apart!  Here's the step-by-step video I used to do it.  How tiresome.  Thanks a heap, Dell.

Recent progress

Still churning away, although admittedly slower than I like the past week and a half.  Most of that is working in the pizza mines, but it doesn't help that I'm in the part of the coding where I'm implementing the menu system.

One of the things I learned about doing over what I'm going to call the Hiatus Project is designing and coding state machines.  Most games these days are implemented so that they have to call a loop that draws the display every frame, and because this routine has to run regardless of what else in the program is doing, it means implementation of the main loop pretty much requires some sort of state machine, to do the displaying then continue working on whatever else the program has to be doing at that moment.  There are alternatives, but this seems to make the most sense here.  (Python has an alternative called co-routines that presented an alternate design strategy, but other than a generator used during map generation, I've avoided them, because they are a feature that Cython does not yet support, and I'm still aiming towards using that eventually.)

Well the menu system is part of that.  And another thing is ideally the menu should allow for being recursive -- if you've got the inventory open, for example, it'd be nice if there were submenus for determining what you can do with a specific item.  And what's more -- and this is where it gets a little weird -- it'd be nice if this happened while the sim is going on in the background.  That is, I am strongly considering having the inventory window open not pausing the game.

Why?  Well the thing is, while I'm not trying to develop an action game, it is still what I'm going to call a tension game.  Not about performing a sequence of controller or keyboard inputs as fast or accurately as possible, but more about, sometimes, having to decide what to do and get it out of your virtual pack in an expeditious period of time.

There will still be game pausing, of course.  And encounters with NPCs will necessarily pause the simulation portion of the game because it could be a subtle form of cheating if it didn't.  But the inventory window being open, I am considering, might not pause the simulation.

I'm still thinking through the ramifications of this.  What if something important happens while the window is open?  I'm considering popping up an alert message, or if it's particularly serious auto-closing the window.  Well, I admit it's a weird idea.  I might just forget about it.  But I figured I should say something about it.

Various things

Working on an assortment of things today, in addition to continuing to look into something to record the screen (I might eventually have to go with a gizmo that reads the computer's videoout), I'm working on the basics of the menu code.

At least things are moving along a lot faster now than they were!  Spirits are running kind of high regarding In Profundis, in fact.  Dum de doo....

Menus, more movement, and trying to record video

The thing I used to record the original intro was Microsoft Expression something-or-other, but that version also used Pygame and handled drawing in software.  Camstudio doesn't want to record OpenGL, and I've yet to find something suitable to replace it.

In other news, I'm thinking more about the skill system, native AI and pathfinding.  I'm considering using a system, if I have my algorithms correct, similar to that used in Will Wright's classic game SimAnt, where entities leave "trails" behind them that others can follow or ignore depending on what their priorities are.  But I'm still thinking about it.

While working tonight, the MST3K episode "Wild Wild World of Batwoman" was playing in the background.  It's not easy to code while cringing.  How on earth did that movie get made?

Screencasting

The program I used to make movies earlier I can't seem to find, and Camstudio doesn't seem to want to record OpenGL hardware surfaces.  Would anyone happen to know a good, hopefully free, screen recording program?

The Guy

I have a guy walking around now.  Movement is not smooth (in fact, he "steps" along a tile at a time), but that keeps with the conscious attempts to downplay platforming.  Despite this he can jump; it's too limiting not to be able to jump a bit.

If anything, he probably moves a bit too fast at the moment.

Player movement, adapting multitile objects for use as actors, planning native AI & pathfinding

The subject line says it all.