Ok, ok. This image implies a bit more than is currently happening, but I have to have aspirations, right?!
One person’s crisis is another person’s opportunity. Now I want to dip my toe into something different. Stay tuned!
In between making games at my day job, I’ve done quite a bit of prototyping and learning. Here are some things.
I generally grab art from the interwebs, so thank you to those artists who put up their work for non-commercial use.
(Geek talk warning!)
So I’m exploring some new technologies, and I think I found a great solution for horizontal scaling databases. I’ve known about NoSQL for a long time, but never actually worked with it until this year. Turns out, it is awesome!
There are a few flavors, but they are all pretty good. I’m playing with MongoDB right now, but also going to experiment with Couchbase.
Since life has settled down a bit (shipped a new game at work, etc), I have been working on a new personal project. So, for that, I’m using NoSQL on the backend, and it’s been great so far. No MySQL sharding! No schema maintenance! No data parity issues between shards! No shards! (Well, not from the game’s perspective.)
Anyway, I’m back on the saddle, fired up about this little game, and using a chunk of spare time to get it running. Turn-based, multiplayer steampunk airship battles! With 3d graphics! (Unity, of course.) Huzzah!
(If you remember my old Facebook game, Merchant Commander, this is kind of just the combat lifted out and made into a game by itself. I wanted to keep the focus tight and the scope small so I have a better chance of finishing it before I die of old age. This is also a significant step toward a more expansive MMO-lite project.)
The techies at Turbine felt this was their last chance to create a new, better game engine. They had visions of their engine powering hundreds of different games and Turbine getting residuals forever.
So AC2 ended up using very little of AC1’s code. Because of all the low-level changes, it was impossible to reuse any of AC1’s game logic. Every game mechanic had to be written from scratch, even the parts that we wanted to be exactly the same. That made it impossible to create “AC1 with more stuff.” There just wasn’t time.
So it stopped being a sequel and started being a different game set in the same world. This one was a Kingdom-vs.-Kingdom war-fest with tons of character options. It was a good design and a fun PvP game. Unfortunately, it was not a sequel in any way, and that’s not what Microsoft wanted to hear: It had been promised a sequel.
So relations got strained between Turbine and Microsoft. Microsoft continued to promote the game as a sequel whenever its reps talked about it. The result? AC1 players came over, spit on it, and left.
If you’re ever stuck on the treadmill of going from language to language or from engine to engine or from shiny thing to shiny thing and you never seem to get a game finished, this is a powerful lesson on the value of reusing existing code. It’s a scary lesson on how far chasing butterflies can lead you away from your goals–to the detriment of your project.
Indies, beware! This siren is dangerous.
With Oil Spill Hero under my belt, this looks like the next thing on the list:
I have discovered and (so far) completely adore Player.IO. I was gobsmacked when I researched it and realized what they’re offering. Naturally, I had to make something with it! And that’s just what I’m going to do.
I had previously been really loving RedDwarf Server, and I still do, but the amount of effort to complete, launch, and operate a game with Player.IO is dramatically less. It’s got some quirks, but they’re quite minor in the scheme of things.
As much as I want to support and use RedDwarf (which I still think is a top-notch server tech–it just needs polished support services and libraries to make it the ultimate one!), I have to pay the bills. That means I can’t always use the technologies I want to. I said goodbye to Python and hello to ActionScript for the same reasons. It’s just not a feasible thing to do in terms of business.
There’s my geek banter for now. See you soon!
Oil Spill Hero is the next game I will release. It’s decidedly simple, and requires only one button. I could probably make a few games based on this central mechanic of “rise, descend over a scrolling level.” There’s a surprising number of ways to make it interesting, and Oil Spill Hero only scratches the surface.
I will be attempting to get the game sponsored, so I expect that will mean the game won’t be online until April. This is my first time getting a game sponsored, so I’m not sure how long the process will take. In the mean time, I’ll be cranking away on another small game (or two).
If you want more news about the game and a way to find other games I make, you might want to “like” Oil Spill Hero on Facebook.
Thanks for reading,
Yeah, so, I’ve got something brewing here. It’s a small project, but it’s a lot of fun, and it’s coming to a web browser near you pretty soon.
That is all.
I’ve decided to take a hiatus from Merchant Commander development for a couple of
weeks (looks more like a couple of months now).
For one, I’m researching some new Flash game engine libraries. I currently use PushButton Engine, but I’m finding it to be kind of long-winded and not clear about certain things such as what component controls which values. Well, that’s a geek rant I won’t make you suffer.
I came across something called FlashPunk, and I like it. It’s not as formally engineered as PBE, but that’s actually why I like it. In terms of sitting down and just getting something done, this game engine rocks. Yes, parts of the code make me cringe (just my taste, nothing wrong with how it’s made), but when I realized how fast I was getting a little game on the screen, that won me over.
Well, that and the fact that it has basic features for everything you need in a game. No hunting down and learning yet another 3rd party library for particles, tilemaps, tweening, etc. Just hack it up, and go! Add the fabulous DAME map editing tool, and you’ve basically got everything you need to make single player games.
It’s likely that Merchant Commander will get a FlashPunk overhaul. I have some big plans for how the interface is presented. It will become much more “game like” and animated, but that would be after the official alpha launch, when the game is online all the time instead of me taking it down to work on it most of the time. That’s coming soon.
But I will need more art, and that costs plenty of money.
So, I also want to experiment and see if I can make any money on single player games, and hopefully come out the other side with some more funding for Merchant Commander. We shall see!
As always, thanks for reading.
So there I was. Building this deep combat system, just how I like ’em. Its inspiration was a mix of Final Fantasy and Pokemon battle systems. It was fun, and had plenty of potential depth.
But here’s something I’ve been fighting the whole way with this game: it’s too much for Facebook. Yes, I like deep, complex games. Really deep, and really complex. Civilization is among my favorites. But a Facebook game is in a unique context, and that means that I have to live with the constraints implicit in that if I want to be a successful social game developer.
My rule of thumb #1 is that players aren’t usually on Facebook just to play games. Sure, it’s becoming a popular place to play, but it’s not usually people’s intention to go there just to play a game (exceptions apply, but we’re talking about the rule here). There’s friction between people’s intent and what they are willing to engage with. That makes it harder for a game to get and keep people’s attention, much less get them to come back.
Rule of thumb #2 is that a game can be interrupted at any point during play. This isn’t just a technical issue (for example, if the player is disconnected), but it’s a practical one, too. A player might need to leave suddenly (boss walks by? baby wakes up?), or might get distracted and forget he or she is playing (news blog in another tab?). This means when a player returns, they can’t be allowed to forget what was going on or what their goals were. The game state has to be discernible at a glance.
If a game demands too much for too long or doesn’t orient a player right away, they might quit playing. If you don’t have players, you can’t make money, and then you can’t keep making games for a living! Nobody wants that.
Something I noticed about a lot of Facebook games that have battles is that the battles are passive. You just watch!
I’m a “hardcore” player, so at first this horrified me. (And, in fact, I still don’t enjoy those games because they never tried to make watching fun.) But having a business to fund, I have to think from a player’s perspective, not mine. I thought my first battle system was “simple.” But let me tell you: truly simple design is hard!
My first battle system was fun, yes. But it was also a lot of work to play! Now I began to see the player’s perspective–not a hardcore player like me, but someone who is on Facebook doing other things and wants to pop in and out and have some easy fun. That’s the key, I think: easy fun–but not necessarily shallow fun.
With a deep battle system, you have lots of options, and thus lots of clicks, lots of icon menus, and lots of reading. (Oooh, the R word!) I have nothing against those things, but after playing quite a few Facebook games, you kind of get used to how easy they are to play, and it’s actually not a bad thing. It’s just different. I see the appeal. Time to embrace diversity and accept that games don’t have to be 50 hour epics to be fun and worthy.
And it’s what works on Facebook right now. I knew that I needed to pay attention, or I was going to fail. I’m paying attention!
I’ve come up with a new, passive battle system that is fun to watch and has some depth. (I admit that it will be a lot more fun to watch when there is animation and audio.) The key is to realize that it isn’t just the minutiae of issuing commands (a.k.a. micro-managing) that creates depth. I had to adjust my design goals with the new perspective on what makes Facebook games fun. Hint: go more meta.
I came up with something that I like a lot. It’s technically simpler but also much more intuitive to understand. That supports my rules of thumb better than an elaborate battle system with tons of hardcore gamer candy in it. There are still some places where I need to work on the UI and presentation because it’s not obvious how all the parts work. That’s on my roadmap, too. I’m workin’ on it.
This has also taught me a lot about evolving my design sense for this new market. I feel like I’ve improved as a game designer because of it. Not only will Merchant Commander be a better game, but all of my future games will be better. Simple is not the same as shallow. Simple is the removal of confusion.
So, you can go see for yourself. Play Merchant Commander on Facebook. This pre-alpha test version will be live until Monday. Then I’ll take it down, work on it for a while, and present another iteration soon. One day, it will be a Real Game, and I won’t have to keep taking it down!
Thanks for reading!