It turns out that I won’t have any time this weekend after all. So technically, I have another day, but I’m not going to be able to finish this in 7 days. This actually works out, since in hindsight I don’t think that Betrayal at House on the Hill’s mechanics actually translate quite as directly to a Roguelike as at first I thought. Continue reading “The House on the Hill – Postmortem”
Not much in the way of screenshots today, but I did manage to add quite a lot of framework for content (which I’m going to spend tomorrow fleshing out). Now, the player has four stats (Might, Vigor, Intellect, and Sanity; I don’t think those were the original stats but I don’t have a copy at the moment to check). Each of them starts at a random value from 2 to 5. If any reaches 0, game over.
Also, to actually make use of said stats, there are two new kinds of definitions that you can stick in the data folder to automatically be used by the game: events and items.
Events are automatically triggered when you enter a room for the first time. Eventually, this will include all manner of spooky happenings, but at the moment there are only two: Bite and Helpful Item. As one might guess, a Bite can lower your Vigor or Might and a Helpful Item grants you a randomly chosen item. Right now, there’s only one item: a Book, which grants you extra Intellect when you find and takes it away if you lose it.
Right now gain and loss are the only hooks on items, but I’ll probably add ones for
on-defend to make things like weapons and armor make more sense. I’m just not sure how that’s going to work out yet.
That’s all I have. We’re running right up against the deadline, but it’s definitely a game at this point–albeit not really a very fun one–so I think I’ll call that a win. Doesn’t mean I won’t put a few more hours into it this weekend.
If you’d like to see the definitions for Bite and Book, check out the corresponding blog post over on my blog. It has better syntax highlighting. 🙂
Today was fairly productive, although even with that I managed to fall a bit behind. So it goes.
Today I’ve made it to where I optimally would have been back on Monday, had I actually planned what I was going to do (and not changed ideas and frameworks literally as I was starting to work).
I present to you:
As I was hoping yesterday, I have a player that moves and I have (most of) the rendering code. I haven’t actually randomly selected the room, but the map of room coordinates and the random room selector are ready, I just have to be able to validate that everything connects nicely.
Unfortunately, it’s a little sluggish at the moment, mostly do to the way that I’m drawing. Each time the screen has to update, it loops through each tile on the screen (top to bottom, left to right) and figures out if it’s a room or border. For rooms, it figures out which room and then which tile. For non-rooms, it has to figure out which doors to place (which isn’t entirely working as you can see). None of this is cached. So just in that screenshot above, I have something like 315 room lookups, each on a hash (not a hasheq; that matters).
That could easily be made better by looping across the rooms instead and drawing their 9×9 tiles before moving on. That would improve the runtime but at the cost of being somewhat more complicated codewise. It would also give me the ability to not draw the borders around rooms that don’t exist yet though, which would be nice. I’ll probably do this tomorrow, although it’s going to take a bit. Fingers crossed for no more than an hour.
Then I’ve got monster / event content for Thursday and a bunch of item definitions for Friday. The nice thing about the structure is that all of my room definitions are dynamically loaded (as I mentioned Monday). So anything I stick in the data/rooms folder will just work™. Or at least that’s the theory anyways. Should be an interesting few more days.
Since yesterday, I’ve managed to write a GUI framework in Racket (note to self: next year either choose a language that already has one or make it ahead of time). It’s roughly based on Rot.js, you can read more about the functionality it has thus far over on my person blog: The House on the Hill – Day 2 on jverkamp.com.
After I got the display code working, I played around with formatting and got keyboard input working. So really, I have a fair first step. Here is what the user will see when they very first start the game (for now):
And here’s what they’ll see once they press any key:
You start outside of the house and have to head directly north to the main doors. I’ll probably put some special code in there on the edges of the grass to keep you from wondering off, but at the moment, I don’t even have a moving @…
Theoretically, I should be able to hammer out movement and room rendering tomorrow. That will leave more room definitions, items, monsters, and events for Thursday and just content adding / debugging for Friday. Believe it or not, I’m still completely confident that I can do it. Perhaps I’m just crazy like that. 🙂
For a few more in progress pictures and a full description of the API (I’ll probably bundle it all up once this is said and done, but not until next week at the earliest), head over here: The House on the Hill – Day 2 on jverkamp.com.
Since I haven’t started my #1GAM a month for March (and since my successfully completed January game was a Roguelike as well), this seems like the perfect opportunity to kill two birds with one stone. I may be starting a bit late, but that just makes it more fun, right? 🙂