Wow, can you believe that my last post was July12th, 2016? It’s been almost two years. Well, there are a few reasons for that which I’ve covered in a separate post. As for the game, there have been plenty of changes. Since the last update, I can’t think of a single system that hasn’t been touched. The update video will do a good job highlighting the most significant changes.

January 2016. Getting close to that two year mark. This month marks the first full month of iteration on an existing “platform”. I’m rapidly iterating through smaller features instead of spending months implementing core code. Because of that, I’m also going to change these status updates slightly. I’ll have my videos go through all the incremental changes, while the posts look through the bigger picture of what’s left. This should allow for easier tracking of overall progress. Additionally, I can save thoughts, ideas, and other general topics for the blog posts.

It’s been quite the 2 months. In anticipation of becoming a father, I’ve significantly picked up my work efforts. It’s not that I wasn’t trying before — it’s just that deadlines have a way of motivating me further. I’ve tackled a few major rewrites / problems with the foundation of my code, and I now have a working “game” that is actually installed on 3 devices via Testflight! With all of this in place, I can iterate on the platform and slowly work towards a rough alpha and then polished beta.

This update is similar to my last update in that I spent a month trying to improve the framework of a more complicated portion of the codebase. Last time was pathfinding, this time is combat. In addition to improving combat, I wanted to focus on data integrity and porting combat pathfinding to iOS9 / GameplayKit.

Note: This post has been backdated to keep the documentation accurate — the game was in this state as of Oct. 1st.

At the beginning of August I challenged myself to get pathfinding under control. In truth, if I couldn’t figure it out I would be forced to consider making the game turn based instead. So, I set out with a giant todo list containing many edge cases to solve. Fortunately, the main branch was merged in yesterday, so I’m in an infinitely better position than I was. It’s been an exhausting month, so I’m ready to move on. Let’s have a look at what’s been completed, and what issues still remain.

It’s been nearly two months since my last status update. To quickly sum up those two months, June was extremely productive while July was almost a waste. June consisted of implementing reusable menus, music, sound effects, button effects, volume controls, unit management and more. Basically, a lot of foundation type elements needed for a game. Unfortunately, I started playing with iOS9 in July, which happened to be both a necessity and a time sink. Finally, just last Friday, I finished the contract with the composer, so all of the music for the game has been completed.

This update is broken into three main events. First, I created spawn zones for the player to place their troops before battle. Second, I fixed off screen heraldry, and refactored the code to make it more flexible. Lastly, I played with consistent UI classes that will work for every screen. And in between all of that, I fixed bugs and worked with the composer (Tony Manfredonia).

An unsteady foundation is still a foundation, right? I’ve continued my work of porting all code into a single project. You can roughly play the game from start to level 2 right now. This means loading, saving, world map, placing troops, enemy waves, game over state, resuming, story, and more. There is a lot of core code in place.

For the past year I’ve been working on a bunch of different code bases learning new concepts. For this update, I decided to piece together a first build of my “game” to get rid of redundant bits of code. I’m left with an app that has menus, navigation, saving, loading, and cutscenes. While it’s still far from an enjoyable game, it’s cool stuff to have a foundation to work with.

I’ve spent every day of the past two weeks working on story. The good news is that it was worth the effort. There is a noticeable jump in quality, and it makes me feel a bit of pride for the product. I’m now optimistic that one or two more rounds of polish along with some sound and music will make it a worthy purchase for gamers. The bad news is that I still have one or two more rounds of polish to go, which turns into 2-4 weeks of work. Music starts on May 4th, so at least I have a concrete deadline driving me. Otherwise, I fear that I could tinker on this forever.

The past two weeks have been 75% story and 25% in game work. That trend will continue for the next few updates as I prepare to send the story of to voice and sound. The encouraging news on the story front is that the first round of polish has resulted in noticeable improvements. Most importantly, the new chat bubbles add animation and interest while also allowing me to add dialogue to travel and battle scenes. As far as battle goes, enemies now have a basic spawn service and will attack the closest target they can find.

Story, story, story. 8 of the 10 days over the past two weeks have been spent preparing story assets, implementing them into the game engine, revising dialogue, and getting the cutscenes to work. It has been extremely tedious, but it feels great to have finished a first pass.

I’ve done quite a lot over the past two weeks. Work has started on melee combat. I’ve hired a composer! But most of all, I’ve been consumed with cutscenes. When I started this process, I didn’t realize that the decision to add a story to my game would end up costing me ~30% of my budget and an equal amount of programming time. Now that I’m actually implementing the story, I’m starting to understand all of the implications.

I’m finally able to start writing game code, and it is fun. Now that learning and performance issues are almost behind me, I was able to implement  ranged combat and death, which is great to see in action. In addition to that, steady progress has been made on the world map, and early story boards are coming along. This update also marks the end of the first contract with Scott, my illustrator, but we’ll be entering a second contract shortly.

Things are moving along much better now. I wouldn’t say moving quickly just yet, but they’re at least moving. I’ve overcome a lot of technical hurdles and learning curves in the past 3 months. The latest of those was how to support 100-150 units on the screen at once. Serious progress has been made in that department. And, as always, I’ve received amazing illustrations and animations from Scott and Liron. Lastly, I’ve dabbled a bit in icon making.

Alright, so that title is sort of doom and gloom. Really though, my mood is pretty good. I’m a married man now! On the work front, the difficulty I’m encountering is programming difficulty, which I feel is in my control. That’s always better than art, story, music, sound or gameplay difficulty. Current pain points? Pathfinding, and moving units as a formation.

Last update was a rough one. My original concept for a tower defense game just wouldn’t work the way I had envisioned. So, instead of moving towards a standard tower defense game, I decided to change direction and make a sort of squad based defense game. This update covers that transition. Most importantly, I feel all of my problems right now are technical ones, and that the art will work out (or be adjustable).

The past two weeks have been a real shot to my confidence. It turns out that a perfect game does not live inside of my head. Instead, a game with real usability, budget, and gameplay issues lives in my head. Researching some of the questions I needed answers for last week revealed that there isn’t always a perfect solution, and that my game idea needs refinement.

If you remember, I left off last update finding and losing two artists. This update marks the beginning of my first contract with an illustrator, and the revelation that I have 1000 unanswered questions about my game. So, while I’m now super motivated, I’m also a bit stressed since every design decision I get wrong directly amounts to spending more money.

The past two weeks did not go as planned. What started out as a coding week that would involve balancing unit attributes turned into a full on art blitz. I received a lengthy, somewhat painful, and costly introduction into the world of art. At the same time, I received the invaluable jolt of excitement and motivation that comes from working with other talented people.

Last update marked the beginning of my conversion to Swift, and this update marks the end — almost. I continued to be plagued by conversion issues (64 bit this time) and time off (Bachelor party), but also enjoyed faster refactoring and cleaner code. I’ve now gotten the game back to playable with 10% of the code left to convert. Small details like synchronized walking animations, missing damage over time and other bugs remain, but I finally feel like I’m in the clear. This is a huge thing because for a second there I was a bit depressed and questioned my choice to convert to Swift.

It has been awhile since my last update. 4 weeks to be exact. And to top it off, my game has fewer features than it did the last time you heard from me. There are two reasons for this: The introduction of Swift, and the perfect storm of distractions.

If last week was a feature rush, this week was a feature overload. I’ve slowly been breaking out of the learning phase and into the implementation phase. I definitely know what needs to happen now — it’s just a matter of doing it. Exciting times are ahead because I can now begin testing features that will make my game unique. My update this week introduces a lot of those features, including a defendable castle and dynamic spawn points.

Last update I had a playable game. This update has been spent trying to add as many features to the game as possible, which has been an enlightening process that has revealed two lessons. First, I need to prototype since you don’t know what’s fun until you try it. Second, while my code is getting better, it still isn’t ready to scale to an entire project. Each time I add a new asset or feature, I’m finding myself copying a lot of code. By going through the motions, it’s becoming clear what needs to be fixed up.

Don’t look now, but I think my Xcode project just turned into a playable game. That’s right, you heard me correctly. User input, gold and a game over state. I would almost say it’s time to wrap things up and call it a win for team Ryan.

With update #3, I bring you my most challenging two weeks so far. As you can see from the featured image, working with Finite State Machines, and AI in general, plays a big part in my frustrations. When this cycle began, I was hoping to have wave movement, group formations and melee combat working. Since only one of those three goals was accomplished, let’s take a look at what went right and what went wrong.

Game development has always been intimidating to me. There have always been so many unknowns that learning how make a game, let alone write in C, seemed unachievable. The past two weeks have been shocking to me because the tools and libraries available have come so far that game development is now accessible. I feel like I did when developing for the web and jQuery/Prototype.js came out. It’s an amazing time and indie games will only become easier to produce.

April has been in my sights for some time now. After a move, some traveling, a bit of relaxation, building out an office space and designing this site, I’m finally ready to start working on games. Actually, this dream is a lifetime in the making.