Word Hunter

Word Hunter

I’m pleased to announce that Word Hunter has been released to iOS, Android and Windows Phone. 🙂

It’s written 100% in web technologies and packaged via Apache Cordova.

Go take a look, I hope you have some fun with it:

The game is made by @danielsalvagni, Gabriel Biz and me (@evohunz).

Tip of the day. We did it while reading Getting Real and Rework. Incredibly how these books affected how we dealt with the development of this project. Changed my mind for sure.

By the way, my personal highscore is 935 points.

Using Facebook’s Flux architectural style for game development in Unity 3D

I decided to work again in an old game project. The game is named “Shotem” and the mechanic is quite simple: coins start falling from the sky and you need to “shot them” (got it?). Tap on a coin to shoot it, you gain score if you hit and you lose score if you miss the shot or if a coin falls off the screen (in case you didn’t tap it). You have seven bullets to use, each shot (finger tap) consumes a bullet and you need to shake the mobile device to reload your bullets.

The game is still a work in progress, but I added the following video in order to show that it actually works in real life:

I’ll write the history of the development process of this game. It started in a very naive form, then I converted it to Flux style and left it alone for three months. Now I’m coming back to it and had a pleasant surprise to read the code after forgetting about it. I think Flux style made it easy to continue the project were I left it. This post is 100% opinion based. Please, take a seat.

The first version I coded was very straightforward. Each coin was a GameObject with rendering and game behavior logic. All game state were inside a Singleton and two other objects were responsible for creating coins and handling user taps. Not organized at all.

I was interested in how to code the “reload by shaking” feature. As soon as I got it working, I lost my interest in the game mechanic itself. This happened quite fast actually, Unity 3D has a very nice class to use for dealing with the mobile device gyroscope: Input.gyro.

At the same time, I got in touch with Facebook’s Flux architectural style. I tried it in some web projects and had a nice feeling about it. It seemed easier to write, maintain and understand code written in Flux style than the code written in MVC fashion. So, I decided to rewrite the code of Shotem in Flux style.

At first, it didn’t seem to fit into Unity’s way of doing things. But I worked it out and coded it anyway. It worked fine, then I left the code alone.

Three months later I’m coming back to this project and I didn’t remember that I tested Flux style in it. At first I thought: “oh no, I’ll need to delete this project and start it over, why did I do it?” Then I did read the code and look at the project structure: I was amazed at how easy it was to get things back on track, I were able to get productive again in less than five minutes! What a pleasant surprise!

Now, I feel that I should share this with the rest of the world. I appreciate feedback, so if you feel that using Flux style in game development is madness or if you feel like giving it a try too, leave a comment.

From now on, I’ll use some terms from Flux, e.g. Store, Dispatcher, Action. I won’t explain what are their meanings, so feel free to take a little detour and read the official Facebook’s Flux website to get a summary of it.

I created a Dispatcher class to register the Stores, dispatch actions, track dependencies between Stores and ensure that the Actions do not cascade. The Dispatcher, in it’s full glory, is here:

using System;
using System.Collections.Generic;

using Shotem.Actions;

namespace Shotem.Flux {

    public class Dispatcher {
     
        private Dictionary<int, Store> stores;
        private HashSet<int> calledStores;
        private ShotemAction handlingAction;
        private int lastKey;
        private bool inDispatch;

        public Dispatcher() {
            stores = new Dictionary<int, Store>();
            calledStores = new HashSet<int>();
            handlingAction = null;
            lastKey = 0;
            inDispatch = false;
        }

        public int Register(Store store) {
            int key = lastKey + 1;
            stores.Add(key, store);
            lastKey = key;
            return key;
        }

        public void Dispatch(ShotemAction action) {
            if (inDispatch) {
                throw new Exception("double dispatch");
            }

            inDispatch = true;

            calledStores.Clear();
            handlingAction = action;
            foreach (int k in stores.Keys) {
                if (calledStores.Contains(k)) {
                    continue;
                }
                calledStores.Add(k);
                stores[k].Handle(action);
            }

            inDispatch = false;
        }

        public void WaitFor(int registrationKey) {
            if (!inDispatch) {
                throw new Exception("wait out of dispatch");
            }

            if (calledStores.Contains(registrationKey)) {
                return;
            }
            calledStores.Add(registrationKey);
            stores[registrationKey].Handle(handlingAction);
        }

    }

}

The core game mechanic is encoded in three Stores: CoinStore, handling all coins in the game; GunStore, handling player’s ammunition; ScoreStore, tracking user score.

Player input may dispatch two Actions in the game: ShootAction and ReloadGunAction. To handle the physics of the game (falling coins), one Action is sent every FixedUpdate: PhysicsUpdateAction.

The Stores handle each action according to simple rules:

PhysicsUpdateAction is handled by CoinStore by spawning new coins, moving the coins in the screen and removing coins that are off the screen. ScoreStore waits for the CoinStore to finish and then updates the score by decrementing the amount of coins that were removed from CoinStore, because they have fallen off the screen. GunStore ignores this action.

ShootAction is handled by GunStore by decrementing player’s ammunition. CoinStore waits for the GunStore and ignores the action if no ammunition was used, otherwise it checks for overlapping coins in the shot area and removes them. ScoreStore waits for GunStore and CoinStore then increases the score by each coin removed or decreases the score in case an ammunition was used and no coin was removed.

ReloadGunAction is handled by GunStore to reset the player’s ammunition to seven. CoinStore and ScoreStore ignores this action.

That’s the whole game logic. Each Store is observable, the Views register themselves to receive update notifications. When the Store handles an Action that changes its state, it triggers a notification. I’ve created an abstract class Store to handle this common behavior:

using Shotem.Actions;

namespace Shotem.Flux {

    public abstract class Store {

        public delegate void StoreObserver();

        public event StoreObserver Observers;

        protected void Notify() {
            if (Observers != null) {
                Observers();
            }
        }

        public abstract void Handle(ShotemAction action);

    }

}

The listing below is the code of ScoreStore, the other Stores follow the same style:

using Shotem.Flux;
using Shotem.Actions;

namespace Shotem.Stores {

    public class ScoreStore : Store {

        private Dispatcher dispatcher;
        private CoinStore coinStore;
        private GunStore gunStore;
        private int lastKnownCoinsCount;
        private int lastKnownCartridgesLeft;

        public ScoreStore(CoinStore coinStore, GunStore gunStore) {
            Score = 0;
            this.coinStore = coinStore;
            this.gunStore = gunStore;
            lastKnownCoinsCount = coinStore.Coins.Count;
            lastKnownCartridgesLeft = gunStore.CartridgesLeft;
        }

        public void RegisterAt(Dispatcher dispatcher) {
            this.dispatcher = dispatcher;
            dispatcher.Register(this);
        }

        public int Score { 
            get; 
            private set; 
        }

        public override void Handle(ShotemAction action) {
            dispatcher.WaitFor(coinStore.DispatcherIndex);
            dispatcher.WaitFor(gunStore.DispatcherIndex);
            int coinsDelta = lastKnownCoinsCount - coinStore.Coins.Count;
            int cartridgesDelta = lastKnownCartridgesLeft - gunStore.CartridgesLeft;
            lastKnownCoinsCount = coinStore.Coins.Count;
            lastKnownCartridgesLeft = gunStore.CartridgesLeft;

            switch (action.Type) {
                case ActionType.SHOOT:
                    // Add points for each coin that is destroyed with a shoot
                    // Remove a point if used a cartridge and did not hit a coin
                    if (coinsDelta > 0) {
                        Score += coinsDelta;
                    } else if (coinsDelta == 0 && cartridgesDelta > 0) {
                        Score -= 1;
                    }
                    break;

                case ActionType.PHYSICS_UPDATE:
                    // Remove points for each coin that is destroyed with a physics update
                    if (coinsDelta > 0) {
                        Score -= coinsDelta;
                    }
                    break;

                default:
                    return;
            }

            Notify();
        }

    }

}

Setup code is done in a Singleton GameObject’s Awake method, I called it StoreHub because I use this to get the reference to the Stores from other Views:

using UnityEngine;

using Shotem.Flux;
using Shotem.Stores;
using Shotem.Actions;

namespace Shotem.Views {

    public class StoreHub : MonoBehaviour {

        void Awake() {
            Dispatcher = new Dispatcher();

            GunStore = new GunStore();
            GunStore.RegisterAt(Dispatcher);

            CoinStore = new CoinStore(GunStore);
            CoinStore.RegisterAt(Dispatcher);

            ScoreStore = new ScoreStore(CoinStore, GunStore);
            ScoreStore.RegisterAt(Dispatcher);

            ActionGenerator = new ShotemActionGenerator(Dispatcher, CoinStore, GunStore, ScoreStore);
        }

        public Dispatcher Dispatcher { 
            get; 
            private set; 
        }
        
        public CoinStore CoinStore { 
            get; 
            private set; 
        }
        
        public ScoreStore ScoreStore { 
            get; 
            private set; 
        }
        
        public GunStore GunStore { 
            get; 
            private set; 
        }
        
        public ShotemActionGenerator ActionGenerator { 
            get; 
            private set; 
        }

    }

}

ShotemActionGenerator is a helper class to create Actions and send them to Dispatcher, nothing fancy.

The View classes are also simple, for example, the game may play three different sound effects when the GunStore is updated: when a bullet is shot, when user tries to shot without ammunition left and when the gun is reloaded:

using UnityEngine;

using System.Collections;

using Shotem.Flux;
using Shotem.Stores;

namespace Shotem.Views {

    public class GunSoundsView : MonoBehaviour {

        public AudioClip ShootClip;
        public AudioClip ReloadClip;
        public AudioClip EmptyGunClip;
        private GunStore gunStore;
        private int lastKnownCartridgesLeft;
        private AudioSource audioSource;

        void Start() {
            audioSource = GetComponent<AudioSource>();
            gunStore = FindObjectOfType<StoreHub>().GunStore;
            lastKnownCartridgesLeft = gunStore.CartridgesLeft;
            gunStore.Observers += OnGunStoreUpdate;
        }

        private void OnGunStoreUpdate() {
            int cartridgesLeft = gunStore.CartridgesLeft;
            if (cartridgesLeft == lastKnownCartridgesLeft && cartridgesLeft == 0) {
                audioSource.PlayOneShot(EmptyGunClip);
            } else if (cartridgesLeft < lastKnownCartridgesLeft) {
                audioSource.PlayOneShot(ShootClip);
            } else {
                audioSource.PlayOneShot(ReloadClip);
            }
            lastKnownCartridgesLeft = cartridgesLeft;
        }

    }

}

Another view shows the quantity of ammunition remaining, which are just children GameObjects with Renderers that I enable or disable based on the GunStore state:

using UnityEngine;

using Shotem.Flux;
using Shotem.Stores;

namespace Shotem.Views {

    public class CartridgesLeftView : MonoBehaviour {

        private GunStore gunStore;
        private Renderer[] bullets;

        void Start() {
            bullets = GetComponentsInChildren<Renderer>();
            gunStore = FindObjectOfType<StoreHub>().GunStore;
            gunStore.Observers += OnGunStoreUpdate;
            OnGunStoreUpdate();
        }

        private void OnGunStoreUpdate() {
            int cartridgesLeft = gunStore.CartridgesLeft;
            for (int i = 0; i < cartridgesLeft; ++i) {
            	bullets[i].enabled = true;
            }
            for (int i = cartridgesLeft; i < bullets.Length; ++i) {
            	bullets[i].enabled = false;
            }
        }

    }

}

There is a View to show the score, one to show a tip to remind the player to reload the gun when it’s empty, another to handle the renderers of each coin visible in the screen, etc. The entire game is made in the same solid base, or may I say “solid flux“. Data always flows in a single direction without cascading, there is always an Action that enters the system and triggers something, nothing happens if no Action is dispatched.

I don’t know if this design can scale to a big game project, as the style as it is now depends on it running in a single core. But, none of my games are that intense, so I will try to finish this game with Flux. I guess that using Flux will also make it easier to create automated tests of the game mechanic, as it is self-contained. Maybe I’ll post some follow up thoughts on it.

Below is an overview image of the current flux of the game. I decided to call “Inception” the layer that generates the Actions, Flux do not give it a name.

Thanks for your time,

Peg Solitaire

I’m proud to announce my new game: Peg Solitaire.

Peg solitaire is a classic board puzzle game for one player involving movement of pegs on a board with holes.

The objective is, making valid moves, to empty the entire board except for a solitary peg. A valid move is to jump a peg orthogonally over an adjacent peg into a hole two positions away and then to remove the jumped peg. Thus valid moves in each of the four orthogonal directions are:

  • Jump to right;
  • Jump to left;
  • Jump up;
  • Jump down.

The first challenge is to solve the puzzle, and then you can challenge yourself and try to solve it with the minimum number of movements. Each jump is considered a move, multiple jumps with the same peg are considered a single move, so you can keep jumping with the same peg and still count it as a single movement. The game displays the count of how many movements you have made at the top of the screen.

Features:

  • Multiple board types to select;
  • Five different board types: English (Standard), European (French), Wiegleb, Asymmetrical (Bell) and Diamond;
  • Display game move count;
  • Quick replay same board;
  • Give up current game;
  • Restart current game;
  • Shows system status bar, so you can keep track of other things while playing, for example current time

The game is entirely free and displays ads, there is no in-app purchase options.

It’s made of web technologies (HTML, JavaScript, CSS) and deployed as a native application via Apache Cordova. Translated to six languages. Really exciting!

I tried to get the look and feel of each platform individually, using a flat design for iOS, a Material design for Android and a dark theme for Windows Phone. Take a look, I hope it’s pretty obvious which screenshot belongs to which platform:

There are still updates to come. iOS has one in the queue for review process and I’m delivering another one for Windows Phone this week.

Take a look at the game, download, play it and leave a rating or feedback:

Hope to see you soon!

Unity3D, Bejeweled and Domain-driven design

I’m working in a new game like Bejeweled. I’m happy with the freedom of code organization that Unity3D engine allows. During my first contacts with it, I thought that almost everything would be oriented to MonoBehaviour class, but this showed to be false. This class is necessary just as a glue point between any C# code and the objects of the engine. I’ll report how I’ve started coding this game and the changes I made so far, you can watch the following video to see the current state of the game:

I started creating a GameObject for every entity that I identified in the game mechanics:

  1. Board
  2. Piece

The board contains every pieces and manages them:

public class Board : MonoBehaviour {
  private GameObject[,] pieces;
  void Awake() {
    pieces = /* Initialize pieces */;
  }
}

The piece type is defined by a MonoBehaviour that exposes an enumeration:

public class Piece : MonoBehaviour {
  public PieceType Type;
}
public enum PieceType {
  Circle,
  Square,
  Star,
  Triangle,
  Hexagon,
  Polygon
}

After the definition of the entities participating in the game, I started to code game’s logic inside these classes. It worked for a while, but some problems appeared. The same classes had lots of different responsibilities (i.e. game’s rules, animations, handling input) and this made it hard to code some stuff, because I needed to maintain a mind map of all concerns to avoid breaking something. Also, during animations, the board in memory was in an inconsistent state, waiting for the end of the animation to then continue processing.

Recently I’ve read some stuff about Domain-driven design (DDD) and decided to apply a bit of it in this game. My first step was to separate my code domain from the others, I selected game’s mechanics as my core domain: if this part is not well behaving and it’s hard to maintain, I’ll be in a bad spot. Then I went to create this domain classes completely separated from the rest of the game, I ignored the existence of Unity3D at this point.

I only seen a single entity for this domain: the board. It makes no sense for the piece to exist on its own, everything that involves pieces always happens inside the board. I still have a class for the piece, but it is an internal thing of the board. My design became this:

public class BoardPosition {
  public readonly int Row;
  public readonly int Column;
  public BoardPosition(int row, int column) {
    Row = row;
    Column = column;
  }
}

public class Board {
  private Piece[,] pieces;
  public Board() {
    pieces = /* Initialize pieces */;
  }

#region Queries
  public Piece PieceAt(BoardPosition p) { /* ... */ }
#endregion

#region Events
  public delegate void PieceCreatedDelegate(BoardPosition position, Piece piece);
  public event PieceCreatedDelegate PieceCreated;

  public delegate void PieceDestroyedDelegate(BoardPosition position);
  public event PieceDestroyedDelegate PieceDestroyed;

  public delegate void PieceMovedDelegate(BoardPosition from, BoardPosition to);
  public event PieceMovedDelegate PieceMoved;

  public delegate void PiecesSwappedDelegate(BoardPosition a, BoardPosition b);
  public event PiecesSwappedDelegate PiecesSwapped;
#endregion

#region Commands
  public void SwapPieces(BoardPosition a, BoardPosition b) {
    ...; // Swap pieces
    PiecesSwapped(a, b);
  }

  public void StepGameState() {
    ...; // Destroy pieces
    ...; // Move pieces
    ...; // Create pieces

    for (...) {
      PieceDestroyed(...);
    }
    for (...) {
      PieceMoved(...);
    }
    for (...) {
      PieceCreated(...);
    }
  }
#endregion
}

This way, the view part of the game register itself to handle the events generated by the board and update the user interface as needed.

public class BoardView : MonoBehaviour {
  private Board board;
  private GameObject[,] pieces;
  void Awake() {
    board = new Board();
    board.PieceCreated += HandlePieceCreated;
    board.PieceDestroyed += HandlePieceDestroyed;
    board.PieceMoved += HandlePieceMoved;
    board.PiecesSwapped += HandlePiecesSwapped;
    pieces = /* Initialize pieces based on 'board' */;
  }

  public void HandlePieceCreated(BoardPosition position, Piece piece) { /* ... */ }
  public void HandlePieceDestroyed(BoardPosition position) { /* ... */ }
  public void HandlePieceMoved(BoardPosition from, BoardPosition to) { /* ... */ }
  public void HandlePiecesSwapped(BoardPosition a, BoardPosition b) { /* ... */ }

  void Update() {
    board.Step();
    if (/* ... */) {
      board.SwapPieces(a, b);
    }
  }
}

This design made it hard to sync time between the model and the view. The model calls the methods of the view to notify about changes, the view has little space left to decide when to handle each event. In my case, some events started animations that needed to hold other events from happening, i.e. there is a temporal sequencing between some events.

I changed the model to return a list of events that happened at each command, instead of calling the handler directly:

#region Events
public interface BoardEvent {}
public class PieceCreated : BoardEvent { /* ... */ }
public class PieceDestroyed : BoardEvent { /* ... */ }
public class PieceMoved : BoardEvent { /* ... */ }
public class PiecesSwapped : BoardEvent { /* ... */ }
#endregion

#region Commands
public List SwapPieces(BoardPosition a, BoardPosition b) { /* ... */ }
public List StepGameState() { /* ... */ }
#endregion

Now, the view needs to call the handlers itself, but can decide when to handle each event:

public class BoardView : MonoBehaviour {
  private List events;
  void Update() {
    if (events.Count &lt; 1) { events = board.StepGameState(); }
    foreach (BoardEvent e in events) {
      if (CanHandleNow(e)) {
        Handle(e);
      }
    }
    // ...
    if (HandledEverything) { events.Clear(); }
  }
}

After this, I still felt that this temporal sequencing was not clear, it was “floating in the air”. I decided to put it into the model, it’s part of my domain: every event has a temporal identifier:

public class Board {
  private int timeCounter;
  public List StepGameState() {
    ...; // Destroy pieces
    for (...) {
      events.add(new PieceDestroyed(timeCounter, ...));
    }
    if (eventHappened) { timeCounter++; }

    ...; // Move pieces
    for (...) {
      events.add(new PieceMoved(timeCounter, ...));
    }
    if (eventHappened) { timeCounter++; }

    ...; // Create pieces
    for (...) {
      events.add(new PieceCreated(timeCounter, ...));
    }
    if (eventHappened) { timeCounter++; }

    return events;
  }
}

public class BoardView : MonoBehaviour {
  private int timeCounter;
  private List events;
  void Update() {
    if (events.Count &lt; 1) { events = board.StepGameState(); }
    foreach (BoardEvent e in events) {
      if (e.When() == timeCounter) Handle(e);
      if (e.When() &gt; timeCounter) {
        stillHasEventsToHandle = true;
        break;
      }
    }
    if (/*handledAnimationOfAllEventsOfMyTimeCounter*/) { 
      // Advance time perception of view
      timeCounter++;
    }
    if (!stillHasEventsToHandle) {
      events.Clear(); // Will step game state at next frame
    }
  }
}

Both view and model has a temporal identifier and the sync is more evident.

The actual code is looking very similar to the listed here. The model is handling well up to now. I feel bad about one thing: the Step command of the model may leave the board in a “not-consolidated” state, as it makes a single interaction to check for matching groups to be removed from the board. The view then needs to call the Step command more than once between handling two inputs from the user. I didn’t want to make a lot of interactions in a single Step to avoid putting lots of stuff in memory before anything is handled by the interface, looks like a waste to me. I miss the lazy part of Haskell.

I still have lots of stuff to add to the game’s mechanics (my core domain). I’ll see the problems of this design in the next days and will post news with the next changes. Critics and suggestions are welcome.