I split this week in two for myself (roughly anyway).
I spent the first half prototyping the game I’d like to work on next (right now I’m calling it Gobbler, but I think the name will change), and I set aside the second half for submitting Pffffft to the App Store and Google Play Store (it’s submitted yay!)
I’m going to explain my week a bit backwards with the tail-end of Pffffft, since my process starting the new game is pretty strongly influenced by how the dev of Pfffffft went, and talking about all the Pffffft stuff at once makes sense to me.
This was my first time submitting anything to the Google Play Store and the process is muuuuch more painless than– and as I’m writing this OH HEY the status JUST changed from “pending” to “published.” Dang. That was… really simple. I submitted it, like, 2 hours ago. This is … wow… I’m so used to the iOS process which…
Okay, let me back up.
In order to submit to Apple, you have to Archive a build (a few minutes), attempt to upload the build (a few more minutes), wait for the build to process (a few more minutes more), and if you’re like “oh shoot, that slider should really be inverted”† you have to do it aaall over again. If you’re working from Unity, by the way, before you do any of that, you have to build a new Xcode project, which, depending on what your previous build platform was, may or may not write over some of the settings you had to set in Xcode to prevent some of the errors appearing.
†totally and absolutely fake example unrelated to anything here whatsoever at all
Oh yeah, and if there are complications along the way, after any of the steps… you’ve gotta start at the beginning.
Forget to increment your build number? Well, it’ll tell you at the end of the upload step that it failed… Gotta change that and re-archive before you can start the upload process again.
Apple got sad at one of your archive settings? Whelp, gotta re-archive again.
Apple Worldwide Developer Relations Intermediate Certificate expired a few days ago? That’ll cause you all sorts of problems…
(Somewhat related to stuff that takes a long time, I highly recommend, oh Imaginary Reader, either using code to take screenshots in Unity of the proper dimensions for the upload page, preferably via a Plugin — but more on Unity Plugins later! I happened to find a very helpful post online with some sample code for how to do this that I used. By the way, I’m pretty strongly against blindly pasting forum code to solve a problem. Whenever I find sample code, I follow a strong rule that I never copy it. I like to write out my own version of it so that I can learn the process, using the other code as reference. I will admit that in this case I did paste in code from the forum to see if it did what I needed, i.e. take a screenshot, because it didn’t affect game code, and I felt okay doing that. I’d like to find the post so I can give proper credit to the forum poster. It was super helpful and did mostly what I wanted with just a little modification on my end.)
All this in mind, I was very happy to see the Android upload process was this:
- upload the apk file.
…
…
(The only hitch I ran into with Android was code signing, but I was able to find out how to do that pretty quickly, thanks to teh Interwebz)
Now Pffffft is uploaded and submitted (and live in one place!)!
I wanted to take some time to review some of the lessons I learned from Pffffft (other than how much easier it is to build to Android than iOS and how it’s somewhat remarkable I thought it would be the other way around).
I’ve touched before on how I sort of began dev for Pffffft in a backwards way; I had a heavy focus on the overall experience rather than the moment-to-moment gameplay until the last few weeks, when it makes more sense to do that the other way around.
I also let a lot of the theme dictate decisions I made instead of the other way around.
Some advice I remember getting in a game dev class when I was an undergrad that I didn’t quite understand but thought about a lot was that sometimes starting with a theme can be dangerous.
In the case in which I received the feedback, I was working on the art and some of the code for this game. Our group made very fast progress in that class and had (I thought) a pretty well-polished piece by the end. I was very proud of it. In the beginning, during an in-person meeting with our instructors, one mentioned that it’s sometimes dangerous to have art so soon (I think we had art in our first or second prototype — partly because I was eager to integrate it; partly because my role was to (a) make art/animations and(b) integrate the art and animations; partly because I was scared that if I did it all at the end, I wouldn’t be able to figure out how to put it all into code — I’ve gotten a loooot better at decoupling since then). The reason given was this: it can tie you down to a theme that doesn’t best showcase your mechanic and/or the fun of your game. We brushed aside the suggestion to change tac and play around with other themes. We had a positive feeling in the end, and, because of that, I never strongly considered how the game might have been different with a different theme.
Now that I’m done with Pffffft, I look at it and think about the fun of the game. In my opinion, the fun of the game isn’t so much the blowing as the bouncing around and generally looking silly. Perhaps I would have done better to pick a theme after ensuring the game was really truly fun and zany in the way I wanted. That’s not to say I’m disappointed with Pffffft, but I do realize that decisions I made early on made me feel boxed in to continue along a trajectory that may or may not have been optimal. Of course, I don’t want to wind up with the opposite problem of having too many options, I like having bounds.
What I want to try for this next game, however, is to make the bounds be the mechanics and the moment-to-moment play — this is pretty new to me.
I have faith that I can develop a theme that I like while also letting the mechanics dictate that theme, rather than working more off the theme. Anyway, it’ll be an experiment!
What DID I make though?
I started with a concept pitched to me by my brother: a timed multiplayer game in which players compete to collect objects that have canceling interactive properties when combined. You can use the things you collect as amo to cause opponents collecting the opposite thing to lose points, or you can horde them and play more defensive to try and not lose what you have.
For me-being-able-to-give-it-a-name-for-now purposes, I’ll call it Gobbler. As stated above, that’ll probably change.
I made 4.5 prototypes (one was just an alteration/fix of the other, and I prefer it to the previous one). Here they are††:
†† none of them are very color-blind-friendly prototypes by the way… I picked green and red, because they remind me of protons and electrons. Then I realized, oh yeah, those colors often do that genetic thing in some people.
1.0 Orbits
In this version, the players (pink square and blue square) have a finite number of orbs (green and red circles) they can collect on contact. When you collect an orb, it gets placed in orbit around you, sort of like Bohr’s electrons (I’ve represented this by putting a colored border matching the player color around the orb). Opposite orbs orbit in opposite directions. When an electron green orb and an anti-electron a red orb come in contact, they annihilate in burst of energy. It wasn’t fun to have them die though, so I had them produce a burst of energy, but not get destroyed. Also, I thought it might be cool if your shell got bigger the more electrons orbs were in it, and this led to something kind of fun; you can have both types of orbs… as long as you don’t have a matching number of them. Also, the nearer the number, the more likely they are to collide, since I made it take a bit of time for orbs to settle into orbit.
The win condition is to have the most orbs total. In one version of this (the 0.5 version that I’m not counting), I made the goal optionally be to be the first to collect all of 1 kind, to incentivize players not to wait until the last minute, but I think I was thinking too hard about specifics then. I cut that. There are other things I could do to incentivize different types of play, like awarding an extra orb for holding a certain number for a certain amount of time, etc etc.
This version was originally going to involve some method of launching the orbs, but… I realized there really wasn’t a need. You can steal orbs on contact and/or interfere with them by bringing opposite kinds in contact to create an energy burst and knock the orb away from your opponent.
The last thing I added was the ability to change your orbital speed, just so players aren’t always in-sync.
I think this version’s got some pretty cool potential.
2.0 Shooter
I had a lot of difficulty developing this one. It’s a side-view, with gravity facing downward.
The players are the pink and blue turret-like things that can collect different colored and valued orbs (the circles with numbers in them) on contact, but if you collect the opposite kind, it’ll decrement your count by that value. The red squares you see, by the way, just spawn more orbs, since in this version, you can lose orbs.
I had a lot of difficulty figuring out what could be fun about this version. I wasn’t too tied to the side-on thing, as you’ll see from none of the other prototypes attempting that.
The way you move in this one, by the way, is by firing charge blasts of orbs. If you’re empty, you’ll dry-fire, which will still move you, but if you have orbs, you’ll fire orbs of that kind.
In this version, the thing that I think made it most unique actually wasn’t the side-on thing or the movement mechanic, but the orb quantity information. Though this prototype’s a bit broken as a game (i.e. it’s not very incentivized to fire at your opponent, since hitting will just even your scores at best, lose you something at worst, and so sitting still is probably the best strategy once you have anything at all), I did like seeing the orbs combine. Oh yeah, the orbs themselves combine too. Opposites subtract, likes add (e.g. Red 2 + Green 3 = Green 1; Red 2 + Red 3 = Red 5).
This is something I may try to take away from this model.
3.0 Classic
I realized I should probably try something more standard/closer to the pitch. In this version player blue square and player green square can collect and fire twin-stick style (I also took this model as an opportunity to learn how to set up Xbox Controls in Unity on a Mac running 10.10! These are the drivers I was looking for, by the way — took me longer than it should have to find them… but they just worked!).
Player blue square and player pink square compete to collect orbs (little green and red squares) on contact, and they somewhat annihilate inside you EXCEPT, I wanted to resolve part of the problem prototype 3.0 had; i.e. if you each have the same count of opposite orbs, it’s never advantageous to fire. In fact, it’s NEVER advantageous to fire, because don’t need to fire to move, and you’ll always lose 1, and your opponent MIGHT lose 1 if you miss. You’ll always be the one to want the rebound, by the way, because your opponent would lose 1 by picking it up. In fact, the winner is pretty much always determined by the fortune of choosing the type of orb that the spawners (those red and green squares) spawn most.
To try and balance/fix this, I changed how annihilation works. No orbs annihilate unless they’re inside a player, and when they do, they spawn an orb of the color that was fired at that player. The net result of this sort of confusing-ly explained set of rules: firing at your opponent:
- always reduces your count by 1
- MIGHT reduce your opponents count by 1
- MIGHT allow you bring your count back up to 1 again, making your net 0 or -1
- MIGHT reduce your opponent’s count even more if you don’t pick up the rebound and hope it bounces at your opponent.
It’s a risk, but your opponent probably wont want to collect the shot you fired unless it reduces that opponent’s count to (otherwise it would cause more loss).
4.0 Heat
After making what I called “classic” I realized that it lost something kind of key that was in the pitch but that I’d only tried in the orbitals prototype, i.e. the ability to have multiple kinds of orbs.
In this version, orbs don’t get destroyed, and, in fact, players (blue and pink duo-circles) can pick up as many of both types of orbs (green and red circles) as they’d like. Only when an orb is FIRED does it pose a threat. An orb fired by an opponent (or a spawner — those red and green squares with time-til-next-fire counters on them) gets HOT (as indicated by the yellow outer circles around some. If you fire an orb, you can collect it while it’s still hot (blue’s fired orbs would have a blue outer circle in this prototype, pink’s would be pink), but if the spawners launch them, they’re dangerous to both players.
When hit by a hot orb, you’ll gain the orb, but you’ll also be forced to expel an orb of the opposite type, if you have any.
A sort of happy accident from this logic is that players with 0 orbs don’t need to dodge the spawners, and players never need to dodge hot orbs if they don’t care about the consequences.
In general, I like when being in last allows an easier jump to first (so long as I could add some mechanic to make being in first for a long time advantageous).
In looking at these prototypes and in evaluating which I want to pursue, what’s most important to me are these:
- Is the main thing players do fun?
- Is it easy to understand what to do moment-to-moment?
- Can this be expanded to more than 2 players?
- Do I want to play it?
Two tricky things about playtesting this are that (1) it requires at least 2 people to get a good sense of it (2) if I want to go with Xbox Controller controls, this will require both playtesters who are co-locus to also have 2 Xbox controllers on-hand. This is something that I can help by being present for all playtests (i.e. providing half the equipment, and hoping that people are willing to play in pairs).
There is a chance, by the way, that this coming week will be an interlude from Gobbler (a name I mentioned more in this post with-respect-to-it-being-temporary than otherwise come to think of it) in order to develop a game to showcase Affectiva‘s software at GDC ;), so do not be alarmed, oh Imaginary Reader, if you don’t hear about Gobbler for a little bit.
Oh! Plugins! Something else I wanted to mention (man this is running long) was that this was (somehow) my first week attending Boston Unity Group. The event was a panel, and, in addition to lots of in-general-good-advice given, there was a quite long discussion about how amazing Unity Plugins are. It made me realized that I’m not very knowledgeable about what Plugins are out there, like, I don’t generally look for them. Maybe I should start. I often find answers to questions I have on fora, and people make suggestions that can often be followed without using specific Plugins. Perhaps it also helps that a lot of the most popular Plugins have become, like, part of Unity.
All right. That sums up most of it. Oh, and I did miss Boston Post Mortem on Thursday. It snuck up on me, I’ll admit. I’ll also admit that it was nice to have a night off this week. I had to person a little bit.
Until next time,
~Zach
zbar games 