2020-03-02
Spent too long rewriting FOV code because monsters were being drawn even outside the player’s FOV, only to realize my calls to get/set “isvisible” were setting the wrong property. Rewrote everything for nothing. Instead, called Animation.IsVisible, and they turned invisible as expected.
So I reverted back to old FOV code and set the appropriate flags there. Tomorrow: – Rearrange UI consoles – add “DialogueWindow” to handle dialogue and message pop ups – add “InventoryWindow” to show inventory
2020-03-03
No need to implement special Dialogue windows. SadConsole already implements Message and Prompt windows. Message windows allow you to show a simple message window with text and an OK button, while Prompts are yes/no dialogues with Action as a result callback.
Instead I’m going to focus on the UI a little bit. I want to make the MessageLog a little more readable and add a hotbar / belt style window which the user can click for useful actions like drinking a potion.
I shrunk the Adventure window and centered it, along with the MessageLog. On the left side of the screen is the Belt, and the right has Stats. For now, this layout will be good enough. I’m not going to work on an Inventory window right now, since there are no real items to speak of. This UI will suffice. It’s time to start working on:
- spawning monsters
- log messages when a monster is seen, how aggressive it looks, etc. – partially done (need aggressive check)
- add monster to Stat window with neutrality ([n] for neutral, [a] for aggressive, etc.) and health
- make monsters aggressive toward player attack player
- make monsters aggressive toward each other attack each other
- make neutral monsters do nothing
Procrastinated by setting up blog. Procrastinated a bit more by setting up a git repo for the project. For now it’s private.
Progress so far:
2020-03-04
Decided to bring in a fork of SCORLIB from the old project. A lot of work was done there for the little details that I will eventually be using, mostly in the ActorInterfaces namespace. I’ll probably drop the ‘xxClasses’ folders in favor of implementing the interfaces in the game itself, rather than the library. I just didn’t want to rewrite all this stuff.
Got caught tinkering with MessageLogWindow because I didn’t like how some code could cause null reference exceptions if a monster spawn in the wrong spot at the wrong time — order of operations on generating map & FOV then logging monster appearances. While tinkering, noticed SCLR uses ~165MB memory almost right off the bat. Just for fun I looked at the old scrl and saw it used around ~70mb. A memory snapshot shows ~30k SadConsole.Cell objects and ~30k EventHandlers — an event handler for every cell? Is this a SadConsole 8 thing, a GoRogue thing, or did I do this by accident?
Looking further into the dump it’s partially GoRogue, partially me. In this fork of the GoRogue.SadConsole helpers library, the “Tile” class instantiates an event handler on every single tile. With a 100×100 map, this adds up. There’s a few other issues in here too, but I’ve just decided to leave it. Focus on the game first and come back to the memory later to clean things up.
Couldn’t leave the message log how it was, so I move the queue away from the UI so it’s a static queue with a set size within the library. the ui just draws the messages and that’s it. Dropped 10mb of memory by dumping the scrollbar? Interesting.
Moved FOV calculation out of base LivingCharacter into the Actors descending from it. So Player does Player’s FOV, Monster does Monter’s FOV, and no more checks for “if ControlledGameObject” or anything like that.
Monsters will log when they first spot the player, but that’s it right now. I won’t be doing the aggression-check stuff until later. I can spend time doing basic “move in player direction and bump him” attacks, or I can spend time on a command / scheduling system. I think I’ll do the latter, but dunno if I want to do that today or later.
2020-03-05
Debating the merits of using GoRogue’s Actions vs. building out / rebuilding my own command and scheduling system. GoRogue’s feels a little overengineered for my needs and I feel that if I try to conform my own work around it, I’ll end up fighting it rather than being productive.
On second thought, I think I will try the GoRogue way of things. It has many moving parts, but allows for more flexibility for each entity to manage its own actions, rather than a central processor processing actions for everyone. We’ll see how that goes.
(later) Turns out that was easier than I thought. Monsters just sit around and wait to die, but combat technically “works”. Player can hit, miss, etc., based on his and the monster’s stats. Very basic, but it gets the job done for now. When the monster dies, it’s removed from the map, and the player can move into that spot.
Next:
- Make the monster drop some gold or something
- Make the player pick up that gold when he walks over it
- Make monsters who have sighted the player move toward him to attack
Later:
- Add / update a scheduling system so monsters and players move at their own speeds, and so that no one moves if there’s no player action taken
Right now:
- Add a small display to show in the UI the monsters on-screen with a health bar
2020-03-06
In true Me Fashion, dropped the last thing I was doing – not going to display monster health on the sidebar for now. Just went ahead with dropping items when monsters die. This involved:
- Adding ItemBase and ConsumableBase
- Adding an Inventory with a limited size and stackable consumables
- Adding a Gold class – for now inherits from ItemBase, as it’s “outside” the Inventory, but I might change later and make gold a Consumable inside the inventory so it, too, takes up space. This feels… draconian.
Now, monsters drop gold on their deaths (that’s it right now). When a player tries to walk into gold, he picks it up, but doesn’t move there.
I think how this will work in the future is a player can move onto the gold tile and auto pickup, but items must be picked up manually. I want multiple items to drop on one tile, and when the player tries to pick up, a dialog pops up showing item details and the inventory, and the player picks which ones to get.
As a side note, I need to be more disciplined on my commits, and commit when something is done and working instead of letting it all build up over the day…
2020-03-07
The ActionProcessor stuff from GoRogue wasn’t working out for me. When it came time to implement an actual scheduling system on top of it, I struggled with conforming my own ideas to the action stack concept — instead, I went with a Scheduling System / Command System similar to my old project, where the Schedule is a sorted dictionary of times and ISchedulable entities. The game loops through the schedule and executes actions for each entity at a given point in the schedule, waiting for input when it’s the player’s turn.
This way, a monster or NPC can have a faster/slower speed than the player and thus act more often or less often, depending. Not going to be usable or useful for a while, but it’s there for me.
I also made it so you now auto-pickup gold when walking over it.
I got tired of crawling through caves to get to monsters to test this so I just made a “map generator” that generates a single room. This room is always “lit”, but the player sight is still small, to test monsters appearing and those types of messages.
Next, I implement pathfinding. What I want is for monsters to move toward the player while they see him, and if he leaves their sight, they continue moving to his last known location or until they see him again.
Week in Review
It doesn’t feel like a great deal of progress was made this week. I spent most of my time shoring down systems in place, making sure they worked well enough, and moving on. So there haven’t been any gameplay additions. I’m okay with this for now. My first (non-blogged) days were spent on map generation and endless tweaking of stupid nonsense that doesn’t even exist anymore, so in comparison I was very productive while I blogged!
Writing out what I have worked on, and then what I intend to work on next, has been very helpful in keeping myself on track and away from falling into the pit of nonsense work. I have a good feeling about moving forward and the progress I’ll make next week. I think, at least for the near future, things are going to speed up some, and I’ll have something moderately playable and fun.