I taught, had meetings, cooked and had a nice dinner with friends in my household (we're in a "pod"), spent a few hours actually cleaning up and backing up some hard drives tonight, so I spent less time on this than I had hoped today, but I did get stuff done, and I tracked down an annoying bug.
ðēðēððēððģðēððģðēððģðģðððģðððēðģ ðēðģðððģðģðģððģðēðēðēððēðģððēðģððģ ðēðēðĩððģðēðēðēðēððēððģðģððģðģððģðē ðģðģððģððēðēðģðģððēðģðððģðēðģððģðģ ðēðððððēðģðģððģðģðēððģðēðēðēððēðē
Today I mostly explored terrain. I kind of decided to keep exploring emojis for my tileset. Perhaps this is a mistake. Emojis, at least to me, are often "ugly aesthetic." But I use them! One thing that's nice is that they are probably present on most people's systems. And there are already a variety of clear options for the player avatars, enemy "sprites", terrain, objects.
For example, here's a clear trophy like in Indiana Jones and the Temple of Doom. Very roguelike-y to me, and pretty clear that this would lead to the end of the game or be a big prize to get in any game.
ð
So if I proceed with emojis for my tileset, I'm thinking about avatars for the player. Does this get selected by the player? Or does the player select a class like in so many other roguelikes, and that determines the avatar? If the player does end up playing this game over days, weeks and months, it's important that they feel connected to their avatar on screen, and I think that would be aided by the player getting to choose their own avatar. Here's some of the options I'm looking at. Notice that these each speak different vocabularies.
const avatars = ['ðģ','ðķ','ð§','ðĪš','ðĩ','ðē','ð§','ðĩ','ð§','ð§','ðļ','âđ','âš',ðĪ ','@']
Ok, so to just get moving, I now have the program choose a random avatar emoji from this array when a new dungeon-game gets created.And I am testing moving using flags. So for example, to move left currently is:
node dotd --left
or
node dotd -l
That's probably a bit silly but i'm going with it for now. I'm using yargs to parse the flags in the CLI.
Just had an interesting idea that perhaps the player submits a short program file like 'right right right up up right' so that you have to program your player-robot, and that you submit that and it runs. Would that be interesting? Rather than turn-based? I get too many ideas but should probably just proceed with standard, and then modify later if I don't have a clear goal other than 'wouldn't it be cool if....".
Tonight after coming back to things I noticed an annoying bug. When opening a saved game file and loading the terrain would be slightly messed up. One char to the left or right of the player wouldn't render correctly, and the player would be a few spots over from where they should actually be. I tried all sorts of things and after some brute force debugging and console.log'ing I realized I was rendering the terrain at the wrong time, moved it until after saving out the terrain/game file (so it doesn't over-write anything in the dungeon permanently). And now it works fine. One question: should i be saving all of the terrain tiles? Quite possibly. So then maybe i should save it out! Or save it to a json table? Seems silly. The issue of why/how to save would come up if tile persistence of terrain is necessary. If a player moves left and walks over a tree, should that same exact tree be there after they walk off? I think so. That's of course the standard course of fare. I mean, I only have different tree terrain not because they act differently but because of 'visual interest'. Would a player notice if the trees were scattered each time they loaded if a day had passed? Maybe? Anyway, I'm tired and will revisit this decision in the next few days. Am assuming I should store all tiles in all positions. It's not particularly computationally difficult.
Next step when I come back is to add gameplay mechanics. I think I'd like to have tents, markets, lore?, conversations? monsters? What else?