DEV Blog: Dog Walker – progress through iteration

Build something new. Break it. Then wipe the slate clean and try again. Eventually, your slate will bear a completed project, reinforced with all the failed iterations you washed away. And even afterwards, once the project is finished, you can reuse that knowledge. The project can be extended, or re-imagined into something new: a chance for further learning and development.

This blog post is a check-in/retrospective hybrid about the app I’m working on: Dog Walker. Dog Walker is the tentative name for a mobile app where you use real life activity to walk and race with virtual dogs. I want to talk about the ideas and projects that preceded this app, and how they’ve informed the current work on Dog Walker.

This idea has been cultivating for a while, thanks to a cyclical process of trying new things, throwing them away, and starting again. This helps me build skills and knowledge in new areas, while not tethering myself to initial mistakes within any one project.

I like to think of each iteration of the core idea as helping me learn new skills and try new mechanics, which I refined through restarting the project until it was complete. That refined knowledge allowed me to create the next idea, the next project, the next mechanic. With those came new skills, which I honed in the same iterative fashion.

When I first started working on the initial iteration of Dog Walker, it was very different. I wanted to work on my development skills without having to worry about creating art. I’m not an artist, and at the time I didn’t want to spend any money on commissions. So, I transformed my idea to walking Pokemon instead of dogs. There were two reasons for this: I love Pokemon, and there is a ton of existing Pokemon art I could use for my ideas.

It’s also really motivating to work on your projects/ideas using existing franchises you already like. The idea of hatching Pokemon eggs by walking in real life (akin to the main-line games)? Who wouldn’t want to learn how to develop that?!

And so I did. My first app, Pokemon Day Care, taught me iPhone development and used the initial mechanic of using real life steps as in-game experience. The extension of that idea into a web app taught me a lot about C# and Web development. After that, transforming the idea into two apps for the Fitbit let me dabble in JavaScript development. Finally, I moved to creating my own IP, where the above ideas are refined in a mobile app, letting me practice my Unity development skills.

Pokemon Day Care iPhone App

Various screenshots of the Pokemon Day Care iPhone app

Skills Learned

  • iOS Development
  • Model-View-Controller design pattern
  • Swift coding language
  • Debugging
  • Playtesting
  • App deployment

Game Mechanics Introduced

  • Using real life steps to hatch, level, and evolve Pokemon
  • Collect new eggs once a day by logging in
  • Collect gym badges by collecting the teams of the Johto gym leaders
  • Challenge prolific trainers for the highest step count in the leaderboard

Pokemon Day Care is an app I made for the iPhone 6S. It used your daily steps to hatch, level, and evolve Pokemon you collected from Professor Oak. It is similar to Pokemon Go’s egg collection mechanic, but there are some key differences. This app doesn’t need an internet connection to be played. You also don’t need the app to be running (or active in the background) for your steps to be used in the app. While I loved Pokemon Go (I walked 16 kilometres the day it came out), I didn’t like having to stop in my tracks to focus on the app. So, Pokemon Day Care syncs your steps once a day, using Apple’s HealthKit, to allow you to focus on your exercise without checking the app!

I worked on this project during university, while I was learning about app development. One of our assignments was to make an iPhone shopping app using the Model-View-Controller software design pattern. I saw how I could implement the same design pattern for my app, and after a few iterations I managed to complete it. I learnt a lot about iOS development and coding in swift, as well as debugging, testing, and deploying apps.

Pokemon Day Care Web App

Screenshots of the Pokemon Day Care web app

Skills Learned

  • HTML, CSS, Javascript, and jQuery
  • C#, LINQ, and SQL
  • Azure Web App Deployment
  • Fitbit API integration
  • Documentation maintained and created for version updates
  • Dedicated DEV and PROD environments for quality assurance, debugging, and testing
  • Use of the Software Development Lifecycle during the development, release, and maintenance of this project

Game Mechanics Introduced

  • Complete with other users for the most steps in leaderboards
  • Weekly and Monthly leaderboards

This iteration of Pokemon Day Care was an online web application that used a user’s Fitbit step data to hatch and level Pokemon. It’s pretty similar to the iPhone app, but the leaderboard was updated and let you see other users steps. The application was hosted by Windows Azure with information stored and maintained in an SQL database.

This project was initially very difficult. I restarted it multiple times out of frustration. Luckily, I was working as a .NET developer while developing this project. So while I was gaining knowledge at work, I was able to transfer it to my web application. I’ve come a long way since then, even becoming a Microsoft Certified Professional for Web Applications.

The Facebook page for the Pokemon Day Care web app

This was also probably the most traction any of these projects received. At it’s peak there were over 50 daily active users worldwide. Kinda bad numbers, but I didn’t advertise or promote it too heavily. However, this limited audience presented the opportunity to practice writing change-logs and dev blogs, where I described changes and updates to the site.

This project came to an end when I was trying to implement a race update, where you could race NPCs for the most steps. This was meant to motivate people (me) to run more. You’d be able to challenge a NPC and your Pokemon team would gain experience based on the results and your steps.

Unfortunately, I wasn’t able to get access to intra-day step data from Fitbit (it needs to be approved on a case-by-case basis, and this case failed), so I stopped working on the website and eventually took it down.

After a while I was determined to try this new mechanic again, but on a more accommodating medium. I wanted to update my Fitbit as well, since it was over 2 years old and a little worse for wear. That’s when I noticed I was able to develop apps for my new Fitbit Versa, and it would have access to intra-day data off the bat.

Pokemon Day Care Fitbit Apps

Screenshots of the Pokemon Day Care apps for the Fitbit Versa

Skills Learned

  • Greater understanding of JavaScript, CSS, and SVGs

Game Mechanics Introduced

  • Race against NPCs to see who can gain the most number of steps in 15 minutes

These next two apps introduced the least new amount of skills, but they were a great way to reiterate over the existing skills to hone the racing mechanic on a new platform.

PDC Battle was an application that lets you race AI opponents for the most steps within a set period of time, and PDC Hatch was an application that uses your daily steps to hatch and level Pokemon.

PDC Hatch was just yet another re-imagining of my previous works, but PDC Battle was the app that introduced the failed “racing” mechanic into my work. You were able to battle the Gym Leaders of Kanto, each one rising in difficulty, until you came face to face with the Elite Four. You could keep track of your badges, wins, and losses, all in the app! I had to tweak the difficulty of the game initially, as during my play-testing I couldn’t even beat the easiest Gym Leader! But some tweaking to the difficult settings fixed that right up. The difficulty scale was tweaked to help me increase my running speed, where the most difficult trainer would be my goal pace for a 5 kilometre run. Unfortunately, my Fitbit broke before I could reach that far, and now these two projects are stored on Github (PDC Battle here and PDC Hatch here).

PDC Hatch in action!

This project was fun to work on. I was working as a JavaScript developer while completing this project. I had also used JavaScript previously to get my web application to work, and Fitbit used a lightweight JavaScript engine for apps, so there was a lot of skill overlap. The apps could only be 10MB in size at installation time, so condensing the apps down was a real challenge. In a way, it helped shape the apps more than it did constraint it. The size limit is why the apps are separate, and it stripped away the unnecessary bells and whistles I would have been distracted in implementing. Nonetheless, I battled ferociously with the Fatal Jerryscript Error: ERR_OUT_OF_MEMORY message that would taunt me through development. Finally, through tons of refactoring and minifying, my apps were small enough to be played without any issues!

Dog Walker App in Unity

Now we’ve come to my current project! The final iteration of this idea to incorporate real world fitness into a game comes in the form of my Dog Walker app. This takes inspiration from all the previous ideas, culminating in an app where you can walk dogs and race alongside them against your (in game) neighbours.

The biggest difference here is changing the theme from Pokemon to dogs. This was done for two reasons: 1. to allow myself to publish this without any copyrighting issue, and 2. to let me dip a toe in contracting artists for work.

This iteration has proved the most difficult. I made the decision to create this idea in the Unity game engine. I love game development, and am now no stranger to C#, but I’ve only developed a small few games in the engine. You would have seen some blog posts on Egg Catch and Remember This! somewhere around here. I also have a lot of other larger ideas I want to implement using the same engine, so this project serves as an important conduit between developing small web based mini-games and developing projects on a larger scale.

I have restarted this Unity project probably around 5 times. Since my initial prototyping attempts to now. Thanks to my previous attempts, my current vision for the project is at its most clearest. I’m hoping this iteration of Dog Walker will be the final one.

My most recent abandonment on this project was utilising a web API I created, which would update an SQL back-end and return results. This relied too heavily on an internet connection (straying from my first app’s vision), so I canned the project. I’ve now restructured the development to avoid the need for an internet connection wherever possible.

Meet your neighbours from the Dog Walker app!

While I don’t have much to share from this project, I can share these adorable dogs and their owners! I commissioned an Adelaide artist to help come up with concepts for these characters, and I’m really happy with how they have turned out. I worked with an artist called Krystal Davies and you can find her website here. It’s been a lot of fun collaborating with other people in Adelaide. Now it’s back to the grindstone to ensure the code in this project is as good as the art!

That’s it for today! I hope this little project retrospective was an interesting read. I find it neat that my past projects reflected skills I was using for my work positions at the time. Kind of like a symbiotic relationship where I was developing my work skills, and advancing my hobby projects at the same time.

I don’t think I’ll have another blog post for a while: I need to shift my priorities to app development. But you can always find me on twitter, where I am very bad at remembering to post!

Until next time,

DEV Blog: Spirit Cleanser Enemies

A four-day long weekend coupled with a state-wide lockdown has done wonders for my productivity. Positivity is always welcome during times like these, which is why I’m thankful this streak of solitude granted me to the time to revisit a prototype I had shelved.

There’s a bit of irony on why I had avoided it for so long: I was frustrated with how the player handled being hit by a large enemy. It was only a rectangle box, but when it attacked from above the player just squished between it and the floor, instead of recoiling away. Should I have just fixed it? Perhaps. Did I instead spend a significant amount of time learning a visual scripting plugin for Unity, in hopes it would prevent future issues like above? Perhaps.

After all that I realized I’d rather write code than drag nodes, and after only 30 minutes of concentrated debugging, this insignificant bug was squashed. I wasted quite a bit of time on my time saving scheme. Nevertheless, glass-half-full as I am, this means that my base enemy logic is complete. So, I thought I would share it with you. Now I have a nice little prefab, consistent with every enemy, that can be built on to ensure unique yet unified foes.

That is, you can possess all enemies, and you can cleanse all enemies. This process is how every enemy in the game will be defeated.

Enemy Possession and Cleansing

Enemy possession and enemy cleansing are two parts of one whole. Together, they form the foundation of the whole game.

When the player projects their spirit, they can “spirit dash”. If they collide with an enemy during this dash, they will possess them. The body remains as a vulnerable shell until the spirit returns.

Possessing and enemy will make the player’s spirit disappear into the enemy. From there, a series of button presses will appear above the enemy. If they are pressed in the correct order, the enemy is cleansed and the player’s spirit is ejected back into the world.

I’ve represented these two pieces of logic with flowcharts. Flowcharts might not be the most appropriate for this, but I’m trying to re-familiarize myself with them.

Logic Flow from Spirit projecting to Enemy possession
Logic flow for Enemy cleansing

Making the Enemy Prefab

Every enemy needs to be possessable and cleansable. It stands to reason a base prefab is a great way to quickly and easily set the enemy logic, before layering on defining enemy characteristics. Straight from the Unity manual:

Unity’s Prefab system allows you to create, configure, and store a GameObject complete with all its components, property values, and child GameObjects as a reusable Asset. The Prefab Asset acts as a template from which you can create new Prefab instances in the Scene.


This prefab is going to need two things: scripts to handle the logic, and a canvas to display the UI elements.

The Enemy Canvas

The first thing I did for the canvas was to create prefabs for the buttons that need to be pressed for cleansing. These consist of an Image component, and a script that defined the sprite to show, and the corresponding button to press. All the script does is set the image, and tell another script about the button to press. There are four prefabs, one for each direction on the keypad.

public class CleanseButton : MonoBehaviour 
    public Sprite buttonImage;
    public string buttonToPress;

    void Start()
        GetComponent<Image>().sprite = buttonImage;
Cleanse Button game object values

I chose this approach for cleanse buttons to allow for easy button adding. If more difficult enemies demand more buttons on the keypad, then all I’ll need to do is add some more prefabs in this fashion. These prefabs will be passed as parameters to the enemy logic script, dictating possible buttons to press.

Our canvas is going to need a place to store these buttons, and to hold the timer. The hierarchy looks like so:

Enemy Canvas heirachy

You’ll notice the Grid is empty. The object has a grid layout group on it, and the buttons will be populated as children at run time. This is to ensure randomness. These objects on the canvas are also disabled to start: they are only visible during possession. The slider has a script on it to start timing when it’s enabled (it also has a variable for timer duration).

public class EnemyDamageTimer : MonoBehaviour
    public Slider slider;
    public float maxTime = 5f;
    private float timeRemaining;
    public EnemyDamage enemyDamage;

    private void OnEnable()
        timeRemaining = maxTime;

    void Update()
        slider.value = CalculateSliderValues(); 

        if (timeRemaining <= 0)
        } else
            timeRemaining -= Time.deltaTime;

    private float CalculateSliderValues()
        return timeRemaining / maxTime;

This script must be placed directly onto the slider object. This means the timer logic is visually separate from the enemy logic (you need to go into the prefab’s children to find it). It irks me slightly, but it works.

The Enemy Script

Now, the parent object of the canvas will hold the big script. This script dictates which buttons can appear, and how many. On start, the script will set the buttons (which will still be hidden), and wait for the enemy to be possessed. Once an enemy is possessed, the canvas will be enabled (which will also trigger the slider timer), and the script will check for button presses. Correct button presses remove that button from the grid. Once all the buttons are gone, then we kill the enemy and jump out of them. Else, the timer runs out and we jump out anyway.

Enemy Damage script editable variables

There are a few variables to tune here. I’ve listed them below with a short description for each one:

  • Mana On Cleanse: The energy returned to the player upon successfully cleansing the enemy
  • Enemy Grid: A reference to the game object holder the grid
  • Slider: A reference to the game object containing the slider
  • Number of Cleanse Buttons: The number of buttons that need to be pressed to cleanse the enemy
  • Possible Buttons To Press: An array of Cleanse Buttons that will make up the cleanse buttons
  • Punch X Max: Punch VFX on correct button press – maximum X offset
  • Punch Y Max: Punch VFX on correct button press – maximum Y offset
  • Punch Duration: Punch VFX on correct button press – length of effect
  • Possessed: A boolean that shows if the player is currently possessing the enemy

Most important are the possible buttons to press, and the number of cleanse buttons. These allow us to tune the enemy difficulty by increasing/decreasing which buttons to press, and how many times.

The Final Result

I can tell already this is going to make creating new enemies a lot easier!
Here’s a basic enemy with four button presses needed in two seconds.

Four Button Cleanse

And here’s another one with fifteen button presses needed in five seconds.

Fifteen Button Cleanse

Having this base so easily customizable means enemies can be tweaked to allow for specific gameplay action. What about small enemies that only need one button press? Line them in a row and let the player quickly obliterate them all, jumping from one to the other. Maybe an enemy with a short timer and long button presses? You’ll have to be smart and possess them multiple times to finish them off.

There are a lot of possibilities, and I’m excited to see what I come up with!

Possible Changes

Like every project ever revisited, this enemy logic is screaming to be refactored.

I’d prefer the grid and slider variables in the enemy script to be found via code instead of the drag and drop method. The variables are already set in the prefab, so it’s set in every prefab instance, but removing the clutter from the Unity inspector would be nice. There is a slight possibility it could cause issues (how would the script differentiate between multiple sliders/grids if an enemy archetype needed many?), but it is on the back of my mind.

The punch values being tweakable from the inspector seem unnecessary. For now it’s okay since we can tweak it easily if necessary, but if it should be consistent between ALL enemies, then privatizing the variables and making them constants could declutter that script in the inspector.

The last change that needs to happen is a major refactor of the script design. I think it would be cleaner if there was an IPossessable interface, which an abstract Enemy class that implements it. Then, each enemy archetype would inherit from the Enemy base class, and everything would be neat and tidy. I’m currently reading a book called “Clean Code: A Handbook of Agile Software Craftsmanship” – so I’m hoping that will motivate and guide me into tidying the enemy up even further.

Anyway, that’s it for now. Until next time!

DEV Blog: Fast Prototyping courtesy of the Unity Asset Store

a wheel
The humble wheel

Ah, the humble wheel. Look at it, in all it’s wheel-y glory. It’s quite a thing of beauty. Someone a very long time ago made it, in a flawless fashion, and it hasn’t been reinvented since.

Speaking of, I have another prototype I’m developing. It’s quite straightforward in it’s nature: download it on your phone, and exercise to walk a virtual pet. Simple. For now, I’ve named it Dog Walker. So you’ll understand that I have made absolutely nothing special for this, and relied almost exclusively on existing unity assets and packages to make a prototype as quickly and painlessly as possible.

I’ve done this for a multitude of reasons, but it resulted from thinking about what I wanted to create, what I needed to do to get there.

What do I want to create?

As stated above, a little phone app that motivates you to exercise via a virtual pet is the goal. That’s not too revolutionary. I’ve done something of the sort before, with Pokemon and various other mediums (see my Fitbit, iPhone, and web apps). This time I wanted to familiarise myself with Unity, and distance myself from piggybacking on my love of catchable pocket monsters.

I’ve thought about the features and created a prioritisation chart à la the MoSCoW method. The MoSCoW has helped me sort out what this app has to do in order to function, and other things that would just enhance that experience. Ultimately, anything outside the essential can be worked on later.

Dog Walker must

  • Be deploy-able to both iOS and Andriod mobile devices
  • Use the device’s built-in functions to access a user’s steps
  • Use the steps to walk virtual pets
  • Be able to be played without an internet connection
  • Be able to track a walk even with the app off

Dog Walker could

  • Have multiple dogs for the user to unlock and walk
  • Have a levelling system to see how much a dog has been walked
  • Have an energy system to stop the dog from being constantly walked
  • Have an affection system to show the dogs friendship level with the user

Dog Walker should

  • Be able to gather steps from other user devices (for example fitbit devices or garmin devices)

Dog Walker won’t (at this time)

  • Have any online capabilities
  • Allow step races – where the user competes with either AI or other users for the most steps within a certain amount of time

What do I need to achieve this?

Now, looking at what I’ve defined above, this doesn’t seem like a difficult thing to implement (though I may be getting ahead of myself). What I mean is that there isn’t a need for collision detection, no perfectly timed button inputs, and no player/enemy/boss logic. A lot of normal game logic doesn’t apply here.

All that has to be done, is to take a users steps, and then do something with those steps. Yes, it’s going to need to work on multiple devices. Yes, it’s going to have to persist data even when it’s off, but at the core it’s just about the steps.

So, to build a functioning prototype that actually gets a users steps is probably going to be the hardest part. It’s going to require some code native to deployment devices (to actually return real values). For now, I can create a prototype that works in every other aspect, and then just plug in the relevant code when the time comes. To do this, I’ve relied on two separate items from the asset store: DoozyUI and EasySave.

Doozy UI
DoozyUI for Unity

Easy Save
Easy Save for Unity

DoozyUI is a UI management system, which helped with transitioning to and from each Canvas with relative ease.

EasySave allowed for easy serialization of object classes to allow for the necessary data persistence.

Overall both were fairly easy to use, and with the Black Friday sales on the marketplace, it was a no brainer. I probably could have spent some time researching and implementing my own UI and save management systems, but I’m sure these assets do it better.

It’s a question I always revisit when trying to develop: Is it worthwhile investing in an existing asset for what I am trying to achieve? In this case, the existing assets won over.

Combining these two assets resulted in a pretty rapid prototype. I did have to mess around with a few things, but since the saving and canvas transitioning is pretty basic (thanks in no small party to EasySave and DoozyUI), there was minimal fuss.

Selecting a dog in Dog Walker

Walking a dog in Dog Walker

The above gifs show two particular workflows from the app, with little Pokemon dogs in lieu of actual assets.

The first one shows the how to select your “main dog” (i.e. the one to walk). From the main screen, the little dog icon will take you to the dog selection screen. From there, you can swipe across dogs and select one to walk. This will update the main screen with that dog, which you can return to via the back button.

The second one is the walk workflow. The current step calculation is just a constant number, but this shows the walk confirmation, walk in progress, and walk complete screens. If you were to shut down the app on the walk in progress screen, loading it back up with send you back there (with time labels updating correctly). It also incorporates the energy, level, and friendship elements from the “Should have” of my MoSCoW list.

Honestly, the time it has taken to create this blog post is probably on par with the prototyping time. The use of DoozyUI and EasySave has sped up the process and incredible amount, which now lets me focus on some other parts of the app that need their due diligence. Now UI Design and Step implementation can be tackled with minimal interference!

Until then!

DEV Blog: Spirit Cleanser Game Mechanics

All the best games are easy to learn and difficult to master. They should reward the first quarter and the hundredth.

— Atari founder Nolan Bushnell, on the subject of video game design.

This particular aphorism is oft repeated, yet it’s still a statement I agree with. As a designer, one of my main goals is to create mechanics that are accessible to everyone, but those who truly understand their limits can push the ceiling as high it can go.

Let’s use Overwatch as an example. Overwatch is a team-based FPS shooter, with a character called Lucio. Lucio has the ability to ride walls, and speed boost his team. Not too difficult to understand. I thought I grasped the idea pretty well. But then you have professional streamers: they show complete mastery of these elements, using them to be untouchable murder machines riding rings around the enemy team.

Wall riding can be difficult to learn…
A great Lucio example
But you can use it to great effect.

That’s why in developing this prototype, my intention is to have game mechanics that can be combined for riveting gameplay. I’ve been calling it “Non fare malocchio”, since it’s inspired from the Italian folklore about the evil eye, but “Spirit Cleanser” is a bit more to the point. Essentially, in this game you can project your spirit out into the world to “possess” and “cleanse” evil spirits from enemies.

There are three core mechanics to the gameplay that can be combined: spirit projection/dashing, enemy cleansing, and spirit leaping. Here’s how they work, and how they complement each other:

Spirit Projection/Dashing

The player project their spirit and traverse the world with it, leaving their body behind. When projecting the spirit, it will dash out into the world at a fast speed. It can be projected in all directions.

Spirit Projection
The player can project their spirit.

Enemy Cleansing

If the spirit collides with an enemy while dashing, it will “possess” them, and be able to “cleanse” them. This is done through a series of button presses.

Enemy Cleansing
The player’s spirit can cleanse enemies.

Spirit Leaping

To reunite the body and spirit, the body leaps from its current position to the spirit. If the leap button is held down, extra momentum will be added to the body once the spirit is reconnected.

Spirit Leaping
The player’s body can leap back to the spirit.

Combining the spirit dashing, enemy cleansing, and leaping to spirit mechanics makes for a game experience that is easy to learn yet difficult to master.

The game mechanics combined
Combining these elements makes for complex and rewarding gameplay.

I’m hoping that these base mechanics are enough to carry my idea while I flesh out the prototype more. No doubt, they will need to be revisited, and then revisited again, but for now the building blocks of what I’m trying to achieve are in a playable scene: that ticks the box for me.

My next goal is to create some more enemies to really test the mechanics and create captivating game moments! These elements seem to be fun now, but they have to hold up to a multitude of different enemies and environments.

Until next time!