Running/flying side-scroller game for Ouya

Week 1

Hey folks. Okay so I have my Ouya console on the way, due to arrive around the end of March. So I’m working on my first game for it and I’m aiming to have the game complete and ready to launch within a couple of weeks of receiving the console e.g. mid April - ie I will probably need a short period of time to do some live testing and decide on pricing.

The game is a side-scrolling 2D platformer affair with a fairly open environment and fun control system. The player can run around and also fly and launch fireballs etc. The main gameplay entails a couple of modes, one is clearing the level of enemy waves and collecting power-ups and getting as far as you can with increasing intensity, etc the other is the competitive mode which is more of a dogfight between players (which may mix in some enemies too). It will also feature multiplayer with up to 4 players. If you ever enjoyed games like Gravity Force/Power on the Amiga or similar games you’ll have some idea of what I’m aiming for, except instead of ships with rotation/thrust (a control system that I find annoying) it’ll be animated characters with easy controls. Also the environment will be fully destructible. :slight_smile: So overall it’s kind of a free-for-all competitive arena platform shootemup kind of thing.

The environment will be constructed in an unusual but versatile manner using filled blobby objects and constructive solid geometry operations which allows me to create interesting shapes easily. Lots of stuff will be procedurally generated including the environments (at least for this first game, later I may do level editing and man-made levels). So the world will be fairly sculptural with curved surfaces, caves, tunnels etc (until you blow holes in it at least).

Here is an early screen shot of the level generator engine which constructs landscape areas using realtime rendering of blobby objects. This can actually run smoothly in HD in realtime on desktop computers but Ouya doesn’t have enough fill rate, so I use it for pre-generating a static environment which you can then modify per-pixel. The coloring/fill of the areas is just plain at the moment but will be better eventually.

The currently white areas in the image are where you can move, red/orange is solid. Eventually there will be a parallax background and proper coloring/texturing of the landscape. It’s okay for it to look ugly right now :wink:

The approach I’m taking is to split the project into phases. Phase 1 is to get the basic environment and scrolling working which is partly complete. Phase 2 is adding a player object and moving them around. I have these two phases planned out in detail with several steps each. There are about 10 phases on the horizon and I am trying to complete at least 1 phase every week - so to hold myself accountable I will be committing to uploading at least one new screen shot to this thread each week.

Since Ouya requires some free gameplay there will be at least 1 or a few levels provided for free, with 1 or 2 player gameplay, and a basic high-score table. Monetization of the project will be in the form of some kind of fun pack which I think will include 3 and 4 player support, lots of extra levels and level styles, extra characters, fun stuff like that. The jury is still out on that exactly because it’s a later phase and I want to stay focussed on short-term goal completion without getting overwhelmed. I’m trying to come up with project scope based on the timeframe rather than defining the scope and figuring out how long it will take. I think it’s important to see a release on Ouya very early in the market so I’m using that as a kind of deadline.

I decided that to make progress on this I need to get what seems like a full game working within a few phases, even if it’s placeholder graphics with no proper menus or sounds or enemies. This will take the cycle from beginning to end ie you can start a game, play it in some way, and end it quickly. Then in future phases I will polish it and add better graphics and audio and features and things to do. I think this stands a better chance of making it more compelling for me to finish it.

And I don’t have a name yet :smile:

How are you developing for Ouya, Doesnt the dev kit come out in a few months? Or are you just planning to port it over later?

https://devs.ouya.tv/developers the dev kit is available there. It was released a few weeks ago.

I don’t have a console to test on so I am just faking it until my Ouya arrives at the end of March. I haven’t looked at the dev kit much other than some of the documentation to see what the control system might entail, supporting 4 controllers etc, and how to do the in-app purchase stuff. It seems doable but the whole process of getting something ready to work on Ouya seems like a lot of technical steps still. I guess I’ll learn some things once I get down to it.

A mini progress update.

Internally, Unity will render to whatever resolution you ask for, either 1080p or 720p on Ouya. The Ouya console then either directly outputs that resolution or alters the output resolution to whatever the TV can handle. Knowing that 1080p is 1.5 times as many pixels, it may possibly be desirable to switch to 720p internally to boost performance in multiplayer modes (optionally) … so I decided to implement the ability right off the bat to support both resolutions. Mainly I’m aiming for complete smoothness on 1080p but I don’t know yet if that’s possible. On the off chance that it may not be possible, I’m happy to support 720p as well just in case it’s a problem and then at least I don’t have to modify much or anything to make the game run at that resolution. Fingers crossed through things will work fine at 1080p. If this piece of code proves troublesome it’s getting axed! You’ll be able to switch modes at any time during gameplay so if you actually have a 720p TV you can benefit from some speed boost.

I also implemented the random generation of blob positions and sizes to fill an environment. I had to figure out how much memory is available (Ouya provides ~512mb free ram at present), how much Unity would take up, etc… so came up with an environment size that’s about 6x4 screens. It might have to shrink a little if things get tight but this gives a good size to play in. I had to figure out how to transition between the a fixed virtual resolution (720p) used for generating blobs versus the actual resolution of the display and how that plays into environment size etc. A bit fiddly but I think it’s done. I would’ve liked to have really big environments but this presents a problem of too much distance between players (poor discoverability) and also all kinds of hacks and compression schemes needed to maximize memory use, which is too much time and effort to bother with right now. I think technically I could get 4x environment size given the memory constraints, but maybe that’s for a future update. Also since the environment has to be destructible this prevents the use of compressed textures.

The next step is to generate and grab-to-texture sections of the environment being generated, and then create and texture geometry to show the whole environment with scrolling. I’m also looking to make the environment wrap around horizontally which does add a bit more complexity but not too bad and this then alleviates the question of what happens when you get to and edge… the player then only has to think about the top of the sky and the base level of the ground. Saying that though, I’m not quite sure how I’ll get Unity’s physics to work when objects are straddling the edge of the environment - easy to do with fake collisions but it may need stuff to be duplicated so I’m not sure if that will hinder the wraparound option. If that’s the case I might have to consider not having proper physics and instead faking it - which would mean proper rotations of chunks of earth may be out of the question. We’ll see.

So far I crossed two steps off my list for phase 1, yay :slight_smile: Several more to go before the end of the week, including generating the physics/collider system which also has to be done procedurally to match the generated level shapes.

I have made absolutely no progress on this project since the last time I wrote. The past few days have been quite a ride.

At first I thought I was really into it. I thought that all I needed to do was get extra organized, make a plan, stick to it, follow the steps, meet the goals, do the work. So I did. I actually made a decent design document, detailed the steps, started working on it and started crossing off as as I made progress. I was being a game developer. All I had to do was continue being like that and I’d finish a game. But that’s when it started to hit me. This isn’t what I want to do, at all. My heart is not in it. My head can really talk itself into being in it easily and quickly, but the rest of me is like what? I don't want that. So I quit.

And quitting is a fantastic relief when it means acknowledging what’s in your heart and realizing that you weren’t following it’s guidance. So this is kind of a celebration. I’m not going to bother trying to make any games for money or whatever else. It isn’t my career. It isn’t my future. I think there are artistic pursuits that I need to give myself time to explore and develop which have nothing to do with making software. I’ve been hitting myself over the head with this whole make a game, get rich thing for years. I’m not meant to. So I hereby stop.

If it’s a toolkit you download, how can Unity compile your game for the Ouya?

The Ouya is an android console that pretty much runs Android Jellybean. So pretty much you just need the Android basic or Pro addon for unity in addition to their ODK. The ODK just has a few hooks that makes it work with the Ouya. (Controllers, In App Puichases, etc.). Unity Just compiles it to an .APK and you can play it on the OUYA.

Oh. I know it ran Android, just didn’t know it was that simple. Thanks.

Hey, No problem!