The big news is Pig Eat Ball is coming to Nintendo Switch!
Yes, along with PS4 and Xbox One, you will get to play the biggest, weirdest, craziest action-adventure game on any console you want! (Okay, not Ouya, but hey, we got the big 3 :)
FEAST your eyes on the Nintendo Switch gameplay reveal trailer for Pig Eat Ball!
We don't have a release date yet, but are working hard to secure it.
What stands in it's way?
Console testing!
Yes, for all 3 consoles, there are rigorous in-house testing and requirements set for all games.
The great news is--we have passed Microsoft Xbox One certification!
That means it's ready to go.
But before we can set a date, we want to get PS4 and Switch tests done as well.
Certification Agitation
Both Nintendo and Sony have issues with the game.
Like what issues you make ask? Crashes? Bugs? Level design problems?
Heavens no, it's silly little things, but hey, fixing these details will make a more polished game for you in the end.
For instance, for the PS4 version, when allowing you to remap the controller buttons, we didn't correctly refer to the X button as the "Cross" button.
And for Nintendo Switch, when the game tries to log your score to the global Leaderboards, if it can't connect to the internet, instead of our simple message telling you there's not internet connection, we are supposed to display the specific Nintendo error code telling you, that you can't connect.
But the BEST had to be when we found out we had unregistered UGC. As in "User Generated Content". Now keep in mind, we don't have the level editor on the console version. That's only available in the Steam version. So how was anyone able to "make" anything on the console versions? LEADERBOARD NAMES! Yes, because we have global leaderboards for each level, and because you have a username that gets shown, this is now technically "User Generated Content" in 2019.
So yeah, it's stuff like that!
So we're fixing it all, which takes some time, and then sending it back into review takes a lot more time.
In the meantime, enjoy how cool Pig Eat Ball looks on a real Switch!
Summer Vacation
But fret not!
We are very, very close and have hope to secure a release date soon!
The Ouya game console officially launches June 4th, but has already been sending out Kickstarter backer versions. The game store itself is live. I've had a dev kit console for some time and have been working on an original game for it called Pig Eat Ball. I'm interested in this console, am making a game for it, and want it to do well. It's a low cost console, but doesn't need to come off as cheap. What can make it look cheap and neglected? Quick ports.
Let's turn those shoddy port faces upside down.
Obviously since the Ouya is Android-based many developers have ported their existing games from mobile over to the Ouya. This is fine and many of these games are very polished likeKnightmare Tower, Beast Boxing Turbo, and Gun Slugs.
After playing lots of games currently on the Ouya store, I've been seeing a trend in which a few irksome issues keep cropping up. Here is a simple checklist for developers to consider before releasing games to console. This in general could apply to all mobile-to-console, but I'm specifically thinking of the Ouya (could be for GameStick, others too).
Analog controller sticks require a dead zone. Many, many, many games I've played on the Ouya store have a 'drift' in their controls. It's extremely annoying, especially considering most games on the system currently are action games requiring precision input.
It usually manifests by tapping the left analog stick to move, and after releasing the stick, the character/cursor/etc continues to move in that same direction.
This is easy to fix--in the code, when you get the X,Y back from the left analog stick, measure the distance of this vector and if it's less than a certain amount, disregard the stick press.
I'm pretty sure there's even example code on the Ouya dev site, but I'll present some here just in case.
The float returned from the stickMag function will tell you the length of the vector made by the left stick input. It should be between 0 and 1.0f. The Ouya controllers are pretty gummy, so try making the dead zone fairly large like 0.35f. That is, all input lower than 0.35 in length is ignored.
Make a selected menu option >>obviously<< different from the other options. Being presented with two options such as an in-game store "Buy" "Cancel" and seeing one yellow and one white is not helpful. Some games will say yellow is the selection and some will say white. Simple color coding is not intuitive and it's easy to fix.
Quick--save her! But do you have the right one selected?
There are many simple ways to show something is the current menu option that is selected.
Consider:
Drastically increase the size of the text.
Put a special background behind the selected text
Put a special pointer graphic off to the left
Pulse the scale of the selected text
Put some simple particle effects on the selected text
Support both analog stick and d-pad input for character movement and menus.
Especially on menus but also in the game. It's just common courtesy to
allow for input for both. Some people like to play with the left stick
and some like the dpad. I've played games that for some reason only
allow d-pad input on the menus. I've also seen games that would work
fine with d-pad in the game, but only allow the left analog stick on
menus (in games where the choice of stick/d-pad really didn't matter.
Yes I understand it's possible it could important in a game, but it's
very common that the game would be fine with either input).
Remove mentions of touch/mobile controls. Seeing things like "Tap the screen to continue" or "Press here to continue" when that function is not supported anymore in your game looks rushed and sloppy. Remove all "tap", "swipe" terminology from your game unless it's actually using the mini-touch-pad as the only input.
Please don't make us do this.
Even if it *is* supported to allow the player to tap a portion of the screen to continue on a menu, the touch pad is a chore to use. Support button input, and show button tool-tips.
Remove HUD graphics that are obviously just left over from the mobile version. Based on real examples I've played: When the O button on the Ouya makes the main character shoot, don't leave a big button on the HUD, taking up space, that lets you shoot if you manage to click on it via the touch pad. Sure it's technically possible to click on the button to shoot, but it's very ineffective and the game already has a button on the controller dedicated to that action. It's just wasting screen space, and again looks sloppy.
Don't leave the || (pause button) on the screen as *the* way to pause the game via the touch pad. It's terribly slow to try to pause like that. Use the Ouya system button or another face button.
It's okay to add this!
Please put an Exit option in the game. Yes the Ouya system button can do this, but you can just as easily present the player with a simple option to turn off the game if they'd like to do so.
Remove unused manifest settings. This may be an Ouya system issue, but I've seen some games that when installed prompt that they may need to make phone calls. I'm pretty sure the Ouya can't make phone calls, but if it can, is your game really making calls? The ones I saw with this requested never made calls. If it's not needed, just remove it--it looks sloppy.
First and foremost--please, PLEASE use a dead zone on your left analog stick input. If you've taken anything from this article, go to your code now, and implement a dead zone. Now. This is really bad, as it's making your play experience worse.
Everything else on the list is good too. Basically it means you really cared about bringing your awesome game to new people. No one likes a sloppy port. No one wants to see "Press Start" in their PC games when they don't support controller input, and no one wants "Tap Screen to Continue" in their console games.
They want to think the neat, new game they are considering purchasing was made special just for their system, just for them. You worked really hard on your game. Ports are annoying--I know from experience. Put in that extra effort, clean up your game some more, and make it a AAA port. Good luck! Gamers will thank you.
To help invigorate game development for the new console, a game jam was held for the Android-based 'Ouya' console. It was a bit of an unusual game jam in that it had no specific theme and had some troubles early on (there was a false start and the rules changed a bit along the way). Buuuut once it got going, it turned out pretty fun. And the event, hosted by KillScreen and named the 'CREATE' jam ended up being very successful with over 160 games made!
The gist was simple, make a game for the Ouya, from scratch, in 10 days. Also, there's +$50k at stake! Playing around with new hardware and trying to make something quick is always fun, but the prize money offered even more incentive to get involved.
New Direction
I created a 4-player party game which has you controlling flying-pig-like creatures trying to eat the most bouncing balls first. The pigs bounce off each other, and if their mouths touch a tennis ball, they eat it. Each ball they eat makes the pig grow bigger. Controls are simple: left stick drives the pig around and any button 'boosts'. The boost propels them forward quickly for a second then they return to normal speed. Pigs have a sensitive tail on their backside. If a pig boosts into another pig's tail, the injured pig will barf out 3 balls.
Do you try to make progress or try to stunt your friend's progress? Ah...just like real life.
The goal of each level can change, but the basic version is to eat X number of balls first. As you play, it becomes a matter of watching the size of other pigs to see if they're beating you, scrambling to eat balls yourself, and if someone is getting too big, you boost and fight each other to make them spit up balls.
What Went Right
1. Don't Follow Your Typical Design: I love violence
and gore and guns in my games. Love it! But for this jam I picked no
gore, no extreme violence. At most, the pigs spit up balls they've eaten. Pigs can also bump each other.
Picking a design and motif that is unusual
for you is a good direction for a short prototype. You may have trouble
with it at first, but because everything is so different from what you
usually do there should be plenty of new ideas to explore in your own
style. Plus at the end, you could end up with something really different
than what you'd normally attempt. I'm already really proud of this game--I
can show my friends and family and not apologize for the flying guts and bone shards in most of my games! :)
2. Clear, Contained Design: The design for Pig Eat Ball was reasonable in scope. 4 players, bounce around, fight over balls, and bump each other. That's it for a first pass. Everything else is gravy. There's no crafting system, no complex animations, no intense AI. The difficult part, of course, with something simple is to make it interesting and original enough. I relied on my powers of 'crazy' for that--everyone knows pigs and tennis balls go together like honey and jackhammers :)
The other part of a simple prototype is to create an excellent 'fun loop'. Ensure that whatever you have for show when the jam is finished is honestly fun. Not 'fun if you know what we have planned', but fun with what you're playing, right then.
Day 1 Diary: Getting Started
3. Video Diary Motivation: Each morning I recorded what I did the previous day and carefully listed progress. This was an unusual jam since it was pretty long--10 days. That required special diligence to stay motivated. Seeing progress through the video and forcing myself to articulate the important changes each day helped me stay motivated for the next day despite some set backs.
Early quad-sprite tests for rotation, tinting, scaling.
4. Learning Through Examples: The system is Android-based using Open GL ES. Within about 20 hours, myself and another
programmer were able to get a respectable, quad-based sprite game
skeleton in place on the hardware. That felt really good! But clearly
this was only possible with articles and examples from others on the
internet. Bootstrapping from examples may be obvious, but was such a big part of the technology side I
had to list it.
What Went Wrong
1. Must Playtest with Newbs: The final version submitted to the game jam was pretty fun. BUT, I blew something completely. I was playing the game every day, refining the controls. That's to be expected. I was having a few others play the game each day as well. By the last day, we were all very good at the game.
The game was submitted with horrible collision bugs, but the problems were only noticeable if you were not good at the game! As the screen filled with tennis balls (from players not being good at catching the balls) the framerate would dip, and the collision bugs would begin to show. Players would get stuck in the walls. They'd get stuck in each other. Balls would travel through walls.
Even in a quick game jam, make time to have new people play it and watch what they do!
Yes, this is basic playtesting, but it's something that I think is easy to disregard or forget altogether when you feel you're missing proper menus, control screens, or advanced gameplay. It's easy to get flustered! But letting someone new playtest before you submit is huge and worth the extra time!
An early screenshot before the pigs had distinguishing icons.
2. Dodge Those Rabbit Holes: Several times I found myself spending time drawing art for a special 'how to' screen, or animations better suited for post-prototype development. For a short game jam, you've got to stay focused, and stick only to things that will absolutely be used right then. It's obviously fun to think about the bigger game, but get the 'fun loop' together first!
Day 3 Diary: Collision is Working
3. Watch Your Example Code: Part of the success was quickly learning how to do things in Android from examples. But that can be a double-edged sword as you may be wading into complex code with little understanding. I had trouble getting sounds to play on the Ouya. Was it hardware, code, or the wrong file format? Turned out I was calling 'Release' on SoundPool then trying to use it. SoundPool does not crash or report calls made to it after a Release(), which I found unusual but maybe it's a 'feature'. I fixed this only after slow debugging, forum searching, and reading documentation (precious time lost!).
Our submission made it just in time!
4. Save Time for the Upload: If this is a strictly managed event and you have to upload your game, approximate the upload time and budget for it! We almost didn't make it, only had minutes to spare because the game ended up a bigger upload than from days before. It's also possible for events like this to have their servers crash from so many uploads! I've done several XNA Dream Build Play contents in the past where this has happened. Get a screen shot of your finished upload!
Also, watch out what timezone the game-time is marked to finish (UTC? GMT? EST?).
Finished Pig Eat Ball game trailer
Fun Loop
My one-sentence, wordy lesson for a game jam or short contest? Ensure you have a demonstrable version of the fun part of your design, made possible because you stayed focused following your articulated, inspired concept.
Diary 6: After Jam, Bugs Fixed
Future
Pig Eat Ball is on schedule for release with the Ouya in April. I love that we're on our way to our first non-violent party game! My inspiration, motivation, and free time come in waves and here they all happened to line up just right. I hope the same can happen for you!
