Another brief, but very productive day. Lots more replay value, and a better progression curve.

This slideshow requires JavaScript.

Today was the last day for new features, day 7 is polish and bug fixing. A New feature that was direly needed was some more perks to be able to take on those scary Seraphs. While looking at that area of progression I found a great place to add more replay value too. There are now two specializations of each [firearm] perk slanting in the demonic or angelic directions.

• Rifle
  • Holy Fire – Ranged attacks ignore armor
  • Paradox Trigger – Ranged attack rolls are rolled 3 times, the best result is used
• Sniper
  • Reaper – Ranged damage in increased by 15; (IE things die when they are far away, but its still useless close up)
  • Heartseeker – Ranged minimum distance is reduced by 7, there is still a range where its too close to use, but its much kinder
• Shotgun
  • Storm of Vengeance – Shotgun spread becomes much larger
  • Tentacle Whip – Gain 1 hp for each enemy hit

Seraphs, while still scary, can now be overcome – so a new challenger, the Pit Fiend. Regeneration, Demon Armor (more regeneration), the new Tentacle Whip(more HP gain), and a boat load of HP. Bringing one down is an impressive feat.

The flow of the game leading up to such a frightening foe needed to be a bit more streched out to allow enough time to collect perks to be able to have any chance at handling a Pit Fiend. The flow of levels is now a bit gentler and a bit longer.

Short day 5 was. I’m on vacation from work, not from my social life. Still, got a few solid hours in during the morning.

This slideshow requires JavaScript.

The game now begins and ends. Sounds silly, but adding in the flow of game entrance and exit is usually bolted on at the end, like it was here. There is now a character name entry menu at the start of a game, and a stats/score menu on the way out letting you know how you did. Minor sounding, but the play session is now well punctuated and it feels much better than being suddenly surrounded by grunts after teleporting only to figure out shortly that you died somewhere in the immediate past.

I also added some new branching [armor] perks to give more choice than ‘what order do I get everything in’ to the player. Right now the game is a bit short and abruptly ends after you get to the first level with only Seraphs and die horribly. Going to focus on smoothing that experience out a bit during Day 6.

Over half way! Day 4 saw a lot of design progress and the game is much more approachable and enjoyable than it was after day 3.

This slideshow requires JavaScript.

As planned from the previous day, I created a character sheet that shows the players stats and perks. Then I realized that the generic object system I had would, for no development cost, allow me to show character sheets for any creature. So that is in as a new perk “Insightful”. Also once I had that working I realized that I could give creatures perks, not just the player. Go-go emergent design, wouldn’t have thought of that in the beginning but it is obviously awesome to be able to have more than just stats for creatures, they can now have personality.

Speaking of creatures with personality, I have added a new creature the ‘Seraph’ a beefy melee angel that glows like the sun.  They are absolutely terrifying – they are bright enough that you can tell they are there from far away, and have enough staying power that blasting them with a shotgun as the casually walk up and tear into you can be quite a memorable experience.

Other features added in to ease the learning curve were a help menu to show the controls and a estimated change to hit/glance in the targeting UI. Having a single number to guide you through all the ranged modifiers is awesome. I found myself moving into better positioning much more often than I had before given how much easier it was to digest that information.

I also added in 2 new map types, a fortress type map with many hallways and rooms in one large connected complex, and a more traditional dungeon type with rooms sparsely connected with dead ends and the like. I was finding it harder to get back to the exit once I found it though, the new map types were much more constrained in their field of view. So, given the importance of the exit tile, I have made it always lit, even when remembered in fog of war, and not directly visible. This makes it much easier to get to the exit in a cleared map instead of the slog of re-exploring that it could sometimes be.

Welcome! I’ve been working in that fuzzy area, design, for most of the 3rd day. I’m getting to a point where instead of asking myself “what is missing that would make this a game?” I am asking “what features need more love to make this game better?”

This slideshow requires JavaScript.

The bulk of the technical work was finished early morning when I implemented a perk system. Basic ‘on perk gained’ hooks and ‘does this object have this perk’ checks covered most of what I needed. Then a little game flow control via exclusive and requisite perk lists per perk. Nothing terribly complicated, but I do with that Game Maker had better user event handling. My options were either to have the ‘on_perk_gained = script’ value and then explicitly check is ‘script_exists(on_perk_gained)’ then ‘with(object){script_execute(on_perk_gained)}’, but not only is that a bit verbose it also means I have to write all of my scripts outside of my object. My other options was user events. ‘User Event 0’ lets me put my script in the object, and if I don’t put a script its a safe no-op so no pre-check. That part is great, however its not terribly obvious what I mean when I call ‘with(perk){user_event(0)}’. I did manage to make it a bit cleaner by adding a constant ‘EVENT_PERK_ON_ADDED = 0’, but that doesn’t save me from doing something silly like ‘with(menu_item){user_event(EVENT_MENU_ITEM_CONFIRMED)}’ (my menu system has the same setup now). Well enough though, I spent most of the day creating perks.

General Perks:

• Regeneration (+hp per turn)
• HP Boost (+max hp)
• Fast Learner (+xp gain rate)
• Brawler(+melee damage)
• Marksman(+maximum range)
• Open Minded(+considered perks per level)

Firearm Perks (Exclusive):

• Rifle (+damage and max range )
• Sniper Rifle (+lots of damage and max range, but minimum range increases considerably and ‘too close’ accuracy penalties are tripled)

When playing around with perks I found that the progression was very slanted to direct combat perks because there was no progression just from leveling – so I also added a minor stat bump in all areas on every level – so taking utility perks early isn’t completely damning.

I also noticed while play testing some perks that I had very little feeling of stat progression, I knew as a developer that one shotting level 3 Demon Soldiers with a sniper rifle was awesome, but reading the console for damage numbers is not part of typical play flow. So, I added some basic floating text damage bubbles to help the player understand what was happening in combat.

Actually, understanding what the game is doing is my main goal today. Adding in a character sheet, adding some predictive combat estimates, help menu explaining controls. Those sorts of things. Make it really accessible.

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.

This slideshow requires JavaScript.

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!

Hello world! I’m taking a vacation and working on a 7 day rogue like game. Well, not strictly 7 days. I did do some pre-work getting a basic console-like engine going in Game Maker Studio after miserably failing at getting any console goodness to work on windows. Yesterday (Day 1), I started working after lunch, from my pre-work I had a player moving around a room with walls, line of sight field of view, colored lighting, and an object following the player around.

This slideshow requires JavaScript.

The first thing I worked on was level generation. I went with a simple method I’ve been calling “Carve and Paint”. Starting with a level full of un-carved blocks and carving out rectangular rooms, then carving out linear hallways between each new room and every pre-existing room. Then I paint in details such as lights and creatures. Super standard no flairs pseudo cave room thing generation. However it did uncover quite a large problem.

My debug room was only 10×10(100 blocks); the full level is around 60×40(2400 blocks). My lighting and visibility checks were causing multiple minutes per frame. So I had to spend quite a lot of time optimizing. My first thought was – eh, lets get this out of script and compile down to LLVM, but getting Game Maker’s YYC compiler working on Windows 10 isn’t well documented yet and I didn’t want to spend to much time on that route.

I looked for waste, and found plenty. I moved the light blending into the simulation update (IE only when the user interacts), that helped quite a bit, got the user turn update to multiple minutes, instead of every frame (small victories). Then I reduced the lighting visibility check from 17 ray-casts (all corners to all corners (16) + center to center), down to 5 (viewer center to target center and target all corners). This helped some too, but it was still more than 10 seconds per update. I then face-palmed when I looked at my basic AI – to tell if it could see the player I was updating the entire room’s visibility based on the creature, then checking if the player was visible. Instead of just checking, the 5 ray-casts between the player and the creature like a sane person. That got the player update down to about 2 seconds. Playable, but terrible. With the game in a pseudo-working state profiling came in to save the day.

Intuitively I expected the ray-casts to be eating most of my compute time – NOPE! Never trust your intuition when optimizing, you are not a computer. I found that my general cover solution was not efficient enough because I assumed I was checking visibility one at a time. Disabling non-vision blocking objects and enabling them once again for each objects visibility check. This was eating up 90% of my time. Only 2% was ray-casting. I duplicated my visibility script and took out all of the object filtering, moving it up to the calling function doing visibility for all objects in the scene. So by fixing up that terrible algorithmic issue, I eliminated 2399 of 2400 passes and everything ran great and I could start making game play.

First order of business was to get combat working. I created a Fighter component and slapped it on the player and all of the enemy creatures. Before, getting to far I added UI to show player health so I can see things working outside of the debugger. Then I created a basic “thing hits other thing” function and started messaging out to the debug console. Realizing that players usually see those sorts of messages I hooked up a basic logging console in the UI, messages now go to both places. Add in death and XP gain and I almost had a game. XP UI and leveling up restoring player health came in next. Everything was working great until I started balancing combat to be challenging instead of creature slaughter prime time. When the player died the game crashed spectacularly.

Technical design theme for the ages – never assume you will have anything available. Treating the Player object as a permanent singleton was great for rapid prototyping, but I had to go back and shore up a few dozen places that assumed the player was in the scene. After that it was time to explore my world and slay some monsters, but I kept getting lost in the ever shifting field of view.

Remember that hallway on the other side of the door your near? Easy right? Well, now expand that to 2400 tiles you may not be able to see. Navigation was terribly difficult. Fortunately tracking where you have seen before fog of war style is technically simple. In a few minutes I had a new ‘fow_memerable’ flag on objects and if you had seen them before they would stick around forever in a gray unlit state to act as your memory for you.

All in all, day 1 went extremely well – I got farther along than I had hoped for and I am very excited for day 2’s progress. First thing on the menu for day 2 is: Breakfast!