Games I’ve Been Playing: Pocket Trains

I’m back, my people!
Playing game

Get Pocket Trains for iOS here.
Get Pocket Trains for Android here.
Or watch the gameplay video here.

Oh wow, it’s been quite some times since I posted anything here. Have no fear, I’m back now! And I also got a much longer and heavier post ready to be published. In the meanwhile, I hope this light post on the latest game I’ve been playing would whet your appetite.

Onward, then.

Choo choo!

So, what is Pocket Trains? Is it some sort of Tamagotchi game where you raise train that grows longer and longer? Well, the truth isn’t far off, because instead of raising a train, you’re managing a network of railroads that grows larger and larger.

Pocket Trains is the latest game from Nimble Bit, a game studio known for its addicting timer-based game Tiny Tower. So as you might expect, Pocket Trains is another one of their attempt at the casual, timer-based simulation genre. On Pocket Trains, you will send various trains across the world, wait for them to arrive at their destination, and then proceed to collect the reward. The reward you get can be used to grow your railroad empire by purchasing track to another city or building a new train you can use.

Despite being a timer-based game, Pocket Trains isn’t one of those games where you can advance by just mindlessly tapping stuff on the screen. For each train you have, you must manually choose which stuff the train will deliver. Since different jobs have different reward, there’s some sort of tactical aspect to the game where player must choose the best route and jobs to attain the best reward possible.

To be honest though, I still can’t decide wheter this tactical layer a bad thing or a good thing. It sure brings more depth to the game, but it also brings more complexity.


In addition to the standard delivery job, Pocket Trains also has daily events to spice things up. Every day (real life day) you will get a new random goal to deliver stuff to (or from) a certain location. I really like the addition of daily goals on this type of game. It gives a smaller goal that player can chase everyday so they won’t just play around aimless.

Speaking of aimlessness, despite the addition of daily events, progression (or the lack of it) is a major problem in Pocket Trains. Yes, your railroad empire gets bigger and you also have more trains to manage, but the game does a really poor job of conveying this growth. The railroads isn’t getting more used, the stuff you deliver stays the same, even the stations aren’t getting more crowded.

Part of the problem with the progression is the low amount of available upgrades. You can only upgrade the train fuel capacity and how much stuff it could carry. So no, you can’t make your trains go faster or use the fuel more efficient or any other upgrades you can think of. I mean, it’s called Pocket Trains for god’s sake, so why can’t I tinker with those trains?


I may have been a bit harsh on Pocket Trains on my writing here (still, Nimble Bit has shown that they can do better), but it’s still a game I’d easily recommend to anyone. Despite all its flaws, Pocket Trains is still a good game that you can easily get into when you found yourself with a tiny bit of free time. And it’s free too!

For the time being though, I’m still waiting for that Tiny Deathstar 😉


[1GAM-May] Tic Tac Head: Progress Log #2

WARNING: Some technical programming stuff ahead.
1GAM Banner

A quick spoiler before we go on, despite this being the second log, the game has been released and is working. But yes, there will be a third log, read on to find out the reasoning.

Anyway, hello people of Earth! It’s the second progress log for Tic Tac Head, my fifth entry for OneGameAMonth, a community that encourages people to create a game every month. Check out the first log here, or check out the logs for my other entries here.

As I have said in the previous log, Tic Tac Head is an online, multiplayer Tic Tac Toe game for your Android devices. It’s nothing revolutionary or ground breaking, but it’s a good exercise for learning about how to build a multiplayer game. And truth be told, I did learn all the hassles about building a multplayer experience.

So, how did my endeavour go? Did it end well?

The Game

To save you all from reading this wall of text even further, let me just say upfront that the ending is a happy one. Well, sort of 😉

Don’t rush now, let’s do this chronologically. The last time I did say that the game can already be played and the player can win or lose. So I continued from that point and built all the missing pieces like the friend list, multiple games, and even some sort of bot that player can play against. And while I was doing all that, the server app was slowly getting into shape as well.

Keep in mind that while building those features, I didn’t connect the app to the server at all. I simply simulated internet connection by having some game process running in a different thread with 1 second delay. Looking back, that was a really good decision. I managed to build an app that is structured for the internet, so I don’t need to change a lot of stuff later. Or so I thought.

So yeah, I left all the internet stuff to the last day. I spent the first part of that day setting up the connection to Google Cloud Endpoints, and fortunately, once I got it functioning, it just worked beautifully . However, the data I got from the server have a different structure from the ones I used in the app, so we spent the second part of the last day hacking things to make the game works.

In the end, with around 30 minutes to spare, we managed to get a working game where 2 players can play Tic-Tac-Toe back and forth. At that point, I simply uploaded the game and called it a day.

Account picker

The game uses a lot of interesting technologies, which unfortunately wouldn’t be written in this post. But let me highlight just one them, shown above, which is the Account Picker.

As you can see, with the Android Account Picker player can choose a Gmail account (or Hotmail) associated with the phone and use it as the login alias. The original idea behind this is that we don’t want players to create yet another account to play the game. We also don’t want to deal with the hassle of keeping another social network session and token data, so we simply use those emails as the login ID for the players.

The development is not all bright and sunny though, one thing that really annoys me is the amount of loading indicator needed to be displayed. Getting a game needs a loading indicator, waiting for opponent’s move needs an indicator, sending a move needs an indicator, etc etc. Seriously, writing “if (isLoading()) showLoading() else showGame()” all over the place really complicated the codebase, and writing to a messy source code is the total opposite of fun.

The pain of building an internet-connected game doesn’t stop at that unfortunately. There’s also the problem that being connected added various possible cases to the app that I need to anticipate. For example, I had to starting thinking abouse cases when a request failed, or when the device got disconnected, or when the request is finished but the user isn’t viewing the app.

All those cases added further to the complexity of the app, and coupled with the last minute hacking we did, it made the game codebase one hell of a mess.

Messy or not, the game works. See it in action for yourself in the Vine capture below.

So now it’s all done, where’s the game link?

Unfortunately, the game isn’t ready for public consumption yet. Like I said earlier, there are a lot of cases that I have to think about, and I haven’t tested them all. For instance, I don’t think right now (as the time this post is being written) players can receive a challenge from a player who is not stored on their player list. And I’m sure there are other non-functioning cases like this, so I decided to withhold the game until it’s fully functional.

That said, I have put the game somewhere on the internet. If you’re smart and creative enough, you should be able to find it 😉

(apparently someone already found it before I even posted this log XD)

All that is the reason why I decided to have another progress log for this game. I planned to keep working on this for a bit more since I wanted to ensure the game is fully functional before making it available to more people. That said, right now I’m aiming to clean up and refactor the whose codebase so it will be easier for me to fix stuff.

And since I left out all the technology stack used from this post, I think I’ll include that in the next log. So stay tuned, people!

[1GAM-May] Tic Tac Head: Progress Log #1

Please forgive my l33t Photoshop skillz >.<
1GAM Banner
Uh oh, we’re approaching the end of May and I haven’t written anything about my OneGameAMonth entry. Well, I’m still trying to make the deadline here, so I’ll keep this post short.

Before we go further, a quick introduction is in order. I’m participating in OneGameAMonth, a community that encourages people to create a game each month during this year. It’s May, so right now I’m working my on my fifth entry, and you can check out my games for the previous months right here.

First, let’s get the cat out of the bag. I suck at doing anything related to the internet. I can’t write a good website, all those HTTP POST GET mumbo jumbo confuses me, and I hate JavaScript. Yet, the internet is fundamental to everything these days, and even games with all those leader boards, cloud save, and social things. So I secretly wish I could get better at doing this internet stuff.

Then, around two months ago, a chance came by.

Chat Head

A chance by the name of Chat Head. Chat Head is the new interface for Facebook Messenger featuring a draggable profile image that is floating on top of the phone UI. Me and a friend of mine really liked this new interface, and during our discussion, we came to a realization that this kind of interface is a really good fit for multiplayer games. Imagine being able to easily goes into and out from a turn of Letterpress. Or Words With Friends. Or Poker.

But building Letterpress, Poker, or even Chess is a tad too big for us. We (well, at least I) don’t really have the experience to build a proper multiplayer game. So we start small. We start by building a really simple multiplayer Tic Tac Toe. That way, we would understand the underlying infrastructure of a turn-based multiplayer game which hopefully can be useful for building another multiplayer game.

We decided to postpone that plan a bit so I can use it for my May OneGameAMonth entry. We also decided that I will deal with the client stuff and he will deal with the server stuff. To be honest, I’d rather learn how to do the server codes, but eh, building that floating interface should be an interesting challenge as well. While for my friend, he hopes to be able to learn server development with Python from this project.

And here we are. So how did it go?

Well, it went… badly. Me and my friend got a bit busy this month with some school stuff so we barely wrote any code at all. Fortunately, I managed to sneak in a bit of time to work on the floating head interface (and exploring the deep end of Android app development) while my friend managed to get some Python codes running on Google App Engine.


Right now I don’t have any school work to worry about for around a week, so I managed to go full throttle on this project for the last few days. I’ve been adding more functionality like the game logic and the game interface, and I’m writing this post while in the middle of working on the game friend list. Working on apps is a bit different than working with games since I have to adhere to a lot of the operating system architecture. Fortunately, it’s still fun.

While now the game is sort of working (you can win or lose a game), I’ve been avoiding some of the more difficult issues like managing friend list or even notification. These are the issues that need to be dealt with a great amount of consideration and I don’t really have the time for that. That said, I’m positive that I can do the core functionalities of the client app in the remaining 3 days.

Meanwhile, my friend hit a snag on the server side of things. Apparently his little adventure with Python is too much for him to handle, so now he’s reverting back to Java, his usual weapon of choice. There’s also the fact that he has another school stuff coming up soon, so he’s in a bit of mess right now. With less than 3 days until the end of May, who knows if he could pull it off.

And at that cliffhanger, I’ll end this log. Stay tuned for the next post to see whether our ending is happy or not 😉

Games I’ve Been Playing: Minigore 2 Zombies

Would the “Zombies” in the title drive more readers to this blog? =p
Playing game

Get Minigore 2: Zombies for iOS here.
Or watch the gameplay video here!

Hi there, it’s been a while since I blogged about anything. Yeah, sorry about that, my schedule is kinda tight lately. But don’t worry, I’m going to be more free in the coming weeks, so hopefully I can get back to my regular blogging routine. And with that, let’s open up this comeback with another Games I’ve Been Playing post!

So, what game have I been playing lately? Well, after getting over my affair with Nimble Quest, the game that I seem to keep picking up these days is Minigore 2: Zombies. Truth be told, this game has been sitting on my iPod for quite a while now, but I only around got to play it lately (yeah, I have a habit of purchasing a game and not touching it until days later @.@).

Screenshot 1

So, what is Minigore 2: Zombies? Is it just another zombie game?

Well, it IS a zombie game, but it is also a dual-stick shooter. And I always have a soft spot in my heart for mobile dual-stick shooter. I think that genre has the perfect combination of simplicity and intensity for mobile platforms. And come on, who doesn’t like killing zombies or other monsters?

Then, how does Minigore 2 differ from other dual-stick shooters? Well, for starter, your weapon is limited by the number of ammunition that the weapon has, which means you have to keep scouring the maps for more weapons to switch to. So you need to keep your eye on the ammo indicator if you don’t want to find yourself weaponless and (later) dead. There are also some melee weapons for you to try, but unfortunately they aren’t as fun to use as the machine guns.

One other thing, and this, I think, is the best differentiator that the game has. There’s only a single currency in the game. Hurrah! No more badass weapon that can only be unlocked by purchasing some In-App Purchase. Hurrah! No more depression because you just lost and the best weapon needs to be unlocked with real money. To be honest, I think this is the reason why I keep playing the game.

And by the way, while this is a zombie game, and the game title even has the word “gore” in it, don’t think for a second that this is a scary game. It’s quite the opposite in fact, I think the visual in this game is quite charming with all that blocky looks. Sometime I wonder if blocky model is the pixel art version of 3D artworks XD

Screenshot 2

Zombies, penguins, and Russians. What else could you possibly want?

I may have lied a bit when I told you that Minigore 2 is a dual-stick shooter. In fact, the game is a lot closer to a single-stick-with-a-separate-button-for-firing shooter. Yeah, the game default setting has the Auto Aim feature turned on, so the player will automatically shoot the nearest enemy (or something like that, the aiming is a bit weird sometime) when the fire button is pressed.

Based on the decision to turn on the auto-aim by default, it is clear that the game is much more geared toward moving and positioning the character instead of plain old shooting (so, dual-stick mover?). In fact, I found my left thumb hurting a lot since I tend to press really hard on the screen, hoping the character would move faster. A lot of stuff in the game supports this focus on movement too, like having the enemy not instantly attacking when the player got in the attack range.

Making the game more about about moving rather than aiming and shooting is a really nice move on the developer’s part. It fits the touchscreen control perfectly since it reduces the amount of control the player need to worry about. Not to mention that it makes the game really simple.

Screenshot 3

One thing that surprises me the most about this game is the replayability. I have finished all 7 levels provided in the game, yet I still find myself playing the game from time to time. This is partially due to the fact that I can still progress further, namely in the weapon department, even though there’s no more new level for me. In fact, I think I only unlocked 20% of all the weapon upgrades, so there’s still long way to go for me.

Apparently separating the level/game progress with the unlockable/character progress is a good way to extract more play time from a game. Just keep in mind that it won’t work if the base gameplay isn’t fun, since I wouldn’t buy better guns if killing those zombies with better gun isn’t fun. And by the way, each level in the game can be repeated with increasing difficulty, so the game actually does still offer more challenge to overcome even after the player beat the game.

Seems like we have reached the end of my game impression, and I haven’t uttered a single complaint about the game! Wow, is Minigore 2 a flawless, perfect game? Well, it may be flawless, but it surely isn’t perfect. While the game is good and overall enjoyable, there is no high point that could make me think “Whoa, this thing is awesome!”. And I don’t think I ever find myself got really sucked into the game.

All in all, Minigore 2 is money well spent and I know it will keep me entertained for a couple more days. Well, that’s all for know, I still got zombies to kill!

[1GAM-Apr] Black Holes iOS Log

May be I should have gone with “Black Holes iLog” instead?
Black HolesWelcome to the progress log for my OneGameAMonth entry for April! As usual, it’s late, but at least it’s only late by 7 days.

You may have noticed that there’s no numbering in the post title, unlike the previous logs where I numbered my post with Log #1, Log #2, and so on. Don’t worry, that just means this log is going to cover everything I did in April, so there’s no need for a second or third log.

Wait, a single post for an entire month of work? How could that be?

Well, my entry for April is a bit unusual, you see. Instead of working on a brand new game, I simply ported one of my Android game, Black Holes, to the iOS platform. But that doesn’t mean I have it easy. In fact, I think this April entry is the one that requires the most work so far (not the most difficult work, mind you).

And since I’m just porting stuff, there isn’t a lot of design process happened. I don’t really like writing a lengthy, technical stuff either, so there isn’t really much I could write in the progress log. And with that in mind, I decided that a single log would be enough to cover the entire month.

To be honest, I’ve always wanted to have a game for Apple devices. Not because people said that’s where the money is, but because I want to know more about the iOS market, about the behavior of iOS users, about stuff that would affect my download count. And what would be a better way to learn about it other than to actually release a game on the App Store?

And since I did Black Holes purely using Android SDK, it is only fitting (or stupid?) to do Black Holes for iOS purely using iOS SDK and Objective-C as well.

Title screen on iPhone

So, how did the porting go?

Basically, I worked on it using a bottom-up approach. I started with porting a lot of the game base components, like images, file loading, and touches detection before moving to the more abstract stuff like game loop and resource management. Not surprisingly, the abstract stuff can be ported quite easily while the low-end stuff requires a bit more work (AKA googling).

Fortunately, despite the differences in both platform, I didn’t encounter anything too difficult. Two things surprise me though, one is the fact that iOS doesn’t seem to have a definite place to store game save data (whereas Android has SharedPreference). Another one is the fact that iOS has a really complete suite of audio processing. I mean, it has like 6 different classes just for handling audio.

Oh, and another thing that surprises me is the fact that file management on an Xcode project is a total nightmare. I keep having to create and recreate the project since moving stuff around often leads to things breaking down.

With all said and done, I finally managed to port the game and have it running on my iPod. I was fortunate since Black Holes is on the simple side and doesn’t utilize all the components my game framework has. Yeah, you guessed it, there are actually still tons of stuff not ported yet to iOS, most notably accelerometer input and scrollable item list.

Another major omission from the game’s (and framework’s) current state is the support for iPad. My game framework has been doing pretty well in handling multiple resolutions, but having two base resolutions is a whole different beast. And I’m not prepared for that.

Yet iOS developers have been dealing with that problem for years now. So yeah, I still need to research how other people are doing it before actually adding iPad support. Not to mention that I would need an actual iPad to test it, since the iPad simulator on Mac doesn’t seem to work for me.

Black Holes on iPhone

While I did say that the game has been successfully ported, it has not been released on the App Store yet.

As this post is written, I’m still struggling to finish up some administration stuff since I want to sell the game. I suppose I can just publish the game for free, but I kinda want to see how a paid game would fare and how the market would react when the game becomes free. After all, I did this for the sake of learning more about the market.

All in all, I’m quite satisfied with how the port turns out. Haven’t test it thoroughly yet, but so far I haven’t see any lag or memory leaks. That said, there are some rough edges since the size isn’t exactly optimized for iPhone’s resolution. But eh, I can live with that.

Oh, and speaking of which, my game and the framework it used is totally open sourced on GitHub (except for the music, that is). The plan is to have Black Holes as an example of how the framework can be used since its quite complex but still pretty simple. And since the game is also available on Android, it would easily shows how the framework can be used for multiple platforms. So yeah, feel free to check it out.

Phew, and with this, I’ve paid off all my progress log writing debt. We’re going back to our regular schedule, people!

So, what’s coming up this May? Well, you’ll have to see for yourself in the May progress log, which hopefully doesn’t take too long to be posted. Suffice to say, it would be totally different from my previous OneGameAMonth entries. This time we’re going to focus our effort on a rather unusual aspect of a game.

Wait, did I just say “we”? Indeed, for my May entry I’ll be teaming up with a friend to help me finish this massive undertaking. And when I asked for help from other people, you know it’s going to be something exciting or something big, or may be even both!

[1GAM-Mar] Grid Chaser: Final Log

This post is way overdue ~.~
One Game A MonthAnd in a crazy turn of event, I’ll be talking about my MARCH project on MAY. Yes, I know this would be totally awkward, but please bear with me.

So, Grid Chaser has been released on Google Play for quite a while now, go check it out here or just watch the gameplay video at the end of this post! As a reminder, Grid Chaser is my April entry for #OneGameAMonth where I pledge to tcreate a game every month this year. Check this page for my previous entries, or read the previous logs for Grid Chaser: #1, #2, #3.

BTW, I really liked the icon for the game =3

And as I have mentioned before, I’m sort of done with the general gameplay and have to start thinking about all the supporting elements. Elements such as tutorial, multiple level support, more levels, and such. While the weekend is still early, I decided to start working on the most crucial part, the tutorial.

Originally I intended to have some sort of interactive, step-by-step tutorial to explain how the game works. For example, when the player is about to reach the first intersection in the maze, the game will be paused until the player made a swipe to change direction. So, each time the player is about to encounter a new feature of the game, the game will be paused and a tutorial overlay will be shown.

While I was writing down the sentences for the tutorial, I noticed that the amount of sentences needed to properly explain the game is way over of my expectation. At this point I realized that this approach is a no go since the tutorial is becoming too complex for the players. Besides, I think the players wouldn’t like it when the game control is suddenly wrestled from their hands.

Wondering what to do for the tutorial, I remembered that Black Holes manages to only uses 2 sentences to explain the whole game despite being actually complex. Taking a page from that book, I understand that I need to create a safe playground where the player can do no wrong and be able to progress at their own pace. And so a plan to integrate the tutorial with the level was forming up.

Grid Chaser tutorial level

To reduce the amount of information the players need to process, I decided to have two separate tutorials levels. The first tutorial level (pictured above) is all about the basic of the game while the second one is about the chasing. On the first tutorial, I simply made the player keep going around in circle until a valid input is made. Then I applied a basic principle of “show, don’t tell” by showing that the level will be completed once all crystals are collected.

At the end of the day, I’m pretty satisfied with how I handled the tutorial for this game.

Anyway, this led us to the next problem, which is level selection. Initially I wished to have a horizontally-scrolling level selection, but since I don’t really have much time, I ended up resorting to a simple left-right arrow button to browser through the level gallery. And that’s just the user interaction, I still need to actually build the system for multiple levels, level-unlocking, and other things =/

Building the level itself is quite exhausting. While I knew what kind of stuff affects the difficulty of the level, tweaking them to have the desired experience is surprisingly difficult since I can’t quickly test the level. Not to mention that I don’t have any tile-based map system so the maze visual and the grid data is separated @.@ In the end I only came up with three levels, including the tutorials.

Title screen

The deadline is fast approaching and I suddenly realized that I didn’t have any background music for the game. Uh-oh. I browsed NoSoapRadio a bit, but I couldn’t find any music fitting for the game. So in my desperation, I turned to Google and somehow landed on this page.

A page which turns out to have a ridiculously awesome album filled with 8-bit music soundtracks. A ridiculously awesome album that cost me nothing to use.

Seriously, I’m willing to pay to listen to those musics and this guy is actually giving them for free 0.o And so I listened to all 16 soundtracks (while enjoying them in the process) and finally picked one that I find quite fitting for the game.

And with that, my game is finally complete (well, sort of). You can check out the game and the music I used from the gameplay video below.

So now the game is finished and all that, what do I think about it? While I’m not really satisfied with the game, I still think that the gameplay mechanic has some potential. I really wish that I have more time to refine the fun factor in the game, but unfortunately, there are more stuff to work on in a level-based game like building the levels and the level selection.

I suppose it’s a lesson for me that doing a level-based game is harder than it looks.

Now my entry for March has been concluded, what’s next? Usually I can’t say about what I’m going to do with 100% confidence, but this time I can say for sure about what I’m doing in April since I have actually done it. What I don’t know is whether to talk about it in the past tense or future tense =/ I suppose I’ll go with the future tense since it’s more fun that way.

Well, my April entry for #OneGameAMonth will be both new and old. I’m going to port Black Holes, my old January game, to iOS, a platform that’s totally new for me. I actually have checked out Xcode and Objective-C stuff before, but never seriously putting my effort into it. Besides, I think it’s about time that I have a taste of the iOS market, so you could say the stars are aligned for me to finally have a game for iOS =)

Anyway, let’s hope that I can get back to my regular blog posting schedule so there’s no more super late post like this ~.~

Games I’ve Been Playin: Slayin

Almost couldn’t resist naming this post “They See Me Playin, They Slayin” XD
Playing game
Get Slayin for iOS here.
Play Slayin on your browser here.

Whew, seems like it’s been forever since I wrote anything here. Granted, it’s only 3 weeks, but it still feels like a long, long time to me. So let’s open up with something light, a Games I’ve Been Playing post!

Our guest of honor for this post is Slayin, an endless arcade game for iOS with retro looks. Some days ago I promised that I’ll have the game as the topic of my next Games I’ve Been Playing series, and so, here we are.

My first encounter with Slayin is on a preview article, and I immediately knew that I have to give it a try when I saw the screenshot (pictured below). I mean, come on, it has a pixelated retro look, a fire-breathing dragon, an armored knight, and a freaking NES controller for controlling the knight. If that doesn’t scream awesomeness, I don’t know what does.

Anyway, the game finally arrived on the App store and I was really pleased to discover that it actually has a solid gameplay to pair up with the fantastic theme. Later on I found out that I can buy equipment upgrades for my knight at a shop, giving the game a hint of RPG feelings. At that point, I just fell in love with the game.

I didn’t know that I could love the game even more, but I actually did when I figured out that I can purchase a new look for the controller (just check out the controller in the last picture of this post, it seriously looks bad-ass). And when I discovered that I could turn on scanlines effect for an even more retro look, I was simply ecstatic.

Slayin screenshot dragon

The screenshot that captured my heart

Wait, let’s roll back a bit. What is Slayin? How does it play out?

Well, Slayin is some sort of an arena game where you keep fighting monsters in a closed area to increase your level and collect coins. In a way, it really is similar to Spellsword, another really nice arena game. The difference is that Slayin is an endless game, which means that as your level increases, so does the amount of more monsters thrown at you.

Their difference doesn’t stop at that, while Spellsword is a hardcore game where you have to jump around quickly and accurately, Slayin is a really simple game where your hero will automatically move and kill any enemy he hits. So it’s just a matter of changing direction and deciding when to jump. This simple control surprisingly works very well for what seemed to be a hardcore game (I mean, slaying monsters and all that sound pretty hardcore, aren’t they?).

Slayin tries to add some depth to its simple gameplay by having a shop where the players could get upgrades for their hero. I really like their implementation of this shop since it lets the players choose how they want to play the game. You want to play a tank with tons of health? Upgrade your armor so you can endure more attacks! Or may be you want to kill enemies easily? Buy a longer sword. Coupled with the medieval setting, there’s a really strong hint of RPG oozing out from this game.

And have I mentioned anything about the bosses? Once in a while, a boss will spawn in the arena which can only be killed after a few hits. And I’ve gotta say, I’m really, really impressed with the variety of bosses shown in the game. At first I thought they will be as simple as “dodge twice, then attack the opening”, but instead the game got a teleporting insect, a bouncing-and-splitting giant slime, and other crazy stuff as the bosses. Simply put, boss encounters in the game never seem to bore me.

Slayin screenshot controller

That said, the game could really use more contents. While the game features 2 more heroes that can be unlocked, the second unlockable hero plays almost the same as the default one. It would be really awesome if the player has three ways to play the game instead of two, since each hero gives the game a unique feeling.

And the lack of noticeable progress is disturbing too. Sure, we have unlockables like the heroes and a few custom controllers, but these unlockables don’t make me any better at playing. I suppose the developer wish to have a pure-skill based game, which is totally understandable, but that doesn’t mean a skill-based upgrade can’t be incorporated into the game.

With all that said though, I still loved the game. I think it manages to nail a lot of stuff perfectly even though it lacks that addictive, one more time feeling.

A little trivia, I actually came to the same conclusion ages ago when I tweeted my initial impression on Slayin XD