2020-03-15
Spent some time writing up another blog post on how I want Aspects and similarities to work. That post will probably go up later this week. After writing, I went and sketched up some code to calculate the “similarity index” between two monsters, and made a little command line application that I could use to test SCORLIB components and run through the code without having to run the game and test there. This made it very easy to compare a few different approaches to calculating this index, which I go over in that blog post.
2020-03-19
It’s been a busy week and I haven’t had any time to work on this project, except for some thinking here and there. The last time I started working on this I started to implement loading game data from SCORLIB. This involved parsing flat files into game objects and setting up factories that I would use to retrieve new objects / mobs / items / etc. as needed. This all works really well – I even have loot generation going, very similar to Diablo’s mostly because I straight up stole the Diablo II file format and style of loot / mob generation.
However, I came across a snag: I want SCORLIB to be as “pure” as possible. Meaning, I don’t want to sully the library with implementation details for whatever game “front-end” is using it. So, even though this game is a roguelike and uses ASCII graphics, I still might want to use SCORLIB with another project later. The problem here is I still need somewhere to store graphics-related metadata so my factories can function without huge gobs of code gluing them together and slapping graphics on things. I think what I’ll end up doing is adding a second set of metadata files to SCORLIB in their own folder / namespace and joining the graphics data (colors, the character glyphs representing entities, etc.) with game data. This way these graphics settings are still separate, but also still loaded from disk instead of hard coded.
2020-03-24
Decided to combine two weeks of dev journaling because… well, I didn’t do much last week.
Today I got a good portion of the work done for my monster factory to a) load in all the game data from SCORLIB from disk and b) load in all Monogame-specific data, also from disk. So at “design time” in my tab-delimited text file I can set all required display settings for my in-game objects, divorced from the logic behind it all (stats and other rules). If my parser somehow fails to conver the string to a proper color / glyph representation (like if I fat-finger while typing) then it gracefully falls back to hot-pink foreground, blue background, and ‘?’ as a glyph.
Because all these objects are relatively small in the grand scheme of things, I just hoover everything up into memory when the game starts, so when I need a new instance of something I request it from the factory. Like so many decisions before this, if it does become a problem, I will revisit it — but I want to move forward adding things to the game without spending too much time right now on what may be premature optimization.
The factory stuff isn’t done, but the loading from disk is 90% done. Probably tomorrow I’ll finish the monster factory and start generating monsters randomly for real!
2020-03-25
It is done!
Monsters, both their stats and display info, are drawn from disk into little factories where they can get pumped out onto maps at will. Because of the number of properties and objects that live inside the Monster class, instead of trying to get clever with reflection or MemberwiseClone or any number of things, I just sucked it up and wrote out all the assignments needed for cloning operations. It took two excruciatingly long minutes to do, but in the end it was far easier to write, test, and look at than any other code would have been — and it runs faster, too. Imagine that.
Next it’s time to extend the MapFactory to randomly assign the next map type, then assign that map a Deity type. I think I want the map factory methods to populate the maps with their creatures, as well. I’m not sure what’s next, but there’s a few options:
- Spawning boss monsters
- Spawning monsters in groups based on their monstats metadata
- Implementing treasure classes for loot
Week(s) In Review
Can’t always have productive weeks. When your day job is also programming, sometimes it’s hard to motivate yourself to do more of the same during your free time. In any case, I got a few key things done these past couple weeks, and now things are starting to get “hard”. Designing and implementing systems is easy, but making them playable and fun? That’s the challenge.