Rogue Sweeper – a post Global Game Jam entry release

rogue_sweeper_logo2014 has been a busy year! I moved to a new town, got back in the industry at a local company (Mobility Games) and worked my ars off on getting a good multiplayer version for Mutant Gangland. Now that 2014 came to pass I was left with 365-ish more days to look forward to. Lucky for me  2015 started out in force, as Bucharest held it’s first ever Global Game Jam. And I was there to get a piece of it’s glory!


GGJ2015 took place between 23 and 25th of January. It was cozy, comfy and there was a lot of coffee to go around. After 30+ hours of work I finished a small game that tried to blend a Roguelike with Minesweeper. It got voted as a runner up by the people attending. Fast forward a bit and here we are today, with me releasing the post-jam version of that game, now titled “Rogue Sweeper”. Here’s what I said about the game on itch:

RogueSweeper is a mashup between a roguelike and a minesweeper game. Tap to reveal tiles, monsters, traps or items. Tap (or click) your way to the bottom of the infinite dungeon. How far can you go?

The game has a level scaling system that requires you to manage your XP. Will you buy that health potion and lose your current level or will you risk tapping on that monster?

Stats (Str and Evasion) scale with your level. Note that you can lose your current level by spending XP in the shop. Combat happens by tapping on an enemy. Destroying a monster will award you with food and maybe a free item!


  • 5 items that can heal, feed, reveal the map and enemies and increase your stats,
  • 8 enemies
  • In-Game shop that allows you to buy items with your XP
  • Generated dungeons with items, monsters and traps
  • No end in sight! Delve deeper and deeper
  • Available for Windows and Android

You can check it out here. It’s available for Linux, Windows and Android for only 1.30€ (equivalent of a beer in Romania).

One month tablet challenge – first few days


I moved to Iasi city a bit over two months ago and ever since I got here I saw how different the life style is from Bucharest. Iasi is situated between mountains and hills, with green lush forests and vegetation all around, lots of open space and alot of people biking all over the place. Since I arrived I wanted to take my laptop and explore the city, writing code one coffee shop at a time, but my first experienced ended with me skipping 3-4 shops that didn’t have a plug I could use.

A few months ago I stumbled upon  Henri Beirgius’s blog and noticed an interesting article about doing development on an Android Tablet which peaked my interest. The thought of being able to work from anywhere without a wall-plug nearby coupled with great portability and hardware cost is hard to ignore. Knowing that my old laptop is ready to give up at any moment I had to take a decision and so I ended up ordering a 9.75” Android Tablet and a bluetooth keyboard. And so begins my one month tablet only challenge / experiment.

As for why I would love for this experiment to work out, well here are my primary reasons:

  • to replace my old dying laptop with a more portable solution with a heftier battery life
  • to eliminate downtime’s during my work process (instant-on, full screen windows, no more 5m+ of building the android version every time I want to test on a device)
  • to establish heavier limits than usual on my design and development process in order to be able to create/design something different then my usual projects
    • as a side point, being confined within the limits of an android tablet (in terms of power, screen space, input, performance) should “train” me to optimize my code and design a more touch friendly experience

First 4 days

One of the first things I did once the keyboard arrived was to take a seat on Mobility Game’s comfy couch and access “the cloud”. I’ve already setup my home FTP and SSH server and all that was left was to create a script that would build my project and move it somewhere that I could download it from. About half an hour later I detached my tmux session, closed the lid on the tablet and left to grab something to eat in a diner not far from the office. I was anxious to get there as fast as I could so I could check on the build progress. Being able to close the tablet and not loose any progress that was happening in the background was something new for me. Sure enough once I took a seat at the table and ssh into my server I noticed a tablet_moai.apk file waiting patiently in the /home/zapa/builds folder. I started Quoda and wrote my first “hello world” on the tablet to see if my app was working properly and gleamed with excitement once it did.

The following two days were spent trying to adapt to vim and learning the key shortcuts. The biggest challenges I faced were due to the way Android handles the ESCape key (it minimizes the app that’s currently on screen) and battling with the SHIFT key position on my keyboard (kept pressing it instead of the A key). I’m also using custom vim settings that came with TerminalIDE, something that rendered most of the tutorials obsolete. I ended up using vim for a little while but decided to return to Quoda as a local IDE, while relying on Nano (with some custom .nanorc edits to enable syntax highlighting) for server-side editing (mostly java).

Yesterday however was the first time I did any real development and work on the tablet, after I left the office (’round 6:45 PM). I stopped at a local pub to grab a few beers and prepare a powerpoint presentation for DesignJam. After scribbling down a few ideas and points in writely I opened up Quoda and patched a few bugs in Mutant Gangland’s editor and then pushed the fixes to my ftp server (git integration isn’t complete on my side). I’m still amazed that I can actually get real work done on this thing with little sacrifice. My biggest problem right now is debugging since I do not have access to a console alongside my app. The way I debug at this point is via VNC to check error messages in the console or via a .txt file dump from within the app. It’s not a streamlined experience and so far it’s been the biggest hinder for my productivity. I’m planning to tackle this problem by either adding in my own “console” overlay in which I catch and print errors or b) by rooting my tablet and finding a way to execute apps via “terminal”, though the second part is still something I have yet to research. It’s a bumpy ride overall but with lots of sweets spots, great views and good “fuel consumption”.

Before I left I did one final push to the FTP and set my machine to build. I detached Tmux, packed my tablet and took a long walk home through Iasi alongside a co-worker who gladly payed for the drinks we had. Once home I launched the new build to see if it works and then I hit the sack, letting the tablet charge. I think we both needed the rest :).

The Setup


  • A vonino Spirit QS Android Tablet
    • OS: 4.2.1
    • 2 GB Ram
    • 16gb Storage
    • Quad Core
    • 1024 x 768 resolution
  • A Rapoo Ultraslim E6300 Black Keyboard
    • Bluetooth
    • 10m connection distance
    • 1 month of battery power with only a 2h charge
    • 20 cm x 1.27 cm x 8.128 cm ( 8.1 x 0.5 x 3.2 inches for you lovely people on the other side of the ocean)
  • A 5GB monthly (grandfather) data plan from Orange
  • A HAMA tablet cover and stand 108278

Total cost? 246 euros + 25 monthly


The Software

  • Local development (on the tablet)
  • Cloud development (on my home server)
    • TerminalIDE: for ssh access to my home computer
      • ssh
      • tmux
      • vim
    • FTP Cafe: to upload/download new builds from my server

Total cost? 10 euros


The Process

From what I saw on Bergie’s post he mostly works in the cloud with little offline work, especially since he’s (from my understanding) mostly doing web development. Going for Game Dev complicates things a bit. I could have gone the C/C++ route with the amazing C4Droid (plus it’s SDL bindings) but compilation times would have nullified the experience I’m trying to achieve. So I went back in my comfort zone and built an android app using my Chaurus Framework. The app itself is nothing but a main file that searches for a folder on the /sdcard and includes “game.lua”. From there on it’s free (game), with not many things changing in my workflow. Building and debugging for Android is an entire different beast to tackle. If I want to make changes to my “main app” I have to ssh over to my server, vim my way through the project’s source, build and then download the app via FTP. Luckily wifi is abundant in my country (and all through-out Europe) and, just in case, I can fall back to my 4G data plan.

Total cost? Building MOAI for Android + 0.01c monthly




[Post Mortem]: Copulus – the love making, weight lifting god game


Copulus is a 2D God Game in which you have to help your subjects populate their little world. In order to achieve this you need to balance their need for social interaction (and copulation) with the need to survive. I decided to try and stream line the “god game” mechanics and let the player focus on only a few tasks, as opposed to regular god games where you have to manage many different needs (housing, hunger, peril, happiness, loyalty, security, etc). In order for your population to survive and expand you only need to make sure they are feed, safe and can interact with each other. I even took this approach a bit further and merged survival/peril with hunger satisfaction. Before I go into the, regular, What went Right, What went Wrong topic I would like to present my approach for this entry:

Limitations breed creativity

Before the theme was announced I already established how far I can stretch things. I know from previous experiences how hard it is to stay on track of the initial design and how many features end up being thrown away in order to finish “something” before the time runs out. So for this edition of Ludumdare, I’d like to say I came prepared. Here are my, self-imposed, limitations:

  • 256×384 resolution (upscaled to 512×768)
  • must involve some kind of an AI
  • must be tile based.

Three rules in total. Three rules that, once the theme was announced, helped me establish a clear goal. For example, the small resolution and tile-based approach helped me establish the art style, level and user interface design. Working on a 256×384 screen I could only fit 8 / 12 tiles (32×32) on the screen, or 16/24 tiles at 16×16 pixels each. The AI requirement weighted in favor of the strategy genre and, it’s subclass, the god game genre.

From here on, I went with the entire map being confined to a single screen (in order to have a good view of your population, and not have to hunt for them everywhere). This also affected my User Interface Design and Experience, since It had to take as little screen space as possible. Little screen space for UI implied having only a handful of buttons during game play which, combined with the god-game thematic, had me limit what tasks the player could focus on. A small amount of tasks for the player to perform required me to streamline the entire “god game” approach and make it as minimalistic as possible (the soul experience as I like to refer to it). You can see how things developed further on.


What went right

  • Using a WIKI to plan ahead. Features, classes, how the AI should perform, etc [click here for a screenshot of the wiki].
  • Not stretching further than I can and imposing strict limits.
  • Making fake-screenshots(mockups) before beginning development so I can plan my interaction approach.
  • Using tools and frameworks that I was familiar with.
  • Selecting a limited color palette to work with.
  • The UI only interaction means that I can also port the game to tablets.
  • Using “procedural” generation to save time (from level design) and focus on other areas.
  • Nailed the risk-reward motif due to Wolves acting as a source of food but also damage to the units.

What went wrong

  • My innate lack of knowledge when it comes to composing and/or generating appropriate sound effects.
  • Having to remove the “convergence” scene. After winning a level, the player was supposed to reach a new world with his highest level followers and watch them fight off the inhabitants. I regret removing because it would have had a better tie in with this jam’s theme. Further more, I had a system which allowed the player to revisit worlds that have been previously populated, to see how they are doing.
  • The game’s balance is a bit off. Level progression of your followers vs level progression of the wolves is tipped in favor of your followers for the first few levels. A few wolf summons in and you can only take them on if you have a high level character that survived.
  • Social interactions are only represented by heart animations on individuals, but it’s hard to tell who “copulated” with whom. More so, a death of a birth of an individual is represented by their respective sprite disappearing from the game.
  • Health, hunger and level indicators are way to small and crammed into a unit’s sprite.
  • The tutorial is just a image and does not convey all the information needed.



I feel that with each Ludumdare event I partake in I can quantify my progress as a Designer. My first entry required the player to quit the game in order to restart the level and featured only mechanics but no clear goal (also no Ui of any kind). In my last LD (7DRTS) attempt I finally had a entry with no missing UI options and a clear navigation path. You can see where I’m going with this. But all in all, I’m glad that with each submission I end up acquiring new knowledge. As far as limitations go I believe that it’s better to know what you should not do as opposed to not knowing what to do. Hopefully my next LD submission will blow this one out of the water.

You can play and rate the game here. Linux, Mac and, hopefully, Android coming tonight. I’ve also uploaded it to and, in the weekend, will release a post-compo version that has sound and the features that were cut off.

Alpha 2 Technical Status Report #1


I know most of you want to see the latest juicy pixelicious art that Thomas has been doing for the game but guess what? This is a technical report (the first in a series of status reports) and none of that will be featured here! Instead let’s talk on where the game is at this point, what can you do with it and more importantly, what can it do for you? Let’s get right on that shall we:



  • Commanders-type units have been added in the game
  • Early keyboard-only support for playing the game
  • Improved modding support
  • Unit creation and editing has not been externalized from the code
  • New healthbars for the units to represent exactly how much life they have
  • Added scrollbars and tousch scrolling for some UI elements (buy menu, victory screen)

Removed content:

  • Unit abilities has been removed from the game


  • Random map scroll at the start of the match happens no more
  • Game starts in either fullscreen or window mode, based on the option ticked in the options menu
  • Icons and Effects now position themselves correctly when zoomed in
  • Player can no longer interact with the map/units/buildings during the AI’s turn
  • Exiting the game to the editor now brings back the latest map you were editing
  • OK/Cancel/Save now work in the editor
  • Going from scrolling to Colision+/- now works as intended
  • Fixed startup crash on Linux due to missing 64b binary

Now to go into detail about the changes and additions (I believe fixes are self explanatory).


commanding_unitsFirst thing I’ll be covering is the addition of commanders as playable units.

Up till this point commanders (or, as Thomas likes to call ‘em, GangBosses) were used only as “profiles” for the player, affecting how much damage a unit will receive/inflict or how much income is generated each turn. From this point on commanders will take a much bigger role in the battle as actual playable units present on the battlefield. At any point in time during a battle a player will only be able to have only one commander present. A commander boosts the stat of his units (albeit less then in the previous version) and has access to abilities. Once killed the stat boosts will be removed. The list of abilities that a commander has access to has not be defined yet but I can give some examples such as:

  • Attacking twice during one turn
  • Doing Area of Effect damage
  • Healing friendly units
  • Capturing building/houses (like scouts)
  • Sacrificing a friendly unit for a damage boost
  • Sacrifice it’s own HP to boost movement / attack for friendly units in range


Unit creation and editing has not been externalized from the code.

In alpha 1 if anyone planned to add new units to the game or change their settings they would have had to dive in the code and make changes to: unit_type.lua, buy_menu.lua and leditor.lua. From this point on units are loaded from external CSV files: mutants.csv and robots.csv. they look something like this:

csv_imgIn the said file you can define their stats, their image, abilities, if they can capture buildings, how much they cost, their animation states, their graphics/icons for the buy menu and sound files. Adding a new unit into the game is as simple as adding another entry in the file (example: Joe, Allen, ZapaTard, Crystal, ISN). I believe that this opens up new possibilities for modders and/or people who plan on using the game’s source for their own TBS game (more on this on the end of the post).

Improved modding support.

In the game’s root directory there is a game called MODS. In there you can place your own folder (example: “Advance Wars”). If you copy the contents of the Game folder into your own folder you can start modding the game. Files present in yourModFolder take precedent over files in /Game (if your mod is enabled). What this means is that now you can change the game and distribute your changes without altering the main game. Now, by default when starting the game it will run the native version. To enable a mod you need to edit game.lua and add the mod name on line 3 for the variable Game.modInUse = “yourModNameHere”. If the varaible is set to nil then no mods will be ran. In the future I plan on releasing a launcher for the game which will allow you to select what mods you want to use (amongst settings and other useful options). For those interested in how this is handled code-wise things are pretty simple. All the lua files I want to use are added to a table called includeList. I loop over that table and check to see if any of those files are present in the current enabled mod. If they aren’t the game defaults to those in the /Game folder. Here’s the code:

for i,v in ipairs(includeList) do

    local prePath = “mods.”..Game.modInUse..”.”

    if isModuleAvailable(“”..prePath..””..v..””) == false then
        prePath = “Game.”



New healthbars for the units to represent exactly how much life they have.

In alpha 1 we’ve received complaints regarding the healtbars. Players found that they couldn’t really tell how much health a unit has and how much damage he will take in a battle. Our solution to this problem is this:

healthbars_unitsEach dot on the healthbar represents one point of health. No more dots = 0 health = unit is dead. No more calculations, no more approximations. When you select a unit you will be able to see how much damage it will inflict to units that can be attacked in his range. Can you unit destroy the enemy? The healthbar will reflect that and will display no more dots. Hope this solves some headache’s and makes things go smoothly.

Early keyboard-only support for playing the game

By keyboard support I mean playing the game without the aid of a mouse/touch screen. A cursor/pointer is used to interact with the objects/units and it can be moved using WASD/Arrow Keys. Pressing space selects the unit/building underneath it and/or confirms movements or attack. This can also allow for the addition of gamepad support in the future. Now I say early keyboard support because things are not so peachy. The main problem with it falls down on UI navigation. In order to setup the user interface I’m using MOAIGUI a library for lua and MOAI that handles the creation of windows and ui elements (textboxes, buttons, images, etc), a library that was designed with mouse/finger input in mind. What I’m doing in order to use it via keyboard is to access the ui elements position via code and move a “virtual mouse” over them, basically emulating mouse countrol on the ui. It’s barely functional at this point and currently requires me to setup each window independently. The code is a tad messy but I’m working on it. Hopefully it will be ready in time for the next alpha release.


That’s it with the most important changes added into the game. Next I’ll want to cover some other game-related subjects. First of all we’re aiming to release alpha 2 in June (aiming for early June but you know how things go… might even be July). Now the next alpha will feature new Maps (older ones will be available for download separately) and 4 playable commanders (as units) and early campaign support.

Next we’re working on setting up a development blog to keep you up to date. Due to personal issues on my side ( mother has cancer and I’ve been on the road a lot because of that) development has gone a tad slow and many have wondered what’s happening with the game. By setting up a dev blog both me and Thomas can offer more transparency on how development progresses. Expect status reports (such as this one), technical stuff (implementing the AI and other fun things ^_^) and, of course, lots of screenshots and ART assets from Thomas Noppers. With a bit of luck we could even get (here I mean strong-arm) Grace to showoff some cool sound stuff. Blog should go up sometime this week.

osi_licenseThird thing I’d like to cover is the source code for the game. Up till this point I licensed it as free for non-commercial use, meaning that you are free to use the code for personal projects as long as you get no revenue out of it. Well I’ve been thinking about this and would like to change things. As of the next commit on Github I’ll be changing the license to MIT. What this means is that you are free to fork the code, change it, distribute it for free and commercial purposes. Just don’t distribute the code with any of the assets from the game (sound files or graphical images). With the way recent changes to the game are going I’m getting close to having Mutant Gangland’s code work as a engine for TBS games. I’m pretty sure that a few months down the road game-orientated contents will be truly separated from the actual code and will be usable to create other different turn based strategy games.

The game’s source is available on github. I recently setup a new branch “development”. Hoping to push updates every week, starting now, into the “development branch” while master will contain stable releases. Currently both branches are a mess. The most stable version should be this one. I’m a git newbie and I overlooked some stuff, but things will get cleaned up. In the meanwhile feel free to fork the source and/or submit issues. I’d love to see my repro getting some activity.

And that’s it for now. Keep an eye out on our twitter (@Zapakitul, @Thomas Noppers, @Mutant Gangland) or this blog for information when the blog goes up. And if you would like to buy the game you can do so here. Plan on using the code for your openAdvanceWars project or TBS-GOTY-2014? Drop me a line, I would love to help out. Also remember there’s a subreddit for the game available. Or you know what? Drop us a love letter at info [at] mutantgangland [dot] com.



Road to alpha 2 and streaming


Hi everyone, a quick update to keep everyone on track with development. Recently I started streaming my side of development on Mutant Gangland via twitch. The reason I’m doing this is simple:

  • Early access buyers get to see how things are going in-between releases
  • New people could follow development and decide whether they want to get in on the action

I’ve released a new website regarding my streams. In the future I hope to release articles and document the streams (as in, what happened during X stream, where I implemented what) hoping it might be useful to others.

As for development updates, here’s were we stand:

  • Commanders have been coded in the game. From now on, they will not act just as profiles with strengths and bonuses but as playable characters (and main characters during the campaign).
  • Mods are in. Now in order to mod/change the game the players can place their mod files inside a /Mods folder. For example you can create a media folder and place the image you want to use for the Tank, or change the way the AI works. Later on I plan on creating a launcher from where you can select what mod to use.
  • I moved my main development environment to Linux in order to better support linux users. Previously I was mainly developing the game on Windows but problems with the Linux version have risen. Since the game’s logic is in lua working on the main mechanics will not be affected. The Windows host works pretty well I decided that I can take some time to get the Linux version working nicely, and what better way to do this then actually working in that environment. I’ve also rolled a new SDL host (based on the one made available by the guys from Stirfire studios) so this should solve some other issues people have been having with the Glut host. For alpha 2, the SDL host could be an optional download and starting with alpha 3 it will replace the standard one.
  • Keyboard support for the game has been added. Some minor issues with navigating through the menus only with the keyboard, but I’m working on fixing this. As soon as that passes I’ll add support for gamepads in order for people to play the game connected to their tv.
  • Halfnelson (MOAI user and developer) released a wonderful tool that allows me to build a web (HTML5) host for the game. I plan on using it to during streams, so people can play the latest build, and maybe during FeedbackFriday on reddit.

Thomas has been present both at GDC and at Rezzed this month showcasing Mutant Gangland and Penarium (a wonderful little platformer made with the guys from Self Made Miracle). You can read his thoughts on how GDC went over on his blog. For now, this is were we stand. I’m announcing every stream on twitter but you can also follow me on twitch and get notifications on what time it goes live.

Coding with the aid of MOAI and what it means to me


Before I get into depths with the article/post itself I would like to make one thing clear: I am a bad, bad, BAD programmer. Most of the stuff that I implement is based on many iterations and hacks that, in the end, somehow get tied together nicely and function (almost) properly.

In my last article I stated that I started out making games back in 06-07 on the TGC forums, using DarkBasic and later with DarkGDK. This statement is important to this topic mostly due to the fact that I “grew up” with a code editor in front of my nose and not a visual tool, fact that influenced my decision to use MOAI. Back in the early days, DarkBasic was the closest thing to magic that I ever encountered. With just a few lines of code I could get a “game” up in minutes (and by game I mean interactive thingy with cubes moving ’round) and share it with everyone who had eyes to see my “masterpiece” (which I did, having posted 3 projects on the WIP section in 2 months). It had literary no visual tool there to help you with anything and I never bothered (nor had the knowledge) to make one myself. And I liked it, made me feel more in control. Later on I moved to DarkGDK which was the C++ flavor of DarkBasic, in order to learn the language “most-used in the industry back then”. Again, same thing, visual studio was my one and only tool. Now, 8 years later I still feel most at home in an environment that places a textbox with syntax highlighting in front of me.

I tried using using Unity 3D (even acquired a license at one point) only to get scared by interface not 10 minutes after first opening it up. It reminded me of Blender’s UI and I wanted nothing to do with it. With DarkGDK reaching it’s limits (and mine) in terms what I could do with it without something going hay-wire unexpectedly and crashing the whole damn thing I was in search of another framework to use. As stated, I’m a bad coder and writing my own from the ground up would mean loosing allot of time and ending up with a square for a wheel. I searched for a framework that would be high-level enough for me to string together a prototype in little time while also giving me access under the hood. And this where MOAI hits the nail on the head. Continue reading

Looking back on 2013 and plans for 2014

So I’m officially 1 year in as a wanna-be Indie Developer (since I have yet to release my game). It’s a tough ride governed by many decisions and mistakes. I’d like to take the time and share my experience after this first year. Hopefully it will be useful for people starting out or a good read for those without content to consume after the New Year’s party.

Going Indie

Doesn’t seem like a hard thing. To be honest, it looks allot like pledging to participate in a ludumdare event. No formalities, no signatures, no contracts and NDA’s. For me it’s more like a state of mind which translates to “Now I can be in full control of my projects and do what I want”. Another way to put it would be like having a cigarette smoker (like myself) saying “Today, I will quit smoking”. It’s easy to say, easy to get into that mental state but it’s hard to keep at it. Most people advice to not take the plunge until you have enough money to sustain yourself for at least 1 year. I think that’s a good, sane idea. I did not listen to it but that’s because I took another approach.

Moving back to my hometown

Sometime in December 2012 I moved back to my hometown after quitting my job at @Gameloft. My mother’s illness really progressed and I was expecting the worse. I proceeded to finish my last year of University/College by commuting to Bucharest almost daily. Thankfully things have gotten better for her since then but she’s not out of the woods. After I finished college I was faced with a huge problem: My funds we’re bellow 0, commuting daily burning all my savings and my folks we’re in the same boat. I couldn’t afford to move back to Bucharest and search for a job (renting an apartment there is expensive for Romanian Standards and you have to pay at least two months in advance) so I decided to make the best of it.

The bright side of things

The idea was to try out the indie life, make a game, release it and see if I can in any way afford to live off of it. My goal was simple: Make enough money from my first release in order to afford to buy a pack of cigars daily for one month, and two beers each weekend. The total sum amounts to: 105 euros. If I could reach this goal then there might by a chance of being able to turn this into a viable business.

By moving back home I don’t have to worry about paying rent each month, nor having to buy food or pay for transportation, which allowed me to focus on one project full time with no other distractions. Living in Romania also provides a huge advantage as, compared to other countries, the cost of living is relatively small and I can get away with earnings that otherwise would be considered less than sufficient in other places.

The project – Mutant Gangland -

Last July I took part in the Mini-LD hosted by @sorceress, #7DRTS challenge. I wanted to go head to heads with a friend of mine and ex co-worker @Radu Chivu. In the end we both took part but only for two days. I ended up with a messy and sluggy tbs which I dubbed Mini Wars. I was heavily disappointed in my creation and set up to remake it (more details on that here). First rule of order was to fix the broken pathfinding implementation I used and design a proper AI.

With a bit of luck I manage to get @Thomas Nopper’s attention and enlist him to help me out with the graphical assets of the game. Over the course of 6 months Thomas waved (and keeps on waving) his magic wand at the screen and kept on producing new graphics and sprites for the game, while I kept tuning, balancing and polishing the game. Looking back on it, things have changed quite a bit:

Continue reading