Still working on the game…

Hi friends, fans and family!

Haven’t posted in a while and I thought I would correct that 😊. The game is still being worked on and I’ve made quite a bit of progress since my last post in February(!)

Instead of trying to remember everything that’s been added since I’ll try to pick out some of the “best” stuff and also talk what the next goal is.

Mission Objectives

I’ve added some code that allows me to setup different missions like for example: reach this point on the map, kill x number of enemies or a specific enemy, survive x turns etc and many more types will be added. I strongly believe that I need a lot of different mission objectives to keep the game “fresh”. There will also be secondary objectives that are not mandatory but will reward you with bonuses of different kinds upon completion.

Technical details

The way I’ve implemented this is I have “Mission” protocol/interface that has various different methods that act like triggers

Here are some examples: UnitReachedTile(unit, tile) and UnitWasKilled(unit) and NextTurn(turn).

The mission also holds a specific map with enemies etc

The Mission class is passed to a BoardManager class that knows when these events happen. The BoardManager then invokes the methods on the mission. So when BoardManager tells the mission that a unit has been killed, the mission code can check if this was the last enemy or if the enemy is a boss or if it was a player unit etc and set the state of the mission accordingly.

Fire & Ice

I’m going for skills that create a lot of emergent gameplay so I try to avoid attacks that only do damage and one of my “rules” when designing is that no skill is allowed to do only 1 thing. Ice for example freezes units so they can’t do anything for 1 turn which sounds pretty standard but…

A frozen unit will prevent fire from spreading and the ice will melt when attacked by fire. So you can freeze one of your own units to protect from a fire attack! The other thing you can do is freeze water to create bridges. If somebody stands on the frozen ice and they get hit with fire… Well the ice will melt and the unit will drown. Fire also spread randomly between tiles which gives the game some dynamism. I’m very pleased with how ice and fire is interacting though more graphical work is required to show it off more clearly.

Here’s some fire:

Technical details:

Lots of if cases 😂. Tiles can hold ice and fire (child gameobjects of the tile) and there is code to detect if something is frozen when hit by fire etc.


I think having different types of tiles is important in a tactical turnbased game since it makes positioning more “complicated”. The most common way of doing this is to give different tiles different bonuses/penalties: forests have +1 defense while hills increase the range of attacks or something like that (this is in the game already). Another way is by setting a movement cost for different units and tiles. In Fire Emblem for example, units on horseback have a harder time crossing forest tiles. I wanted movement to be impacted somehow but I’ve never been a fan of the “movement cost” approach since I feel it’s too fiddly so I needed to try something a bit different. Enter roads. A unit beginning their turn on a road can move their distance OR move freely on roads until blocked by an enemy. This allows you to move great distances. To mitigate this a bit I added a defensive penalty on roads which makes units on roads very vulnerable to damage. Here’s an example:

Technical details:

My first challenge was to place the appropriate road sprite on the corresponding position. I began by having a specific type for each road tile like “NorthEastRoad” and “NorthSouth” road etc but this quickly became unwieldy since mapdesign was hard and if cases for detecting types of tiles were huge and unreadable and I knew I was going to have to refactor it at some point. I then changed the architecture to work like this: all road tiles have the type “road” but when they are placed I examine all their neighboring tiles, if a road tile has a road above and below it then I know I have to place a “NorthSouthRoad” graphic there. This code was then reused to handle water as well. It’s now super simple to “paint” roads and water since the corresponding graphic is drawn without me having to think about it when designing 🎉.

The other problem was related to pathfinding and allowed tiles in a turn. When a units turn begins I check if it’s on a road tile. If it is I draw paths out from where the unit is standing and only add road tiles to the path until I can’t add anymore. So my “allowed tile movement” contains the normal range + the road tiles from the pathfinding. When a unit wants to move to another road tile I check if its within the unit’s normal range and if it is not I know that the unit wants to do a special road move and I restrict the red path arrows to only follow the road. My normal pathfinding cares about showing the shortest path so I need to restrict it so the unit doesn’t move outside of the road crossing hills, forests etc. The feature needs to be tested some more but it spices up the movement and feels different in a good way.


I’ve added some more shading to the units and also changed up the tiles to add some more variety on the maps and make them look a bit better. The graphics are still on the simplistic side and I’m favoring production speed and clarity over “beautiful” graphics, mostly because it’s the only realistic way to actually make and finish the game on my own.

Going forward

There are still a million things to do but my main focus right now is to send something out to my closest friends to let them have first stab on it and iron out some things before I make a “meatier” demo. This demo will most likely be used as an incentive for signing up on an email list that I will be creating shortly.

The other BIG thing is that I need a name for the game before I can start creating store pages on steam and itch. Once I have that I’ll be setting up a website to increase visibility and all of the other stuff you need to do so people know your game exists…

I’ll try to post a bit more often hereafter (aiming for once every two weeks) but you know how it is 😂

Finally, here some actual gameplay to finish up! Thanks for reading 🙏 / Luis

Dev log w6 (3-9 February) 2020

Ran into a lot of problems this week that ate up a lot of time and I had to restructure and understand a lot of small things (that’s the price you pay when you “need” to work fast) so I didn’t get a whole lot done unfortunately but I did learn a lot about how Unity works.

New functionality: 

  • Implemented a new skill for the wizard that raises impassable ice mountains on the tiles adjacent to him. If there are units on those tiles they are frozen. This effectively protects him from incoming damage and can also be used to block of enemy paths to other units. Will probably modify it to be a ranged attack.
  • Implemented a “unit details window” where you can see the portrait, name and hit points of a unit. This will also show any status effects or injuries that the unit might have etc.
  • And also %€#/!. Better luck next week I guess 😛 



Dev log: w5 (27 Jan- 2 February) 2020

Made great progress this week apart from on Sunday where I experimented with stuff that I ended up throwing away…

New functionality: 

  • Added functionality for terrain bonuses and penalties. Hills increase ranged attack distance and damage for example while forests give a defence bonus.
  • Archer can no longer fire on a unit adjacent to it. It is now basically an artillery attack
  • Added a turn label to indicate whether it’s the player or the AI’s turn
  • Hovering over a player unit now shows exactly how much damage it will take when the enemies attack 
  • Added a new symbol that shows that an enemy will move (I don’t indicate where) but that I won’t attack anyone
  • Added mountains. Mountains block paths just like water but also block some types of ranged attacks. Not “artillery” attacks (arrows etc). 
  • Implemented a move indicator. It shows whether the unit has moved but not performed an action, if the turn is completely over or if it hasn’t done anything yet. 
  • Added an END TURN shortcut key


  • Fixed some annoying pathfinding AI bugs where units would stand on top of each other in certain situations
  • Removed a crash on the swingmeter and fixed erroneous damage calculation when the Rogue unit attacked while cloaked
  • Made sure that inputs don’t register when animations are running 

Here’s the weekly gif 🙂


Dev log: w4 (20-26 January) 2020

Less productive than usual and only got 4 out of 7 days done (wife was sick) but I got some work done on a really cool new mechanic 🙂 

  • Added some panels to the UI to get a feel for the size of the map and the screen and increased the map a bit as a result
  • Fixed some issues with the damage number labels that appear when attacking. They were not following the characters correctly among other things
  • Added a ”swingmeter”. When the player attacks a meter appears which forces you to use  your reactions to maximize damage. Stop the swing in the big yellow zone and the attack does “normal” damage. Stop it in the red zone for “critical” damage. However, aiming for the red zone is risky since missing causes you to do LESS damage than normal. It gives the game a nice “Mario RPG” feel 🙂
  • Made sure that the rogue does more damage when attacking when cloaked

Here’s a gif of the first iteration of the swing meterswingmeter

Dev log: w3 (13-19 January) 2020 and a first look at the game

HI friends, fans and family!

In order to keep you all in the loop and tell you what’s going on with the new game I’ve decided to put up short weekly reports on what I’ve been doing. They won’t be super technical nor extremely detailed (makes it easier for me to actually write them :D) but will hopefully give an idea of where the game is and where it’s heading.


  • Changed layout of the game. The playing area will be in the centre and have two UI panels on each side of it. The panels will hold the buttons for special skills, objectives for the current map, unit and tile information etc.  Support for all 16:9 resolutions. Full HD (1920×1080), Nintendo Switch portable resolution…
  • Added unit subclasses. Started specialising the units a bit by giving them special abilities. The Rogue has a cloak ability that lets him/her disappear which make enemies focus elsewhere. If the Rogue attacks while cloaked the attack will do much more damage but the cloak will be lost and put into cool down. The Knight/Paladin has a guard ability that lowers the incoming damage that turn which can be used to bait enemies into attacking the Knight while others attack them from range for example. 
  • Set a foundation for different abilities by adding cool downs and durations and just making them easier to work with.
  • Added handling of multiple abilities. Each unit can now have multiple abilities as well as their “basic attack”. 
  • Simple bug fixes and cosmetic tweaks. Changing the facing of damage labels for etc…

Here’s a gif from the game:


See you next week!

// Luis

The embryo of a game

Hi fans, friends and family!

In my last post I mentioned that work has started on a new game and then I left you with a cliffhanger. This was more due to the fact that the game is in the very early stages of development and there’s not much to say yet, than an attempt to trick your mind into getting hooked and eager to come back for more :D.

How the project was chosen

I had three important criteria that I wanted to meet before I took on any new game project:

  • It should be a project that I’m confident that I can pull off technically. Something that caters to my strengths.
  • It should be a game that I would like to play. A game for me.
  • It should be something fun to design which for me means intricate little rules and systems.

Considering all these things and the fact that I’m working with a new tool (Unity) that lets me release the game on various platforms, I have chosen to once again make a turnbased game :). My reasoning being that the risks of using a new tool will be somewhat mitigated by my previous experience with implementing games in this genre.


The main difference this time gameplay wise is that you will control more than one character. Another feature will be some form of management of these characters outside of combat, though time will tell how expansive that part will be as it depends on how much effort we can reasonably put in before growing tired of the whole ordeal :P. Those are the only two things so far that are set in stone. I have some general ideas that I want to try out that I’ll be prototyping for a while and I’ll post here every now and then to keep you updated…

For those of you that want more frequent updates the best way of “staying in the loop” for the moment is to follow on twitter: or to check our facebook page that’s has a copy of the twitter feed. An email list will show up once the game has gotten some real traction.

Next time I’ll tell you a bit about the goals with this project and the general strategy to get the project over the finish line.


Update (no we haven’t stopped making games)

Hi fans, friends and family!

I haven’t written anything here for ages so I think it’s about time I correct that. While working on a few prototypes here and there I’ve made a couple of realizations which I thought I would share with you. 

I’m not in it for the money
The most important one was that I don’t actually work on these projects for money. After the release of “Rogue Knight: Infested Lands” I found myself feeling a bit disappointed which is strange considering we just released our first game which is a major achievement! I concluded that this had everything to do with the poor sales and the low download numbers and I got a bit obsessed by this. Not because I needed the money but because I was equaling sales to the quality of what we’ve made. This led to me thinking a lot more about the financial aspects of the next projects until I finally realized that this was a red herring. This is something I’ve had to remind myself of more than once. Why? Because it creates a lot of pressure to think in terms of “how will this make money?”. It leads to thoughts like: I should be putting in more work. More hours. I need more marketing. I must increase my follower count on Twitter.  I need to be featured on the website x and z wetc.

The truth is that I don’t have the available hours to be able to focus on all of these things and if I’m going to be able to enjoy this hobby I need to have realistic expectations. If I can only put it 2 hours per day at the most, how can I compete with games who have several team members that work constant overtime? Besides the fact that these things are simply impossible to do given my time they also suck the fun out of making games if I focus too much on them. I have to dial it down a bit and pay attention to the things that give me the most bang for the buck.

Find a project you’re really passionate about
I’ve dabbled with many prototypes since finishing “Rogue Knight: Infested Lands” and while I’ve had some initial enthusiasm, the fire always burned out rather quickly. The answer was easy: I was trying to make games for others but not FOR ME. I don’t play that much on mobile yet I make mobile games. I’m not fond of casual games that appeal to “everyone” yet I found myself thinking in these terms more than once (this was also affected by the “sales obsession” mentioned earlier). It’s fine to compromise and I’ll have to do it in many areas during development but I have to make something that I’m truly passionate about or the energy won’t last and I will become bored and uninspired rather quickly.

Go big or go home
In the end I don’t want to make small mobile games which means I got to take it up a notch. It doesn’t necessarily mean super advanced graphics or tons more hours invested but it does mean that the time of focusing only on iOS is no more. PC, Mac, Android here I come! Who knows, maybe I’ll even have something on consoles one day?

I’ve been learning Unity recently and have enough confidence to say that my current knowledge of C# and Unity is already at the required level to pull off what I want to do next which is…

I’ll let you know soon enough :). Thanks for reading!


All games don’t make money: Making of “Rogue Knight: Infested Lands” and Appstore sales figures

Hi friends, fans and family!

The following post will be a lot longer than usual and I will be telling you about the process of making and releasing “Rogue Knight: Infested Lands”, what went well and what didn’t as well as revealing the atrocious sales figures. I was inspired to do this after reading many of the awesome posts by Arnold Rauers who has been very transparent about the sales and making of his games (check out this post for example) and Ray Ferraro, the maker of Meteorfall who made a great retrospective which you can read here. Now, there’s a huge difference between their games and mine and the perspective of the posts. Their games would definitely be considered successful whereas “Rogue Knight: Infested Lands” would not. It met our goal which from the beginning was just a simple “release a game” but at the same time it feels a bit like a failure in retrospect with the sales being practically non-existent and the game being far away from any bragging rights regarding to AppStore ranking. But enough with the long winded intro. Let’s begin with the beginning!


I started working on a prototype in March of 2016 with the goal of learning more about making tile based games and using pathfinding to move characters around a map. My game idea was not much of an idea at all actually. I just wanted to make something turn based on a tile based map. After a couple of days (read hours) programming I thought about the possibility of making a stealth game where you had to sneak around the map and avoid being seen by guards. The game had no theme or anything at this point. The main character could have been a thief, an assassin or just someone trying to hide from zombies. It really didn’t matter as long as I could get him to sneak around and hide from guards. This is what this EXTREMELY crude prototype looked like at this point:

simulator screen shot - iphone 8 - 2019-01-03 at 10.11.14

Last gen graphics, incredible AI and 60 FPS! This will be a super hit!


But don’t let the graphics fool you! There were actually quite a lot more advanced features in this prototype than what made it into the final game. The guards could have fixed and random routes that they patrolled, they ran to the place where they last detected the hero and stopped to look around if he had disappeared etc and their behaviour was quite “smart” in general.


During this time I convinced Xavier to make the game with me since square dudes with big eyes are not what most people find “aesthetically pleasing”. He was, like me, very interested in games but he had completely different talents. He knew how to make things look pretty. Even though he had mostly dabbled with board games he was (and still is :D) super enthusiastic about making digital games so he jumped onboard without any hesitation. We were still not clear on what kind of game we wanted to make though. We both played games like Hoplite, Microgue and Tiny Rogue a bit at the time so in the end we reached the conclusion that we should do something in that style but add “more of everything” and keep the stealth parts that I had been working on. The game looked like this after just a day or two with Xavier doing the graphics:

simulator screen shot - iphone 8 - 2019-01-03 at 10.40.44

A groundbreaking UI and potions everywhere. 



Our process was weird. During the year that we worked on the game, we didn’t actually meet physically more than once or twice despite living in the same city and 20 minutes away from each other (!). We did most of our communication through the Facebook chat. Xavier worked during the night and send me mails with comments, design suggestions and attached sprites. I usually programmed for an hour either before work or directly after and sent him builds to play with almost every day or at least every week. Working consistently for an hour a day on small tasks was crucial to actually getting the game finished and is a “secret” I would gladly give anyone. If you want to get things done, do at least a little each day. Before you know it, you’d have made a lot. Things in motion tend to stay in motion…



Xavier and I quickly realised that having the characters turn in different directions was not feasible. We removed an action point system that I was working on. We experimented with showing the enemies walking directions in advance. We did all sorts of things. And even though we did the right thing by prototyping like crazy one of our mistakes was the lack of direction. We experimented with all sorts of things and this was causing the design to become somewhat conflicted. The game was not sure what it wanted to be and we needed to cut out a lot of features to make the design tighter but also to make sure that the game would be finished at all…



SpriteKit & Xcode

Being an iOS Developer by trade drove me into the easy conclusion that the easiest way to get a game done was by using Apple’s own languages, frameworks and dev environment. I didn’t have much time to spend on game development so I chose to focus on what I already knew and keep the “learning” to a minimum. This made the choice of using SpriteKit as the game engine an obvious one. SpriteKit is ideal for 2D games and is super easy to work with for me, especially for the animation parts. The major drawback though, is that the game can only be released on the Appstore and nowhere else…


I use GitHub for source control both at work and at home. It lets me see my code’s history and go back and forth between versions etc and is a crucial tool in my workflow. The bare thought of only working locally makes me queasy. Don’t do it.


Both Xavier and I are great fans of pixel art and old-school games so that made the choice of style obvious. Xavier could’nt wait to make pixel art for the first time and used PyxelEdit to do it. I can’t tell you much more about his process than I already have but what I can tell you is that his work was crucial in every way. Just take a lot at the first images I posted and compare them to this trailer if you need convincing 😛

“Rogue Knight: Infested Lands” in motion…


Sounds & Music

I created the sounds super quickly using Bfxr, a handy tool for making the kind of primitive sounds our retro-styled game demanded. Intuitive and easy to use.

I studied music in school and used to play keyboards in a Reggae Band (!) among other things and I occasionally write songs of my own so it was only natural that I’d make the music myself. At first I thought about using a tracker to make Chiptunes but this turned out to be a lot more complicated than I imagined so I quickly abandoned that thought. I found a nice plugin that created 8-bit sounds for Garageband, a free program for Mac that you can use to make music and bought a small MIDI-keyboard that I could use to play the notes and release my inner Mozart. Writing the songs was not that difficult and most where actually made in a matter of minutes and I attribute that to the fact they’re quite straightforward and that I’m always hearing things in my head XD.



I did the incredibly stupid (but apparently way to common) mistake of not taking marketing seriously at all. All I wanted to do was release a game I told myself. Well, that was one of the main reasons why nobody knew about the game either. The day of release, which was arbitrarily decided and could easily have been changed, I panicked a bit and did a bunch of random things at once. I sent out an email to cause I thought that their reader base would probably be most interested in this sort of game and they had covered similar games before but got no response. I sent one to but did not get a response there either. I posted the game on and created a Twitter account without having the slightest idea of how to do marketing or anything else on that platform for that matter. I made a post about it on Reddit which is notoriously against self-promotion… In other words, our launch was catastrophic and the weird thing is that I knew it a the time it was happening. But… I didn’t know what to expect and thought that maybe things wouldn’t be that bad so I released it instantly anyway.  After all, we had just released our first game! How cool is that?!?

Our game was added to by a bot and not by us which says it all. I should have created a page there way before release day. Anyway, we got a small amount of sales from there at least. But how many sales? Not many it turns out…


Like most games, we sold more on release day and on the days surrounding it but there are some slight spikes in the end of the chart which is incidentally when I’ve become waaay more active on social media. But look at those figures. A total of 653$ in sales from the release on May 2017 to December 2018. And that’s even before Apple has taken their 30% cut!  That’s less than a dollar a day. Boy am I happy I have a full-time job as an iOS Developer :D.

screen shot 2019-01-05 at 16.48.34

Are the sales disappointing? Yes. Was I expecting more? Yes and No. It is our first game so it’s possible that expectations are way off but I’ve seen a lot of games that are “worse” (in my highly subjective opinion :D) that in all likelihood fare much better financially. Maybe if we create another game that gets better attention “Rogue Knight: Infested Lands” sales will be boosted as a side effect.



Games take longer to make than you think

The base of the game was done fairly quickly but fixing the bugs, the menus, GUI and adding some polish here and there took a lot more time. The last 20% really takes 80% of the time. So if you’re gonna build a game, start as small as you can and then make it even smaller. If you can increase the scope from there do it but don’t dream up crazy big ideas unless you want to risk burning out way to quickly. Gamedev is a marathon and not a sprint.

Release on multiple platforms if you can

We’ve had a lot of Android users showing interest and one of the most common replies we’ve gotten when we show the game is “this looks really cool. Too bad it’s not on Android”. I have a strong feeling that this game might even had made more money on Android (!) which is a rare thing for games. In any case, unless you have a really good reason NOT to release on multiple platforms, do it. You’ll broaden your audience significantly and it’s the main reason I’m gonna learn Unity.

Be extra disciplined with your time when you have little of it

Making games is extremely time consuming and unless you are unemployed, live at home with your parents or have no social life whatsoever, you won’t have time to do everything you want. Features will be cut and some things will not get the amount of polish that you believe they need and you just have to accept that. Both me and Xavier have full-time jobs and families to take care of so being overly perfectionistic or taking too long on tasks just isn’t feasible if we want to actually release anything.

Marketing is crucial and you should start doing it as soon as you can

If you want your games to be played and earn you at least a bit of pocket change you really have to take marketing seriously. Show off your game as soon as you have something worth showing and maintain a strong social media presence. DON’T just blurt out something on Facebook on the day of release without doing anything else and think this will help you in any significant way. It most probably won’t.

Testing your game on other people should not be an afterthought

I worked for 6 years as a software tester and I should know this better than most. Despite that, we were happy by just letting our significant other and some friends try out the game. Even though this is better than nothing, we should have tried to gather people for a BETA of some sort for two reasons: getting as much feedback as possible but also to build up some hype for the game. There are still some things with the game’s UI that could be improved for example…

Other random lessons

1. Getting the UI right is tricky and should be done early

2. Making scripted tutorials in an otherwise mostly random game is a pain in the ass

3. We like pixel art way more than other people do

4. Don’t get obsessed about code architecture if you want to get any work done

5. Don’t neglect code architecture if you want to keep your sanity

Last but not least: Make the best game you possibly can

I read a post by a publisher where he said that a lot of developers don’t have 100% faith in the quality of their game and that this should tell you something. I am extremely proud of the fact that me and Xavier released a game that others enjoy playing but I feel so much stronger as a developer now that my demands for the game’s reception have changed. Was it the best I could do at the moment? I don’t know. I think there’s more that could have been done but I’ll just have to take that with me for our next game…

Thanks for reading and feel free to ask any questions 🙂

// Luis










Upcoming updates for Rogue Knight

Hi friends, fans and family!

We have a slew of updates on the way for Rogue Knight, both big and small. I’ve already mentioned that the hero is getting some much needed personality with a bunch of one-liners. They serve to give the game more flavour but also as player feedback to some events in the game. But that’s far from everything we’re adding. We are also adding an option for setting the animation speed of the game for those of you who want to quicken the pace. Along with that we have a ton of grahical improvements coming your way and a really big feature that we’re working on but I’ll save that one for later… Keep your eyes peeled for more news in the coming weeks.

Thanks for playing!


Week 3: Progress slows down

Hi friends, fans and family!

Work on the prototype has been chugging along nicely and punches are flying left and right and bugs are being squashed all over the place but… the pace has slowed down somewhat in the last couple of days. I’ve been doing more parenting and more gaming than usual. You can blame a certain cowboy-themed game for that ;).

I’m going to try to finish strong but this is what’s working so far:

– multiplayer implementation is working pretty good and communication between devices has been set up

– punches can be blocked and countered etc but I have a few special cards and situations left to deal with

– work on the UI is ongoing on Xavier’s side

– i’ll be moving the prototype to Spritekit next week. Doing it in UIKit first is too inefficient

Tune in next week for more updates!