I'm now into week 3 of Get In The Ring's development. A friend told me the camera was a bit jerky and pointed me to this excellent article that covers anything and everything about cameras in side-scrollers. For now I've adopted the camera smoothing approach where the camera chases the player position instead of always being centered on it. It helps when the player jumps around to counter enemy attacks.
I've also been implementing a new enemy that grabs the player and leaves him (more) vulnerable to enemy attacks if he doesn't react fast. Gameplay video:
Get In The Ring is our new game, currently in the second week of development. It's a top-down brawler inspired by the combat system in the latest Batman games, coupled with the constant upgrade progression systems of games like You Must Build A Boat. It's being developed in Unity, here's the first gameplay GIF:
The game uses Unity's 2d Physics system to manage player and enemy movement and collisions, with the occasional "cheating" to move the player quickly when counter-attacking. The physics system seems to handle this quite well.
Unity also provides a TimeScale variable that makes the slow motion effects easy to do.
I've been busy porting Twitchy Thrones to Unity. The game was originally programmed in Objective-C, using XCode and the Cocos2D framework. Cocos2D is a great framework but if you want to publish your game for iPhone, Android and PC you have to use C++ and Cocos2D-X. Setting up Cocos2D-X isn't trivial and using C++, of course, implies losing comforts like automated memory management.
As for Objective-C, it's almost exclusively used by Apple and thus can't be used, as far as I know, to port a game to other platforms. This is actually a Good Thing, since it is a monolithic programming language, full of unnecessarily verbose syntax and lacking modern programming language features such as generics, real encapsulation, string operators, etc.
So I turned to Unity and C# to publish Twitchy Thrones on Android and PC. I'm finding Unity amazing, except for a few quirks. If I knew before what I know now I would have started the project in Unity to begin with.
Everything was going well, except... When the Objective-C/Cocos2D version was originally published to the App Store it occupied 17.3 MB on my iPhone. After most features were implemented in the Unity version I installed it on my iPhone expecting a similar file size. Nope. 156 MB! In these days where most games are free or freemium, a big file size can change someone's mind when it comes to downloading your game.
What follows is information I found scattered across the web to solve the problem of Unity's output file size, which I hope will be more useful gathered in one place.
As mentioned in Unity's own article about reducing file size (http://docs.unity3d.com/Manual/ReducingFilesize.html), the editor log provides a summary of the size of each of your assets after you perform a build of your project. This is what I got for mine: [quote] [font=arial]Textures 65.2 mb [/font][font=arial] 79.6% [/font] [font=arial]Meshes 0.0 kb 0.0% [/font] [font=arial]Animations 113.1 kb 0.1% [/font] [font=arial]Sounds 10.2 mb 12.5% [/font] [font=arial]Shaders 42.9 kb 0.1% [/font] [font=arial]Other Assets 543.3 kb 0.6% [/font] [font=arial]Levels 92.8 kb 0.1% [/font] [font=arial]Scripts 439.5 kb 0.5% [/font] [font=arial]Included DLLs 5.2 mb 6.4% [/font] [font=arial]File headers 99.8 kb 0.1% [/font] [font=arial]Complete size 81.9 mb 100.0% [/font]
[font=arial]Except for the theme song, all my biggest assets were textures. The problem is, while XCode uses the compressed .png images and even compresses them further with pngcrush (https://developer.apple.com/library/ios/qa/qa1795/_index.html), Unity uses the raw texture data, resulting in enormous file sizes. [/font][font=arial]In Twitchy Thrones' case, a 2D pixel art game, reducing the texture quality wasn't an option since any blurry texture stood out from the rest of the game.[/font]
[font=arial]The first solution I came across was bypassing Unity's content pipeline and loading the textures from the .png files in real time. If you change an asset's extension to .bytes, Unity treats it as binary data (http://docs.unity3d.com/Manual/class-TextAsset.html) and doesn't unpack it, thus the asset won't bloat your file size. Here's Unity's code sample from loading a texture from a .bytes file:[/font]//Load texture from diskTextAsset bindata= Resources.Load("Texture") as TextAsset;Texture2D tex = new Texture2D(1,1);tex.LoadImage(bindata.bytes); A script component was added to each GameObject containing a SpriteRenderer using the offending giant texture and on the Awake() function the texture was loaded using code very similar to the above. A sprite was then created with the texture and this sprite was set to the GameObject's SpriteRenderer. Problem solved, I thought. But when I booted the game on iPhone, a screen that took less than 1 sec to load before now took more than 10 secs! The performance of Texture.LoadImage is simply terrible.
Luckily, someone with the same problem lead to the solution, the WWW api (http://answers.unity3d.com/questions/511268/texture2dloadimage-too-slow-for-use-ios.html). The game ran perfectly on Unity's editor, but when running on iOS I got an "unsupported URL" error.
Back to Google. Most threads referring the same error warned that the URL is case sensitive and spaces need to be replaced with "%20" as with any URL, but that was not the problem. My problem was, Unity packs the assets in its own format and doesn't keep the original file structure, so the file I was trying to load in the URL didn't exist in iOS. Fortunately Unity provides a way to keep the original assets in their original form in the final build, the "StreamingAssets" folder (http://docs.unity3d.com/ScriptReference/Application-streamingAssetsPath.html).
Note that unlike "Resources" folders, which can be placed anywhere in the hierarchy of the "Assets" folder, the "StreamingAssets" folder must be placed in the root of the "Assets" folder. After placing the textures in the new folder, with their extension changed to .bytes for the reason mentioned above, I changed my GameObjects and respective scripts.
Here's one of the final GameObjects (The Sprite should be set to "None" in the SpriteRenderer):
And a link to the SpriteTextureLoader script (Sorry for not putting it here but the formatting got messed up when I tried):
A couple of notes:
The main downside of this method is that the sprites won't be visible in the Editor when the game's not running. But then again in most cases this method should only be implemented when the game is nearly done, as premature optimization is the root of all evil.
Although I haven't experimented, this method should work with other asset types, such as textures for models in a 3D game.
I chose to create a script component for each GameObject where needed, but obviously this code can be used to load all textures in a loading screen if needed.
I only changed the biggest textures so far, but right now Twitchy Thrones occupies 87 MB on my iPhone, which is 55% of the original size.
EDIT: Fixed linked SpriteTextureLoader script to work on Android.
Twitchy Thrones is the first game where I'm trying my hand at pixel art. Fold took advantage of Retina iPhone's resolution of 1136x640 by making all the art vectorial and creating resources for both hi and low resolutions. In Twitchy Thrones the pixel resolution is always 568x320, cropped to 480x320 in devices prior to iPhone 5.
Twitchy Thrones is an ultra-fast strategy game where you control knights, sending them to conquer enemy territories or defend your own. This is the first knight pixel art (2x actual size):
And this is the first knight pixel art in the first map:
I couldn't see it at first, but the knights were too small and hard to tell from the background. Eventually I went back to [s]Photoshop[/s] the drawing board (2x size):
Some time after the second attempt I found myself thinking it could look better. It still looked too small and the contours were not very defined. So came the third and latest attempt (2x size):
And a screenshot of the game at the moment on an iPhone 4s:
The map's landmarks, such as the bridges and the trees were also modified to reflect the knight's size change. Contours were also made more visible with darker colors.
What did I learn from this? Perception changes over time (duh!). A seasoned artist would be able to point the flaws in the first attempt right away, but I could only do it weeks/months later. Obviously even the art I have right now is flawed but for now I reached the point where I don't know how to significantly improve it.
My name is Ricardo Moura, Once a Bird is made of myself and my cousin. I do the programming and "art" and he does the music and sound effects.
I quit my job at the end of July but only left it mid-September. It had been making me sick for years and seemed to be going nowhere. The job consisted of programming various pieces of the back-end of a stock-broker / bank, It was well paid but I very rarely did any interesting stuff.
If you have been following this journal, you're probably wondering at this point how can this guy quit his job when all his games so far were commercial failures. If you didn't, now you know all the games we made so far were commercial failures.
The answer is, I've been working as a programmer for 12 years now and for about 5 years I've been doing games in my spare time. I consistently enjoyed making games more than programming "corporate" software. When you reach a certain point in life you realize that it's very easy to spend most of your waking hours working on stuff that you don't like (and doesn't really matter much to you) just so you can make a living (this realization probably comes earlier for most people).
Also, I realized I could survive some time with the money I saved.
So, games. Fold was our latest and best-selling game, it was released in June for iPhone and sold 1016 copies so far. If you want to take a look, the app store link: https://itunes.apple.com/pt/app/fold/id645248522
Although it didn't sell much, Fold had very positive reviews, including a glowing review by tuaw.com: http://www.tuaw.com/2013/07/13/daily-iphone-app-fold-is-the-most-original-ios-puzzler-in-years/...
In September I entered the Ludum Dare 48-hour compo alone and made Twitchy Thrones, a real-time strategy game parodying Game of Thrones. Here's a link to the post-mortem: http://www.ludumdare.com/compo/2013/09/12/twitchy-thrones-post-mortem/.
For our first full-time game, we decided to remake Twitchy Thrones for iPhone. Right now I'm doing pixel art for it:
A knight's death animation:
Thanks for reading, let us know what you think! Art critiques in particular would be very welcome. :)
Soooo....tuaw.com just called Fold "The most original iOS puzzler in years". :)
Also some other quotes:
"You've probably never played a game even remotely like this before."
[color=rgb(68,68,68)][font=Helvetica]"If you're looking for a unique puzzle experience that will undoubtedly help you pass the time on a lazy afternoon, a short break at work, or the subway, Fold is a fantastic choice."[/font][/color]
So what is Fold anyway? Fold is a puzzle game where you have blocks that collapse into each other in a chain reaction. The goal is to finish each level with just one block of each color. Right now there are 3 worlds, each world introduces a new concept.
Fold was written in Objective-C. The game is free to play, but you only have access to half the levels on each world. A single in-app purchase unlocks all the levels in the current version and all future updates.
We got the phone from the DreamBuildPlayContest, it's a spiffy Lumia 900. The interface and screen is quite nice, shame about the apps.
Graveyard Shift is on a temporary hiatus as I'm developing a phone game by myself. The game is being developed in XNA, it's almost complete and running on the Lumia. I'm going to start porting it to Objective-C soon as the plan is to release it first to iPhone and then to Windows Phone and Android.
About the game itself I can't say much because it's a simple and easily duplicable concept. What I can say is that it's an original puzzle game and I never saw anything quite like it.
So, we finished our entry on time. In the past two weeks we completed the intro sequence, the animations for when the player dies, built a new tip system and fixed a truckload of bugs.
As mentioned, we replaced last year's tutorial with a tip system. We felt the tutorial was too restrictive for experienced players who will probably guess how most of the game works on their own. The tip system works with question marks that are spread on the first two maps. The players can read these tips when they step on them or dismiss them.
The animation for when the player dies is... Well, you'll see for yourself in the game, it's not something that should be spoiled.
Even if we don't get anything else out of this, I can say contests are a great opportunity to establish goals for your project. We did work in the past two weeks that would otherwise, in our part-time work hours, easily take at least three months.
Here's the video we made for the contest, it was made in a hurry so the editing it's not that good, but...
Made a new tile upgrade that when the player steps on starts leaving behind a flame trail that damages zombies. The tile sprite is not final. Right now, the big red "X" represents a cooldown during which the player can't step on the tile again. Video here:
There are two resources to collect in Graveyard Shift: Zombie souls and experience points. Zombie souls must be collected with soul sucker tiles while experience points are dropped by zombies where they die, ala Geometry Wars.
Zombie souls are the currency used to place tiles and enchant them, while experience points help the player gain experience levels. Every time the player goes up an experience level she gets skill points with which she can upgrade her weapons and tile enchantments. Here's a video of the upgrade screens where the player spends skill points:
We added grenades to the game. Like in most games, the grenade is a powerful and scarce weapon that should only be used in tight situations, giving the player a brief respite from a nasty situation. The player will never have more than a few grenades at a time and they will be very expensive.
Instead of the right trigger, which is used to fire the other weapons, the player throws a grenade with the left trigger. The grenade is only launched when the player releases the trigger, so that it can be cooked to explode earlier than normal. If the player doesn't release the trigger in time, the grenade explodes in the player's position, dealing him just a slight amount of damage. This way the player can use a grenade to get rid of zombies crowding him.
Visually, grenades were given a red "aura" because otherwise they wouldn't be easily visible at night. Also, I used a nearly untouched stock particle effect from the Mercury Particle Engine for the explosion.
In order to maximize the "satisfaction per kill ratio" I added blood pools. The pools are made out of a maximum of 3 blood textures that are placed close to each other, rotated randomly and expanded at different rates, giving the sensation of multiple leaking wounds.