Recently I discovered an awesome podcast that discusses a variety of games, and one of the hosts actually works the business of developing them.
While you’ll need to know at least some Japanese to appreciate this, if you do it’s a great way to study up on Japanese as well as the art of game making.
You can more details about this podcast in my post here (on my blog about Japanese study).
I came across Quantum Cheeks on a fellow developer’s blog on WordPress, and decided to review it. It’s the first game from a small team of developers who are learning Unity, and the tone of my review takes that into account. The game is out for Android, iPad, and iPhone. I only played it on iPhone 6.
The concept of the game is simple – guide a hamster through a series of radioactive barrels. The controls are very simple: click anywhere on the screen to make the little thing jump out of his (her?) current barrel and hopefully into another one. Many of the barrels are in constant movement, rotation or translation along some path, and the core gameplay element of this title involves getting the timing right with respect to the barrels on screen. Each stage ends when you reach the ladder at the end of it. There are also some seeds you can collect along the way to get extra lives, similar to coins in Mario Brother.
The graphics are fairly simple but sufficient to support the gameplay. There are some little visual touches that caught my eye, like the fireflies on the first world. There was clearly a bit of effort put into this effect since their paths seem dynamic and there are different sizes of fireflies, plus a fading effect in and out. There is also a nice parallax effect with multiple layers of background, but I had to really pay attention to notice it. One minor nitpick is that the resolution of the barrels on the first world is too low and could use some refinement. The barrels on the second look pretty nice, though those on the third stage have a weird design, maybe a space ship?
Because of some issue I wasn’t able to hear sounds or music, although I think it is supposed to be there. Will update this post if I get that figured out.
My favorite thing about this game is element of shooting a hamster back and forth between barrels. It’s challenging, a little addicting, and adding the “hamster” idea gives life to what would otherwise be a dry physics simulation. I am not sure if the team plans to keep working on this game, but I think it would be interesting to expand on the concept, with more barrel types (maybe ones that explode after a single use) and more interaction with the world, for example bouncing off walls and such. Since they already have a physics engine I think some of these additions wouldn’t take that much additional development time. I also like how you can just randomly shoot in one direction and have a chance at hitting a barrel in the distance, and I think if they can foster this sort of experimental play the game could be even better.
My biggest issue with this game is the bugs or inconsistencies I saw, which I notice even more being a software developer. I’ll give a detailed list here because I think they can probably fix these in a follow up release if they like.
1) Sometimes clicking on a barrel doesn’t seem to do anything. I noticed this mostly on barrels that are rotating back and forth 180 degrees, since it requires nearly perfect timing to eject the hamster at either endpoint. I would allow ejection at any point, and if the designers really want to limit this, queue up a click and eject when a valid point is reached.
2) Sometimes a rotating barrel will start ‘twitching’ back and forth for several seconds, after which it eventually stabilizes again. Seems like something has gone awry with the physics engine here.
3) Once or twice it seems like a barrel ejected me before I touched the screen, though this is hard to reproduce.
4) There was at least one barrel (pointed up and to the right 45 degrees) which seemed to have less power than the others, so the distance the hamster was projected was unexpected.
5) At least once, I saw the game end before my character was completely off screen (on the right side). It would have gone off screen eventually, but the timing caught me off guard. This one is very minor, though.
6) I usually played the game in landscape mode, but there seems to be several issues with portrait mode which automatically triggers upon device rotation. Rather than go into all of them here, I recommend just disabling portrait altogether since it’s probably not worth the effort of supporting it.
In spite of these issues, the game is still fun to play, and I recommend you check it out. If you do, please consider giving their team feedback, since as a developer I can tell you this is one of the most important things for them (:
Link to the game’s release blog post with download links: https://rhyskucharski.wordpress.com/2015/07/04/quantum-cheeks-has-launched/comment-page-1/#comment-7
It’s been about a week since my latest game for the iPhone, Dokusen: The Art of Domination, has been released. I am planning on writing more details about how the game is doing in the App Store, but for now I’ll just say it is doing much better than my previous game based on the data from first few days.
In order to get some feedback on the game to help me improve it and future games I create, I’ve created a simple poll.
If you have a iPhone device, you can check out the iTunes page here and download it if interested. Or if you are not looking at this page on your mobile device, you can just search for “Dokusen” in the app store on your iPhone.
If you can’t or download want to download it that is fine too, but please consider taking the poll to explain why that is so.
You can also check out the game’s app preview video here.
For my latest mobile game project, I decided to spent more effort on the overall player experience, in particular the visuals and sound. After I worked out the basic gameplay rules and level design, before releasing the game I went back to put some of these finishing touches on.
For the experienced mobile game developer, these types of things are second nature, but for the hobby game developer who is still learning the ropes it can take some time to shift one’s thinking to be player-centric. These refinements also contribute to the game’s overall appearance and can result in more downloads if they are showcased in screenshots and app preview videos. Ultimately, one of the best types of marketing is a game that markets itself with appealing graphics.
In this post I’ll highlight some of the visual improvements I did, followed by some audio and sound ones.
Visual
Sound/Audio
For the app preview video, I found another high-energy song which I really liked so I used that instead of the game’s actual music. I also shut off the sound effects since I thought they would be distracting. But the visuals are all intact, so if you are interested you can check out the app preview video here.
Recently I was skimming the forums where I advertised my new puzzle game, Dokusen, and realized someone had made a comment about how they had no idea how the rules worked. I was planning on writing a post about the game’s rules anyway, but this made me decide to do it sooner rather than later.
Each stage has a different board size and shape, along with a different set of players. The types of players are as follows:
1) User player: the person playing the game, present on all board levels.
2) Inactive player: a player who begins the stage owning one or more squares. This player type does not place any more tiles with intent, but the existing tiles will spread automatically.
3) Active player: Same as an inactive player except it gets to play a new tile once each turn like the user player.
Basic game flow
1) User player plays a tile of their color in any legal square. Legal squares are defined as any square except one already owned, in other words either a black square (not owned) or one of a different color which is owned by an enemy (active or inactive player).
2) If present, one or more active players each play their color tile on any legal square. The level of skill of the active players depends on the stage.
3) All tiles that are currently on the board are then expanded or “grown” to legal spaces, if any.
4) Special effects will then take place (such on meteors on stages where they appear)
5) Back to step 1, where the user player goes again. The game ends when all the squares are taken. If the user player owns over half (50%) of the available squares, that stage is won and player proceeds to the next stage. Otherwise, it is a loss and the stage must be replayed.
The only other thing that needs to be explained is the rules for “growing”. They are actually pretty simple – a square will change ownership to whatever color is surrounding it on more sides (up, down, left, right) than any other color, excluding black. To see this in action, let’s look at the first few moves for level 5, which contains a inactive player owning four squares at the start of the level.
The user player decides to play on the topmost square, and you can see this represented by a white dot. After that, the tiles around squares of both the user player and the inactive grow and expand outwards.
Let’s talk about two squares and why they changed colors during the growing process.
1) Top left blue square above: this one was bordered by black on left and bottom, nothing above, and blue on the right (the one the user player just put down). Since black doesn’t count, the square was ‘dominated’ by blue and so it became blue.
2) Square in the middle of the board: this one was bordered on all sides by orange, so it became orange.
For the next turn, the user player (blue) decides to play on the bottom center of the board. During the growing stage, this new blue square expands to the left and right, but does not grow up. This is because there is an orange square two above it, such that the square about the newly placed square is bordered by black on the left and right, orange on the top, and blue on the bottom. Since there is a tie, the color doesn’t change.
I hope this explanation made the rules a little clearer, but if you have any questions feel free to comment on this post.
I recorded a short video of the above game which can see below. I ended up loosing, but the purpose of this post wasn’t to teach strategy. I may do another post on that later.
I perused the June 22 issue of Time today and came across an article about the mobile gaming industry. If you’ve been keeping tabs on this area you might be familiar with much of the content, but I found a few of the facts both fresh and informative.
For example, it talks about how the industry is increasing at a rapid pace, but over half of the profits are being dominated by the top 10 companies. I don’t remember thethe exact figures, but it quoted how a pretty large chunk of mobile game developers make only a few hundred dollars a month (this part was no surprise).
There was an interesting section about the popular game series Dots. I found it surprising how they were unable to have much success with in-app purchases for the first game, even though they had 40 million downloads.
To be honest, very little of it was motivating to small-time developers, but whether you are making mobile games as a hobby or a business, it’s good to understand the industry as much as possible.
For my first game on the app store, Play The Field (a casual RTS game for iPad/iPhone), I did some advertising experiments by posting in several related forums.
I think it’s important to separate the number of people who decided to click on the post title, and those who actually went ahead and downloaded the game as a result of reading the advertisement. For PTF, the latter number was pretty small so I can’t say it was a real success. However, the former number is still important since it shows how many people reading each form were interested in the game baed on the title and the fact it was an iPad/iPhone game. These view statistics will come in handy when I try to advertise another game.
Since these numbers might help out others as well, I’ll post the exact number of views I got for my advertisements on each site, ranked with highest first.
For my next game, I will very likely use the first two because of the great turnout (forums.toucharcade.com and forum.devmaster.net). The small number of views from the last site (http://www.slidedb.com) was especially surprising since there was many fields to fill out, and a 1-2 week period of waiting to be approved. All of that for a measly 5 hits!
I did achieve one minor goal, which was to not get banned from any sites. This was done simply by following all the rules for each of the forums involved. On all forums I only posted a single time, and only in the proper sub-forum.
One thing to keep in mind is that I submitted these posts over a week or two period, so some are a bit older than others. However, because I think most of the traffic comes in the first few days (when the post is near the top of the list), I think this has a minor effect on the overall hits. It would be an interesting follow-up post to check these again in a month or two.
I’ll put links to the posts below in case you want to see how I phrased things, though because of the low overall effect on downloads I think I need to work on writing more appealing, concise advertising text.
http://www.slidedb.com/games/play-the-field
http://www.gamedev.net/topic/668462-play-the-field-minimalistic-rts-game-for-ipadiphone/
http://forums.toucharcade.com/showthread.php?t=261996&highlight=play+field
http://forum.devmaster.net/t/play-the-field-minimalistic-rts-game-ipad-iphone/26744
http://www.armchairgeneral.com/forums/showthread.php?t=159587
http://iosdeveloperforums.com/forums/advertising-and-self-promotion.18/
When working on a mobile game, I typically try to stay away from playing other games. This is partially to maximize my available development time, but also to minimize introduction of elements from other games. (Though in all honesty, there is nothing really wrong with this.) However, I do try to view the apps on the Apple App Store for iPhone/iPad at least once a week to see what types of apps are popular and try to think about what made them popular.
One app I keep running across is Move The Walls (which is in this week’s “Best New Apps” in the App Store), so I thought I would write up some thoughts on it.
This app is a casual game whose gameplay is extremely simple. It’s a vertical scroller where your character moves through a narrow lane that contains walls blocking it’s path. Your goal is to swipe (or ‘flick’) left or right to remove these barriers and allow your character to proceed forward. The visuals are quite simple as well, with each level’s character, background, and walls changing according to the theme of the level. There is a driving theme with a car driving on a road, an outerspace theme with a UFO going through a mysterious place, and a boat trying to avoid what looks like sticks of frozen ice.
The app is free, but contains in-app purchases for certain levels. Even though it just came out, there is already over 600 reviews, with an average of 4.5 stars.
Herein lies the reason for my curiosity. How did a game this simple get to Apple’s “Best New App” list, and manage to get so many reviews (and surely a huge number of downloads)?
I tried playing the game myself but got bored quickly, so I decided to read some of the reviews. Interestingly, many of the 4 or 5 star reviews complain about the lack of variation in the music, insufficient difficulty, and the fact they beat the game’s free levels in an hour or two. If so, why did they give so many stars?
The reason for this amazing success starts to become more clear when I found out it was made by BeaverTap Games, who produced the 4-game series Mikey Shorts as well as another game (Radical) which had critical acclaim. Briefly looking at the screenshots of Mikey Shorts (currently $1.99), it looks like a simple Mario clone, though has the potential to be a lot of fun. This game is quoted as being listed under “App Store Best of 2012”, and also has a total of close to 1500 reviews.
Putting this all together, it seems clear that Move The Walls had alot of help from BeaverTap Games’s large fan base it built up over several years. I don’t know what level of advertising they have done, but I wouldn’t be surprised if they spent a good chunk of money on it, knowing (from experience) that it will pay off in the long run.
I have a hard time believing even if I were to write a game exactly like this, or even if I added major new features, that it would be as popular. Some might feel that being listed once on “Best New Games” doesn’t necessarily mean they are raking in the cash with in-app purchases, and we don’t actually know how many downloads they are getting, but to an indie developer, getting listed on such a high visibility place is a dream. Even if the game falls from popularity after a few weeks, being in this position gives it a great chance to be profitable at the present point in time.
I found this review of the game, which gives it 3.5 stars as a “decently fun distraction”. More interesting than the review text, however, was an embedded video of the game’s official trailer. Over half of the 30 second trailer contains live-action footage, which while clearly low budget definitely took time and money to film, edit together. It’s interesting to speculate how much this trailer contributed to the game’s success.
When I made my first iOS game, I decided I would make a proper app preview for it, since I feel it is one of the most important factors that determine whether someone decides to download it from the app store. After doing a little research about editing programs, I ended up choosing Apple’s iMovie program. The movie I ended up with was pretty simple, but good enough to show off the game’s basics.
A few weeks ago, I had a need to do some video editing for another project, and was going to try a more “proper” editor like Final Cut Pro (there is a 30 day free trial), but due to my familiarity with iMovie I ended up using it again. With my experience from the app preview, I was able to ramp up pretty quickly and do some advanced editing to splice together my film.
I had the impression that iMovie was only for basic editing, but after this project I realized it was extremely powerful. The learning curve is a bit rough initially, but you can get over it pretty fast and be editing in practically no time.
iMovie, especially for a free program, sports a surprising number of features, including transitions, titles, sound effects, independent editing of audio and video, and export to a variety of formats including Vimeo and Youtube. It also has a special mode for iOS app previews that helps you get the right filetype to Apple at submission time.
For my next iOS project (to be released shortly), I decided on using iMovie again, and in only a few hours was able to edit together something even better than my first game’s preview.
Even if you don’t have a need to create app previews for iOS games, having editing skills come in handy whenever you want to show off your game to someone else quickly, without having to actually install it on their machine. This can be great for finding investors, additional developers, or other staff to add to your project.
I’ll close with a few tips I learned using iMovie:
1) Part of the reason for the initial learning curve in iMovie is because of the way clips and movies are organized. When you first start the program, you can import clips into your library, organized by “Event”, but you have to start a new movie via File->New->Movie/Trailer/App Preview before you can actually start editing. The confusing part about the iMovie Library window is that it contains both the list of movies, plus all the clips for a certain event. If you click on a movie it will change to it, but the list of clips is global so doesn’t change.
2) iMovie doesn’t have a “Save” option which makes me uncomfortable, but if you are paranoid you can make a backup of your movie in the aforementioned library window by right clicking and clicking “Duplicate Movie”. I appreciate that the program is supposedly saving after every action, but the “Save” option would make me feel much better. It’s nice to know the undo option goes back pretty far, however.
3) In both the iMovie Library (top center) and main (bottom right) panes, you can change the clip size via the little film icon. You can also change the zoom level via a horizontal slider in the latter pane. When I use iMovie I frequently adjust these depending on what task I am working on. For example, for fine-grained editing (to sync up two scenes perfectly) I would zoom in pretty deeply.
4) A bunch of special effects can be accessed via the little icons at the top of the upper right pane (which shows the current frame). When I first used the program I had trouble finding these.
5) iOS app previews are different sizes for each device, and creating one for each device type is time consuming. You can re-scale from one size to another by creating a black image in a program like Gimp or Photoshop, and then importing it in the first frame, and making it last only 0.1 seconds. I was able to do this to scale a preview made from video recorded on a iPhone 6 to iPhone 6 Plus size, though I had to create a new project, import the black image, then cut the scenes from the iPhone 6 project to get this to work. If you actually have a physical device I would still consider recording each one separately, especially if your app/game’s UI changes significantly depending on the screen size.
I’ve been thinking about making a new mobile game and have started work on prototyping and basic implementation. I plan to post on that more in upcoming weeks but today I wanted to write some more about game development in general, especially when done as a hobby by yourself or on a small team.
If we look at software development as the practice of writing code to fit a set of detailed requirements, the set of tasks involved is relatively well defined. Define the high level implementation, including modules and how they interact, then gradually drill deeper down until you get to the function level and are writing small chunks of well-defined logic. This is no means an easy job, typically requiring knowledge of one or more technologies or languages (iOS, objective-C, etc.) and possibly third-party frameworks (i.e. Unity). Implementation itself can take a handful of people to hundreds of people anywhere from a few hours to several years, but the point I’d like to make is that you can generally see the road ahead and make gradual progress [Exception: projects that stretch the limits of technology]. Worst case, you reach a testing phase and find out your design doesn’t support an important requirement, at which point you may need to re-design the modules or some algorithm.
Now lets take a step back and look at the scenario where there is no requirements document, or any clear set of things you want to accomplish. As a hobby game developer, you might just “want to make a cool game”, “want to make a RPG like Final Fantasy”, or maybe “just make a game that becomes popular”. Note that I purposefully omitted “want to make money” since that is one of the most difficult goals for a small team.
Here what you are supposed to implement is vague, or at worst totally undefined. If you are the perfectionist type you can take the ivory-tower approach, and write pages and pages of a specification document about what you game is going to be like: the world, game mechanics, interface, etc.
But as a hobby game developer, you have limited time and being an idealist just isn’t going to cut it. The only way you are going to get anything done is by bouncing back and forth between implementation and inspiration (design) modes. This can involve building a set of prototypes, or fine tuning a more fleshed-out implementation, but you can’t avoid jumping back and forth between these two modes. This is because that whether something is fun or easy to use is very subjective and requires someone actually playing the game.
Without design there is nothing to implement, but without implementation you don’t know if what you’ve designed is actually an enjoyable game. In some cases, you may not even know if it’s possible to code in terms of technology and development time. For example, if your game involves natural-language input (like classic adventure games), you need to either develop this technology yourself or find a third-party library. If during prototyping you discover you can’t properly parse the types of language you want the user to be able to input, you might have to go back to the drawing board and re-think the game’s interface.
If you are working by yourself, you’ll have to put on even more hats during this process: visual artist, sound designer, scriptwriter, gameplay balance engineer, QA tester, etc. There is research indicating that, for the average person, multitasking like this takes a toll on productivity, so you have to fine the right granularity of work to minimize this overhead.
Personally, after many years of doing software development as a career I’ve improved my ability to implement quickly and efficiently, and much of this carries over to my hobby game development activities. But I have a great deal to learn as far as design goes, especially the tricky act of juggling the many roles of a game developer.
I’d argue that the art of smart, efficient multitasking – knowing where and how much to spend your time at any phase in the project – is one of the most important skills to learn as a hobby game developer, and one of the hardest to learn. Another one is scoping (maybe a good topic for a future post), which means determining how much stuff you want to fit in a project for a given timeline.
Note: this post was inspired by this post I just read.
Mobile Game Development 