Events

In Nano, Events are the primary way the player interacts with the game world. Events are also the most direct way the player learns about the environment they are taking part in, meaning Events play double duty by providing game play and story elements. While the story is something that will develop overtime, the functionality of Events is something that the game needs right away. Events are also the feature that I wrestled with the most when trying to come up with a solid development design.

It was clear what Events had to be, they were to display some story text to the player, a few buttons with text on them representing the player’s available choices, and upon selecting a choice a result is shown that also has story text as well as displaying any rewards the player is given. Think of the event system in games like FTL. This type of system is generally referred to as a dialog tree, decision tree, or most specifically a simple directed graph. There are many plugins for Unity that provide varying levels of decision tree functionality, but I wanted to take a stab at rolling my own first.

So far a very simple Event model is in place along with Choices and Results. When a player enters a new location an Event is chosen from the list of possible Events which is then displayed on screen. To manage the Event’s display is the Event UI Controller class which is attached to prefab in Unity. This Event prefab uses Unity’s new UI features to display text and buttons. This is my first attempt at working with this new UI system, before this all objects displaying text used Text Mesh components which I find to be clunky and lacking a lot of features that are needed for displaying even a modest amount of text.

The early Event UI screen.
The early Event UI screen.

There is still a lot to be done to get Events fully functional. The player still needs to be able to select one of the choices and be presented with the result. Events will also be the primary way that combat is triggered. Some choices should only be available to the player if certain conditions are met, like having a particular item equipped. There is also the daunting task of creating a large amount of Events all with multiple choices which in turn have a variety of rewards.

C-C-C-COMBO SYSTEM! Part 2

Last time we talked about how players will build Combo Points by playing cards in the right order. This time we’ll learn how that glorious combo can be ripped down in an instant if you’re not paying attention!

Interrupts

Not going with the flow

You can’t just rack up Combo Points carefree. Combos can be interrupted meaning you lose all of the combo points you’ve built up and perhaps even worse! Sometimes you may be able to play a card that is the color needed for you followup Combo Color, as is the case when you don’t have a card of the necessary color in your hand. In this situation you will still want to play a card in order to continue damaging your enemy, but when a card is played that is not the color of the required Combo Color your combo will be interrupted. Having your combo interrupted means setting your Combo Points back to zero and missing out on any combo bonus effects you had been building up! So try to manage your deck and cards in hand to maximize your combos.

Combo Breaker!

Your enemy isn’t going to sit there and let you wail on them all day! Enemies attack the player every few seconds, depending on the enemy. When an enemy attacks it will interrupt any combo you’re trying to put together. In addition to having your combo interrupted you will also be effected by the enemy’s attack typically in the form of being dealt damage. Ideally, the player will want to conclude their combos with a Finisher before an enemy’s attack timer fills resulting in the best combo bonuses while mitigating the enemy’s damage. One last thing, just as the player is given bonus for completing combos, the enemy will get bonuses for breaking the player’s combos!

Finish that combo quick! Dummy strikes back soon!
Finish that combo quick! Dummy strikes back soon!

So there is an overview of the current combo system used during combat. Things are still being tested to see what works and what needs to be changed. The need for the right card colors will hopefully play into the deck building aspect of the game, urging players to be mindful of the cards they put in their deck and to hunt down the perfect cards to fit their strategy.

C-C-C-COMBO SYSTEM! Part 1

Ok, now this is starting to look and feel more like a game. The combo system has been added to the game in a basic, minimum viable product sort of way. Just the minimal amount necessary to demonstrate the idea has been implemented. The code is still a bit of a mess and some refactoring is certainly in order but there are too many ideas to get out. Some other UX improvements have also been added.

Dragon Drop

The ability for a user to drag and drop (I prefer to call this Dragon Drop) cards during combat has been added, making for a much more fluid combat experience. Cards are now flicked at the enemy portrait in order to use the card. This flicking motion lends itself towards faster card plays which feeds into the combo system.

Combos

The idea is relatively simple, all cards are given a color and most cards have a Followup Combo Color. When a card is played and then the next card played is the color of the previous card’s Followup Combo Color the player’s Combo Points are increased. The player can continue to rack up combo points until the combo ends. A combo ends either through the use of a Finisher or by being interrupted. A combo can be interrupted either by the player not following up a card with a card that is not the Followup Combo Color or by being attacked by the enemy.

Finishers

Finishers are almost the same as Followup Combo Colors. Where most cards have a Followup Combo Color, many of them also have a Finisher Color. When a card with a Finisher Color is played and then followed by a card that is the color of that Finisher Color the combo is completed granting the player bonus damage and/or effects. The player’s Combo Points are then reset and a new combo can begin.

sweetCardArt
Early card examples showing card color, name, Combo Color and Finisher Color.

 

Next time we’ll cover how combos can be interrupted and all the terrible things that take place when that happens.

Half Combat

Half of the super basic combat system works! For testing purposes, whenever a player clicks the Explore button, combat is initiated with my good ol’ pal Test Dummy. Yep, that bag of straw and anger is back to take another kicking. preAlpha_Combat01

Once in combat the player’s starting hand get’s drawn. When a card is used it’s cardPower is deducted from the Test Dummy’s health. This continues until the Test Dummy has no health left to lose, at which point the combat window is closed and the player is given a random reward.

Like the patient dummy he is, Test Dummy doesn’t fight back yet. That’s next on the agenda, I can tell he’s itching to strike back… or maybe the itching is from the straw… I’m so corny.

How to handle the Deck, Hand, and Discard

I spent a long time thinking about the best way to handle this aspect of the combat system. The inventory system already has the player’s deck as a Dictionary with a Card as the key and the Quantity as the value for each row and at first I thought I could just use this Dictionary as the deck in combat as well. First I tried to give the Card class a inHand and inDiscard boolean property. The idea was to just toggle these boolean values as the card moved from deck to hand to discard and back to deck again. This quickly became apparent that it wouldn’t work easily and that it would be best if each card had its own row meaning having 2 Punch cards would result in having 2 rows in the Deck array.

So I switched to a List, no big deal. At the start of combat the Combat Manager loops through the deck dictionary and turns it into a deck list. Now I could just look through the list for cards that have inHand and inDiscard booleans set to false and I can draw one of them!

Wait, no, that kinda sucks too! Doing that would make randomly selecting a card difficult as i’d always have to check to see if the card selected was inHand or inDiscard, if it was in either of those places, select another random card and keep doing that until an available card was found. Laaaame!

So the inHand and inDiscard boolean idea was scraped too and two new Lists were added, the Hand List and the Discard List. Now, a random card could be selected and removed from the deck list and added to the hand list. No having to make sure a card in the deck list was currently in the player’s hand. If a card was in the deck and was available to be drawn!

So there I was, spending all this time thinking up the right way to do it, the when I started implementing what I thought was the right, it turned out to be very wrong and the right thing fell right into my lap. I’m a little embarrassed I didn’t think of it sooner!

Nano Inventory and Deck UI Ready

Slapped away at the keyboard today and got the inventory and deck editing features put in, it looks pretty nice actually. I hope I can get someone to do a code review of it sometime, as I’m sure there are some more efficient ways to achieve what I’ve made. No matter, it works and that’s good enough for me.

An inventory system isn’t terribly exciting but now that it’s out of the way the fun part can begin, combat! Well, before there can be combat, there has to be something to combat against, so the next things to implement are Enemies.

To start, only a few simple, punching bag type enemies will be added so that the work on the player’s side of combat can begin. The player will start combat by shuffling their deck, then drawing a hand of cards from it. After that combat is turn based and after the player chooses a card to play, the enemy will perform its attack, then back to the player. Attacking back and forth will continue until someone dies, then a reward will be given to the player… as long as the player isn’t the one who died.

That’s the super high level overview of how combat will work. For me, the implementation of the player’s side of combat will probably go something like this:

  1. Add Enemies
  2. Create combat UI
  3. Add ability to draw cards from player’s deck at random and add to player’s hand
  4. Display cards in hand to player in combat UI
  5. Add ability for player to select a card to play, removing the card from their hand and drawing a new card

You’ll notice that having the cards do anything is not on that TODO list. That’ll come after all those basic things are in place, this is still just UI and basic functionality we’re talking about here.

 

Nano with Unity: Fresh Start

I’ve started to remake Nano using Unity. Nano will no longer be a browser game, instead I plan to release it for PC, tablet and phones. It’s a bit odd for me to say “release it” as if I’ll ever finish it. It would be really cool if I did and that is the plan but you surely know how these kinds of personal projects go.

So far I’ve got some of the basic UI in place, enough for some testing and experimenting. So far this UI is limited to displaying the player’s health points, a few buttons with placeholder actions and an early take on the inventory system.

Next up will be improving the inventory system and adding the Deck feature. Cards in the player’s inventory can be added to their deck, which is used in Nano’s combat system. Though, before combat can take place Enemies will be need to be added.

So that’s the game plan. I’m excited to be working on this project again, here’s to the hope that it’ll go further and be better than the browser version. It wouldn’t take much to be better than that ol’ thing.

Lil Critters – Class structure and the Nervous System

I’ve started working on the Lil Critters “Evolution Sim” project again. First thing to do was some refactoring, so I made many more classes and split up the methods. The classes and structure of the project is kind of interesting, since I am loosely modeling it after how the nervous system in living creatures tend to work. I’m no expert in biology, neurology or anything like that so I’m taking a more broad and general approach to the nervous system.

A critter’s “nervous system” is made up of three main classes which are Stimulus, Brain, Response. As you can probably guess, Stimulus is in charge of receiving input from the world outside of the critter and relaying those inputs to the Brain. The Brain chooses a response based on the input and sends this choice to Response. Lastly, Response allows the critter to perform some action as dictated by the Brain. There are other classes each critter has as well such as Raycast (to draw sight line) and Metabolism (to manage energy consumption). There will also be plenty more added as the project grows. The way I’ve been thinking of these classes in more specific terms is:
BasicCritterClasses
Raycast: Photons that hit the eye.

Stimulus: The eye that forms information from the photons that hit it and the neurons that transport that information to the brain.

Brain: Takes care of brain stuff… makes choices to call for particular responses based on input.

Response: The muscle system, applying forces to the critter when instructed to by the brain.

Metabolism: The chemical reactions and burning of energy in order to power the muscles and also just to maintain life.

It’s almost soothing to organize the series of inputs, analysis and outputs like this. This project often makes me think about real life a bit differently. While we all get the general idea that out bodies and minds are set up in this way, we typically don’t give this idea any weight or importance. I find it interesting to be building these little critters with this structure as a guide, which developed over billions of years of evolution.

12-1 Mage Arena Deck

I’ve gotten 12 wins in Hearthstone’s Arena a number of times, but usually ending at 12-2. This time I managed 12 wins and only 1 lose. The deck itself is pretty powerful with 3 Fireballs, 2 Flamestrikes, a Frostbolt and Onyxia to finish the job but many other cards did some serious work.

Here’s the deck in its entirety:

2 Flamestrikes can get you 5 wins easy, throw in 3 Fireballs and 7 wins is no problem.
2 Flamestrikes can get you 5 wins easy, throw in 3 Fireballs and 7 wins is no problem.

Some other key players were the Mana Wraith and Nerub’ar Weblord. Now these aren’t great cards but they were the best of a few shit choices. However they ended up allowing me to control the board early game. Coin into Weblord followed by turn 2 Mana Wraith and now all the opponent’s plans are on hold. These cards just screw up the enemy’s flow, which allowed me to get off a turn 3 Arcane Intellect for both card and board advantage.

One key thing to do when playing as a mage is to try and act as if you don’t have Flamestrike in your hand, even though we all know that every mage has a Flamestrike in their hand on turn 7. When you ping a Taz’Dingo down to 4 on turn 6 your opponent knows you’re lining up a Flamestrike and will play around it. Also, try to maximize the value of the Flamestrike by waiting until the opponent’s hand is empty or near so. Also, look for ways to deal with the board without using Flamestrike even if you have it. If turn 7 comes around and you don’t use Flamestrike, many people will assume you don’t have a Flamestrike and will feel better about filling up the board with his minions, then is the time to strike… FLAMESTRIKE.

Nano is now Open Source

I made Nano open source and it’s all available on GitHub here. I haven’t been able to find the time and energy needed to push further development, plus I think it needs such a massive refactoring that it might as well be rewritten from scratch. Regardless, I think if anyone wanted to take what I have made and expand upon it in terms of just content, art and UI, then you could have a pretty solid and fun game.

I still like the game play ideas of Nano, and I learned so much about programming from making it that it pretty much landed me a developer job. While I’m not working on it currently I haven’t stopped having ideas for it. All of them revolve around remaking it as an android game, perhaps as a Unity 2d project but still, finding the time and motivation will be tough in the next few months. To come home from a day at work of coding and spend the evening doing more coding might be a bit much for now, so any personal coding projects are on the back burner for now.

Anyway, it would be really cool if someone wanted to use this base for their own browser game. So if you do use it, let me know I don’t know about how to make something officially open source licensed or whatever but if you wanna play with the source and are concerned about that stuff just let me know how to set it up.

This was a really cool project and I’m sure I’ll revisit it in some form some day.

Playing with Unity and My Critters

I’ve been away from the Nano project for a few months now and I’ve instead been spending my programming time learning Unity. It’s actually pretty easy to use, and after watching a few of the tutorials on Unity’s site I was good to go and started off on my new learning project, which I’ve been calling My Critters. This is an awful name and isn’t a name at all really, it’s just what I say when I tell my girlfriend what I spent my day doing.

Her: “Have you been playing video games all day?”

Me: “No! There were a few hours that I worked on my critters… AND I showered!”

Unity?

Unity is a 3D engine typically used for making video games, incase anyone is reading this (no one is) and isn’t familiar with it. You can use Javascript and C# to write scripts for how the objects in your game should function.

Evolution Simulator Project

The Idea

In my case, I’m trying to make something I’ve been calling an evolution simulator. The idea is that when you start the simulation a few critters (aka spheres) and some food (cubes) are randomly dropped into a small flat world. The critters have the ability to detect the food via sight (raycasts) and then can move to the food (using physics and impulses) and eat the food. Now, every action the critters do burns energy, some actions burn more than others (moving forward burns more energy than turning) and simply existing slowly consumes energy, and when you run out of energy you die. In the end, critters try to get to food to stay alive, they will mate to make more critters and spread their genes.

Current State

This isn’t how it all works right now, currently I only have 1 critter who doesn’t burn energy at all and just poots his way around the world eating everything he sees, sweet life. But all that other stuff is coming and I don’t think it’ll be too difficult to get those basics in place. (In before the post where I talk about that stuff turning out to be really difficult.)

The Hard Part

The hard part comes when the critters aren’t told to do any of those things. The goal is to not have the instruction of move to food, eat food as an explicit instruction of the critters, instead the critters genes should determine what the critter does when it detects food, when it comes in contact with it, when it detects another critter, how it explores its environment, etc. This is when I’ll be getting into neural networks and stuff like that.

Polyworld

This whole idea is based off a project I saw years ago called Polyworld. The guy is a terrible presenter but it’s really inspiring the way the creatures in Polyworld develop their own survival strategies. My goal is to create a similar effect in a 3D space, the bigger goal is to then use this type of creature generation in a game of some sort.

Up Next

As of now, Nano’s development is on hold. I think Nano makes a decent portfolio piece and I’ve still got ideas for it that I want to implement, so the project isn’t canned, just on the back burner.

I’d really like to get some 3D models in the simulator. It’s really early, but I think having some models to look at instead of just geometric shapes would be more interesting to look at. Since I don’t know much about making 3D models, this part will likely require outside help. For me, the next part is to add more critters to the world, allow for mating, and add energy consumption.

Screen shots in next post!