Author: Christopher Evans

Want to be able to quickly record your weight? Want an app that doesn’t require your email address or join a social network? This is an app for you!

Why does every weight tracking app want my email? Why do they want me to post to Facebook, Twitter, SnapChat, or their own personal network? Seriously, I just want to record my weight!

All I want to do is toquickly record my weight and get on with my day. Is that too much to ask? I couldn’t find an app that just did this, so I decided to make my own.

Weight In, does not need your email address, it does not need you to sign up for some web service. It does one simple thing and it does it well. It lets you quickly record your weight, and get on with your life.

Today I am going to talk about how my spawning system has evolved. It first started with a Spawn object, who’s main job is to display spawning related information to the player; such as where the enemies will be spawning from. The key thing to note is that the Spawn object does not spawn enemies. It is given a spawning component which tells the game when it is time to spawn an Enemy object; I will talk more about components in a future post. I pick this design because I wanted a lot of flexibility when it comes to spawning enemies.

My first spawning component was the easiest thing that I could think of. Basically it would spawn a Enemy object of type X, at a regular interval. Example: spawn weak Enemy, every half a second. The goal was to get something playable very quickly; knowing I would improve this later.

For my second iteration, I wanted something similar to other tower defense games. Such as spawning waves, notification that enemies will appear, and indicator of what type of enemies will be spawning. I created a SpawnWave component that held a collection of Wave objects. The Wave object holds a collection of enemies that would get spawned and some metadata about the Wave. The SpawnWave component would go through and figure out when a Wave should start, and then the Wave object would iterate through its collections of enemies and spawn them. The SpawnWave object would hold a bunch of Wave objects, and remove them when they are finished.

This worked well at first, but as time progressed I wanted more control over spawning. I had an vague idea of what I wanted, but wasn’t sure if it would be worth the time. It was only when I was trying to fix a bug in SpawnWave, that I decided that this code was a bit too complex and that I should try the new idea. My thinking was some type of a event based system, where I have a collection of events that are fired when their time is ready.

For my third iteration, I created a SpawnEvent component that holds a collection of Event objects. Event objects has a spawn time as well as a method to be called when it was time to be activated. I was surprised how simple and smaller the SpawnEvent code was compared to SpawnWave. Note for the design pattern junkies this is command (Event) and event queue (SpawnEvent) patterns.

At first I only had one Event, which spawned an Enemy object. I shortly realized that it could do much more. A Event could spawn a group of enemies, it could display a message to the player, it could give the player money, or even cause them to win the game. The possibilities are basically endless, and so far fairly easy to implement (hopefully it will continue to be so).

But all is not great in event system land, with power comes responsibility. In giving the designer this level of control, it also means they have to keep track of more stuff. Such as making sure Events fire at the right time or making sure they don’t forget to add a important Event. I had one issue where enemies would be spawning perfectly, and then all of a sudden a bunch enemies would spawn on top of each other, looking as if only one enemy had spawned. Can you guess what the problem was?

The problem was I had a bunch of Events in the middle of the SpawnEvent collection who’s spawn time said they should spawn at the start of the level. Since they where in the middle of the collection, SpawnEvent would see a bunch of Events, where spawn time was less then simulation time and trigger them all at once.

Overall I am pleased with how the spawning system has turned out. The components allowed me to quickly test ideas. I was able to come up with a really simple and easy to use code. Makes me wonder why I didn’t think of this at first. Maybe that is a sign of good design?

My last post I talked about different UI designs that I could do for the tower defense game. I solicited feedback from a bunch of people and implemented what I think is a good touch system. Here are some screen shots of my efforts.

If the user selects a tile with no tower.User selects a tile with a towerUser doesn’t have enough money to build all the towers.User doesn’t have enough money to upgrade the tower

What I find interesting is how I started off refactoring code and feeling good about what I was doing. Then as time went on, my code got ugly really fast. I feel part of this is due to my misunderstanding of how to work with UIKit and SpriteKit, but maybe I am just trying to make excuses.

To appease my code design guilt, I kept telling myself that this is semi prototype code. That I can go back and change it, and that it is better to get something working then it being prefect. I once heard a game developer say, “if you code something quickly and ugly, and you never change it, then you coded it the right way”. I don’t know if I completely agree with that, but it rings true enough.

At this point I want to get feedback from play tester and let their feedback drive any improvements. My thinking is that when people only talk about the game play and not the touch system, that is when I know it is good enough. Or to put in a different way, if they don’t notice it, I did it right.

The main actions for my game is building, selling, and upgrading towers. I have been wondering how the user should do these actions? Right now I am going to focus on just the building aspect. I might do another post that talks about selling and upgrading.

When I first implement this part of the game I chose to code it the quickest and easiest way that I could. Now that I want to get this ready for play testers, I think that I should create the UI/UX the “correct way”. Basically draw everything out using pen and paper and get people feedback before coding. I already did some pen and paper work and decided to converted them to images (using Keynote), for your viewing pleasure.

UI 1:

This first design is basically what I currently have. You tap on a tile and it display the towers that you can build. This is the simplest to code and is fairly easy to understand. The main thing I don’t like about this is how much finger movement is required to build a tower.

UI 2:

For this one when you tap on a tile it display the towers that you can build around the selected tile. This one is very appealing to me, but I fear it is also the hardest one to code and get right.

UI 3:

The towers will always appear on the screen and it gives the user two ways to build towers. First they can tap on the tower to build and then tap the tile to build on. Second they can drag from the tower and it create a ghost version that they drag it to the tile they want it build at. I like the idea of the ghost version because I could also show the firing range of the tower.

UI 4:

For this one I am thinking more like an RTS game, where you have the list of towers in a scrollable area. It would have the same input methods as UI 3. The main difference is, it is reducing the visibility of the most importance part of the game, the map. I am currently displaying it on the right side of the screen, but it could be anywhere.

Those are currently the designs that I am fixating on, maybe after this post, more idea will come to me. Even with these designs I still have some things that I am not sure about:

Finger travel: This is the main thing I want to avoid. On an iPhone it is not a big deal, but on an iPad (or Pro) this gets annoying.

Blocking the screen: On the iPhone the screen is so small that I worry about having to many things on the screen. On the iPad I have lot of screen space.

To many taps: I worry about requiring the user to tap a lot.

Number of towers: I am not sure how many towers I want to have in this game.

Needless coding: I don’t want to spend too much time coding when the input system may change.

I would love to get some feedback about these designs. Maybe you can think of something simpler. Maybe you have things that just bug you in Tower Defense games. I would love to hear it.

My last post I mused over how I could handle the connect yet unconnected nature of using SpriteKit and how I was doing spawning and timing in my game. I am please the say that the solution was far more simpler then I was dreaming of.

To recap, my game run off the time it gets from the SKScene.update method. I would then calculate how much time has past between the frames and then pass the “delta” to all my other objects that needed updating.

After some searching I decided to treat my game logic more like how I would a physic engine. Instead of passing in the delta time between each frame. I now process a fixed amount of time, multiple times during each frame. Keep reading if that doesn’t make sense, hopefully I can explain this more clearly.

Currently SpriteKit calls the frame update method about every 0.016 seconds. I decided that I would set my step time to 0.014 seconds. Or in other words my game logic would calculate how much has changed in 0.014 seconds. It would does this calculation at least once every 0.016 seconds.

One problem with this is that if my game logic updates every 0.014 seconds and SpriteKit updates about every 0.016 seconds, after 7 frames update my game logic would be one frame behind (0.016 * 7 = 0.112; 0.014 * 7 = 0.098; 0.112 – 0.098 = 0.014). It doesn’t seem like a lot, but after a few seconds everything in the game would be wrong and no one would want to play it.

To fix this problem of missing steps, I keep a sum of the delta time between each frame in a variable called “simulationTime”. Then if simulationTime is greater then 0.014 I take a step. After each step I subtract 0.014 from simulationTime. I continue doing this until simulationTime is less then 0.014. Using the numbers above, every 7 frame updates I would take an extra step.

Now to have the game logic move faster or slower, it is just a matter of multiplying the delta time between frames by the speed the user selected. If the player wants the game to run 2x faster, I just times the frame delta by 2 and my game will take the correct number of steps each frame. If I want it to move half the normal speed then I just times it by 0.5 and it just works.

I am really happy to see is that even if the game is running 2x times faster (it is taking 3 to 4 steps each frame) the game is still running around 60 FPS without any problems. If I start having issues with a drop in FPS I can always raise or lower the step interval, but I wont worry about that unless I need too.

Overall I am pleased with this. I can now continue using SpriteKit and enjoy the animation, and still have the rest of my game run smoothly with no issues. I am hoping that I can convert a more of my code to SpriteKit and reduce the number of lines that I have written.

One thing that I did notice during this time, is that I can no longer use the simulator; I have to use my device. When testing in the simulator the game is running at about 12 to 20 FPS. While on my device I get about 60 FPS. I also notice strange slow downs on the simulator, but not on the device.

If you want to learn more about variable time stepping a great resource is this blog post.

When I started working on this game, I took some old path movement code and adjusted it to work with the game. I considered it a quick(ish) implementation and hoped it would be fine. The code took a path and and every update it would pass in the time that had past and it would calculate where the object needed to be. This created a consistent linear movement which is what I wanted.

Unfortunately the code had two main problems. The enemies are only single file and the movement didn’t feel as smooth as I wanted; especially when it was running at 4x speed. Now that I am in a polishing mind set, for the past few days I started reworking this code.

My first though was to see what options SpriteKit and SKActions had for me, and to my surprised it has a follow path action. This action work much better then what I had created. The main difficulty that I have, is it has no dynamic speed control. Well, that is not completely true, there are methods for controlling speed and duration of an action, but getting this to work for just one action yet alone for the many that I will have in the future made controlling and calculating the speed for actions far to difficult for me.

I felt like I was doing thing that hardest way possible, so I started to review documentation and blog posts to see if there was better way. I discover that there is a speed property on SKNode. This property will affect the speed on itself and all its children node and their corresponding SKActions. Meaning I could just set the scene (SKScene is a child of SKNode) speed to 2.0 and all animation and actions will move at that speed. I wished I had notice this properties earlier, but I guess I just need to learn to read the manual more closely.

I wish that, that was the end of this tale, but there is still a problem. If I slow down the game, the enemies will spawn really close together, if I speed up the game they will be further apart. The enemies still all move at the same speed it is just a problem when they spawn. I think I know what the problem is though.

When I spawn an enemy I am using the time I get from SKScene.update method which is in system time. In my code I calculate the different in system time from the last update and I pass that delta down to the update method of my game objects. My thinking is that I need to create what I am calling simulation time. Simulation time is the time that the game thinks has past, not the what the wall clock says.

My thinking with simulated time is it will add a fix duration for each frame. This duration will be modified by the current select game speed. Then when I need to do a time base calculation I can know that simulation time will match what the user is seeing on the screen and everything will be nice and smooth.

I have a bit more research to do, because I don’t think this idea of simulated time is anything new. Hopefully I am not to far off on a workable solution.

I recently lost all everything in my Documents folder on my Mac due to iCloud Drive. I spent the last couple of days trying to restoring what I could, but sadly I could only recover a small percentage of my data. 🙁 Fortunately I had a fairly recent backup of my Tower Defense game.

I am trying a different method of building a game then I normally do. I am forcing myself to implement the minimal code needed to have a working feature. Then I work on the adjacent features until I have them working together. Then I go back and do a small improvement pass, and repeat. My hope is that I can avoid the over engineering (I do that far to often). So far I am liking it, but I find that I am refactoring a lot.

Today I focused on level progression. Making it so not all levels are available and requiring passing a level to be able to proceed to the next. Now three levels do not make much of a game but it is enough complexity that I can test the general idea. I have a ways to go, but it is something.

iPad screenshot of the game map. With three levels and only one is playable right now.

We wanted to have a place where we could record what we have and are currently working on. A place where we could talk about the deep dark technical details or the high minded aspiration, where we could just vomit our thoughts and show how messy we are at developing our stuff.

For today I have gone through and updated our website so we could have a nice place for all this vomit.

I wont lie too you, you’re going to die. Death is likely might seem simple, but it is deceptively so. You’ll think you have it, and then suddenly you’ll be trapped in a corner with enemies all around you.

That’s OK though, because this is a game that lets you play at your time and leisure. Give you brain a tease, and stop when you’ve had enough.

This is not a game based on quick reflexes. It doesn’t have some time base come back in 4 hours game mechanic. Nor does it have some nefarious In App purchasing system. We hate those!

Death Is Likely is a game that we would enjoy playing and you will too.

One day Michael couldn’t remember how much money he had in the bank after making a large purchase. While he was trying to figure out how much money he had spent, and looking over the many different budget and money tracking apps he had purchased but never used. He realized he was lost in a dark and expensive forest.

Not sure how he had gotten here, he decided to ask the bear that was standing over him, where he was. Instead of providing any help, the bear attacked him and that was the last we ever heard of Michael.*

Don’t be like Michael and waste your time on overly complicated money apps, that you will stop using after a few days. Instead give money pile a try, it is FREE!

Our team of military grade scientists from NASA trained in elite software and hardware combat simulations, have found a revolutionary way of dealing with money.** First keep track of how much money you have in a pile. Spend money, subtract money from the pile. Earn money, add money to the pile. It’s that simple!

And if you keep reading you will find out how to become a millionaire!*** Follow our non-patented idea, and this simple easy step. If you got money, spend it. Don’t got money, don’t spend it! It is that simple!

So next time you find yourself wanting to track a pile of money. Think of Money Pile and let it put all your money worries behind you. You don’t have to worry about ever getting lost in dark and expensive forest again.

P.S. We do not recommend talking to bears.

* Don’t worry, there really was no Michael. This is just a fun story we made up for your entertainment.

** We are not military grade scientists from NASA trained in elite software and hardware combat simulations. We are a couple of programmers making apps we find useful.

*** We cannot guarantee that you will become a millionaire if you use Money Pile.