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.

Implementing Events Part 1 – Being Stateless

I’ve started implementing the Events feature into Nano. So far my posts haven’t been too technical or in depth, so this one might be a bit heavy for some. First, allow me to describe the overarching idea behind Events in Nano.

The Idea

As a player navigates the world they occasionally encounter an Event upon entering a new location. An Event is basically a description of something that is happening and a list of choices about how to react being made available to the player. Once the player has made a choice they are given some type of result, such as stat alterations, finding treasure, or getting into combat with an enemy.

Example Event

A player enters a new location called ‘The Open Plain’. Upon entering this location they are shown an Event screen, for the event ‘A Pool of Water’. This event has a description; “You see a pool of water. It looks clean enough to drink.” and a couple of choices:
Choice 1: “Drink the water.”
Choice 2: “Ignore the pool of water, bugs have probably pooped in it.”

The player selects Choice 1, “Drink the water.” (Ignoring the possibility of bug poop!). This choice results in the character’s Thirst being reduced by 100. Had the player ignored the water, they would not have received that reward. A second screen is displayed given both a description and a breakdown of the results.

“You drink the bug poop free water. Ahh, refreshing!”
Thirst: -100

How to Organize the Data?

So now that we know the overall idea of what we’re trying to do. How do we execute that in code? It’s never as straightforward as you think and even when you’re prepared for it to become complex, it’ll go and get even more complex than that. This is because at this stage of development I’m really building a system, not just a ‘if this, then that’ scenario.

How does the database look?

First I had to figure out how to organize the information in the database. Will the events, choices and rewards all be in one table or would it be better to have a separate table for each event element?

After a lot of thought, I decided on having separate tables for Events, Event Choices and Choice Rewards. The reason is that each of these has a One-to-Many relationship with the next. For example an Event has many Choices and each Choice can have many Rewards. This would suggest that using a separate table for each piece would be the best way to manage them.

Being Stateless

One major pain that I’m always dealing with in this project is that as a web game using MVC4 and standard postbacks (ie. I’m not using Flash) is that this game is Stateless. Most games can save information about the player’s current location, stat values, and what screen their looking at in your computer’s memory, but not Nano. Nano needs to save all these variables in a database and access that database after every player choice.

Being Stateless Allows Cheating

So given the Stateless limitation, how does the player’s choice get sent back to the server? Another problem with being Stateless is that user input cannot be trusted, they could send any value they want back to the server and the server just accepts that value, never thinking that the user might be a big fat cheater! For example, if a player is in combat and clicks the Use Kick button, the link they click actually forms a URL that ends in /UseCard#CardID=3 which calls the UseCard method with CardID=3 (3 being the ID # for the Kick card).

So there you go, that’s how you can try to exploit Nano. During a combat just change the url to have the CardID equal a number of an amazing card like ‘Sword of a Thousand Truths Stab’ and you can use that card even if it’s not in your hand or even in your deck!

Just kidding, you can’t do any of that because I had to take special measures to stop that form of abuse. Again, because the game is stateless, when the user sends a request to use a card with a particular ID I first check to see if that card is in the user’s hand. If not the user will get a message saying it’s an invalid card and then it will taunt them for trying to cheat. But the point is, this is something many games don’t have to be concerned about since they can store information in memory.

Record the Character’s Current Event

Something that is nice about working in this Stateless environment is that it allows the player to leave the game at any moment and when they return they will be right back where the left off. Whether that is standing in the middle of a forest, at a crucial choice for an event, or right in the middle of combat.

But this also means that the game must record everything to allow for this seamless return. For Events, I decided to add a property to my Character records called ActiveEvent this field stores the ID# of the event that the character is currently involved in. Upon page load the game says “Is the character in an event?” If no, then the ActiveEvent field is null and the game displays the location the character is in. If yes, then the game looks up which event it should display based on this ActiveEvent field.

Sum it up

So that’s how working in a stateless environment for a game adds a layer of complexity to the design of the game. I have to think about everything in steps and each step has to end in a single output of information for the player to react to. In the next post I’ll get into making events more interesting by limiting their frequency and availability.

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.

Codename: Nano

Here is a brief description of the game that I’m developing. Pretty much nothing is set in stone but these are some of the ideas I’m working on and/or implemented already.

Nano is the temporary name of my browser-based, multiplayer  survival game. Nano puts the player in control of a character who explores the world, fighting enemies, getting loot and just trying to survive in the distant future.

Setting

“The distant future you say? Well I’m sure survival is easy in the future! It’s already so easy to live now!” – Some Nerd

“No.” – Me to some nerd

Nano’s set on Earth in the distant future centuries after an apocalyptic event that left very few humans alive. Those that did survive have had to start over, living in small nomadic tribes, living off the land, no longer having access to technology.

Centuries have passed since the apocalyptic event took place and nature has done its thing and reclaimed the land and sea. The Earth is starting to look a lot like it had in the time before humanity ever came around and mucked everything up.

So you’ll be able to piece together more about the world as you roam around. Neat.

Features

  • The world uses procedural generation to build the world as players explore new locations.
  • Survival! Starvation, Dehydration, Disease! All fun ways to die! 
  • Card based combat! As you explore the world you’ll find cards and edit your deck, effectively ‘customizing’ your character. No classes, no levels, that crap is played out.
  • ScoreBoard: Explore, win fights and find stuff to gain points and get ranked against other players.
  • Death is fun! Permanent death! (As see in the hit classic, Real Life!)
  • Multiplayer! I don’t know how exactly yet, but it’s possible… and characters all exist in the same persistent world so it’s just a matter of adding ways for them to interact. Shouldn’t be hard to do, right?
  • Arts! Nice world and character art to look at, so you’ll have something nice to look at while you die of dysentery.
  • And probably more!

Tech Stuff

I’m using C#, asp.net MVC4, and SQL server.

Why these things?

I dunno really. I don’t know enough about all the different options out there to make an informed decision. I just saw what MVC4 could do and was like “Hey! I could make a game with that, I think!” and here we are.

So… what is it, again?

I’m taking inspiration from a few other games:

  • FTL
  • Kingdom of Loathing
  • Magic: The Gathering
  • DayZ
  • Your standard RPGs

Combining aspects of those games and others to make some concoction that I haven’t seen before, but probably already kinda exists because that’s how the world is.

So, those are the basics. I’ve got a long way to go, so let’s see what happens.