Hello again! Day 2 has added a lot of new features, but the days are starting to blur together. At the end of the day I felt I had gotten very little accomplished, but writing this I now see that most of what I thought I added on Day 1 was really just a morning addition on Day 2 that I had forgotten about.
First things first I wanted to add in a ranged combat system, but that requires a way for the player to target creatures. So after adding a tab-target system and target information UI (see screen shots) I got to work separating out my Fighter component into ranged and not ranged stats. Then like a good USB stick I reversed 3 times whether cover % was a bonus or a penalty – eventually getting it right. Then I upgraded the Lantern Archon to have a ranged attack. However it was very difficult to tell who was shooting at you, that needed a solution.
ASCII based console graphics are great, but I do have the full Game Maker engine available, so why not use it? I added in a ranged attack special effect that shows tracer lines from ranged attacks. Colored, and fading as appropriate; nothing special but it makes the game playable once again. Until I ran out of enemies at least.
One giant floor is great, but infinite giant floors is better. I added a concept of a usable object and setup triggering them if the player ‘waits’ on top of them. Overloading ‘wait a turn’ and ‘use the object I’m on’ is great for accessibility and learning curve, but it does box out tactics like waiting on the exit or other eventual usable objects. A fair design trade in my mind.
Once I had an exit working I needed a place for the exit to go to! The world carving logic from Day 1 was modified to take in a starting position – the first room would always contain this point. That way the exit and entrance are in the same space between floors and I avoid the hilariously bad procedural pit-fall of “keep generating until it happens to work out”.
Now that I had multiple floors to explore I needed some new enemies to populate the ever increasing difficulty. So in came the generic Demon Solider, a hitty-shooty hybrid with way too good of stats for the starting player to handle more than one of at a time. It was time to add in player progression – but alas technical pre-requisites were not there.
Menus. Menus are a convenient way to turn a game into a multiple choice quiz. I want the player to understand what they get when they level up and have some say in the matter as well. So I created a basic menu stack full of menus full of menu items and adjusted the game input and rendering accordingly. Having a strong tools background this work was quick, clean and very boiler plate. An hour later, ta-da menus! Now back to that whole leveling up bit.
I stepped away from the keyboard a bit for some curry, because curry is a lovely design aid. How do I want to handle progression? I could go loot heavy, but then progression is based on the Random Number Generator(RNG) gods – not a good player experience. I could expose basic stats like health and damage to increase each level, but then progression is a list of numbers that go up with no interesting bits – not a good player experience. I could use a Perk system ala Crimsonland, but … wait no actually that is perfect.
Perks distributed via a board game standard “Consider X Keep 1” method allows for target player growth without the safety of always having the optimal build available. In addition if I give Perks pre-requisite Perks I can effectively create classes – especially if I start the player with a “Character Creation Only” perk. Perks also allow for expansion as I think of it, adding a perk should be quick and easy. The Consider X Keep 1 mechanic also gives me a design lever to pull on exactly how many X is. Perks that let you consider more perks, items that grant you extra considered perks at your next level up, that sort of thing.
With that figured out its now time to start in on implementing Perks!