Death and Cascading Delete

Character death logic has been added, when a character’s health reaches zero the character is DELETED along with all of its associated records, such as its inventory and any active combat records. Having a character’s death be permanent is pretty vital to this type of survival, roguelike. It makes the risk vs reward choices that much more vital. Just don’t get too attached to your character and its stacked inventory of food and cards.

But not all is lost, for I have also added the Graveyard. This is where all characters go when they die and simply stores their name, final score and the user they belong to. Having these records allows for a couple of things. First, it allows for a leaderboard to be posted that displays the top scores of characters alive or dead. It also permits me to make a page that a player can visit to see a history of all their old characters, perhaps as a motivator to beat their personal best score, or maybe just a place to go and mourn your passed characters.

I’ve got some ideas for expanding the stored stats but for now, name and score is all I’m holding onto.

When implementing character death I realized I had many records that needed to be removed from many different tables. At first this seemed daunting, not only would I have to remove the character from its table, but I’d also have to remove every inventory item, any active combats the character was in and then every enemy card associated with that combat. That’s a lot of foreach loops removing a lot of records, one at a time.

Luckily, there is a better way and it’s called Cascading Delete which basically means – when I delete this thing Entity Framework will go ahead and delete everything else associated with it. Then it was just a matter of going back to my models and making sure they were associated properly to begin with. So now, all I do it remove the character in question and Entity Framework takes care of removing all the records associated with that character via a Foreign Key. It was nice to go a learn a new trick that makes things like that easier to handle.

But it’s not all death and deletion, there have also been major strides with the visual design of the game, and I’ve done a lot to make all of the interactions with Nano use ajax. Once you enter the game’s World view, that it, no need to do full page refreshing anymore.

The character death logic was the last “feature” I needed to tackle before the game can be played seamlessly. Next I just need to work on the visual presentation layer of things and add some more content. Once those two things are done, I hope to be ready for some very early playtesting.

Combat goes in the Combat Box

Long story short, I got the Combat screen to display within the World view via ajax. What does this mean? Means the game looks like this when in combat now…

Featuring background scene art by Koishii Kitty.
Featuring background scene art by Koishii Kitty.

This turned out to be easier than I expected when implementing, but took a while to plan out properly. The result is a smoother transition from Event to Combat. There are still a bunch of things I need to refactor now that this is how the combat screen will be displayed, but it’s a step in the right  direction.

I still need to change the card’s ‘Use’ button to use ajax and the players stats in the top left need to update after each combat round.

I also ajax’d the close button for the inventory screen, meaning now, going from the World screen to your Inventory, using an item and then closing the inventory screen to return to the world screen is all seamless. I’m going to start looking into fancy javascript animations for the opening and closing of screens. While the current transition requires no full page refresh, the switch is somewhat startling. I think all it needs is a slight fade as it transitions.

Inventory got all AJAX’d up

Over the weekend I enlisted the help of my old pal Zach Lysobey to give me some tips on adding Ajax functionality to Nano. Zach and I have been working together as a web design and development duo for years now as Rough Giraffed. He’s no stranger to javascript, AJAX and programming in general so he was able to hook me up with the basics real quick.

Ajax is a technology that does lots of stuff for websites/applications, but for Nano the primary benefit is avoiding full page refreshing. This is another step into making Nano feel less like a browser game and more like a standard video game. Avoiding the flicker of a full page refresh will hopefully make the player feel like they haven’t left the game world to enter an Inventory screen. Instead the Inventory screen opens right there, as an overlay to the standard World screen.

The screenshot above can’t show the Ajax functionality in action, that’ll have to wait for the video demo. But what you do see is how the current, basic Inventory screen looks. On the left is the character’s inventory with a list of Cards, and Items gathered from the world or winning events. You see a bunch of Kick cards because, while testing, I had my ol’ Test Dummy only dropping Kick.

On the right is the character’s Deck list. These are cards that the player can use while in combat. Currently, there are only about 15 cards in the deck, but later there will be a minimum deck size that will, most likely, be greater than 15.But, I’ll get more into Deck editing, and Items in another post.

For now, just know that there will be a lot of this kind of effort put into making this browser game not feel like a traditional frame-based browser game.