It’s that time again. No, I don’t mean next week’s Superbowl. I’ve reached that magical moment when I realize… “Hey! Waitaminute! I haven’t tried to pick up new l337 sk1llz in almost a year!” I took a bit of a look around, and stumbled into Adobe Flex. Holy cow! There’s an environment where I can develop Flash-based software — only it feels more like my Visual Studio-esque background! A quick poke over to Monster.com shows a reasonable amount of interest in Flex, so it’s a technology that probably isn’t a dead-end to pick up. And since most of the coding is in ActionScript, which feels very Java-esque, the learning curve there probably won’t be murderous. OK, I’m sold. Time for a new project! (As an aside, I used our recent adoption of Twitter to drive an early test project: the Twitter widget you can see at the top-right of our page.)
I am both Lucy and Charlie
OK, I have to come clean here. As anyone who’s followed this blog in the past knows, I’ve publicly mentioned several projects that faded into the ether. So that doesn’t even count the projects that I didn’t mention publicly (though the gods know Tuebit could list at least a dozen of those for you). You see, writing a game — even a relatively small one — can turn out to be a difficult, and large project. And even with the best of intentions, it’s easy to scope-creep yourself. So, why am I going to kick the football this time? Because failing a few times has helped me get a handle on what kind of scope I can realistically manage. In other words, this time, it’s fo’ realz, yo! So let’s talk about goals, and the highest-level of designs.
My Selfish Little Goals
- I want to write a multiplayer game.
- I want this game to be asynchronous and web-embedded.
- I want to use contemporary technologies that I haven’t previously: Flex/Flash with a LAMP backend.
Perhaps equally importantly, what are my goals not?
- I am not going to focus on security and un-spoofability. I understand these problems, at least conceptually, and solving them will not accomplish my goals.
- I am not going to review this game for monetizability. While I’m fascinated with how games become profit sources, I just want to finish this one.
- I am not going to go overboard on graphics, music, or lore. I’ll try to get the game to a pleasant polish level, but I won’t be writing scads of flavor text, either.
A High Level Design
This game is currently untitled and missing any sort of “lore.” I’ll fill those kinds of details in later, when I finish. The working title (thanks, Wikipedia Random Entry for returning this) will be “redblack”
Every day, when I get home from work, one of the first things I do is log in to Facebook. I then play a half-dozen small-time-commitment games that are, well, pretty fun anyway. I’m going to learn from the design of the games I like, and then add some things I want to try.
Overall, the focus of the game will be a grid (hopefully hexagonal) of “systems” in a galactic-conquest style zone control game. Players can claim regions, construct stationary defenses, and construct travelling fleets of ships. Each of these activities will be embodied in a single-player casual puzzle game. Performing these actions occasionally rewards players with “event cards” which can be used to modify combat. Combat situations arise whenever a player sends a fleet to assault an opponent’s controlled system.
Defense will have an explicit advantage. It will require multiple players working in concert to defeat a well-prepared defensive position.
Facebook game mechanics that will be borrowed include: Actions are gated by some form of “energy” counter that recovers over time. PvP mechanics will be asynchronous; statistics-based battles will occur based on the state of the game board, but only the “attacker” will have been directly involved. Players will be able to chat amongst their team.
Game components including: Login, chat, “map” overview screen, “claim” minigame for unowned territory, “build ship” minigame for constructing fleets, “build defense” minigame for building stationary defenses, “battle” simulation for determining outcome of PvP situations.
Server components including: Data services for chat, game state, player state, and “history” log.
The first milestone
The “battle” portion will be constructed first, so that simulations can be played to tune the desired statistics produced by building minigames.
Wish me luck! I’m planning to start in on the “Battle” minigame in more detail in my next post.