The only downside is that the simplicity of the graphics is now more apparent than ever. Ideally, I’d like to overhaul the visuals completely—especially considering the increased memory capacity and support for transparency provided by Pebble Time devices—but I must confess that would require more time and effort than I’m willing to invest at this point. These apps were fun to build and are fun to play (if I may say so myself), but my heart has moved on to other projects, particularly those associated with my new indie game development company: Golden Drake Studios.
So, what about owners of the original black-and-white Pebbles? Do I have anything new to offer them? Yes, as a matter of fact, I do. The following general improvements have been implemented in both the color versions and black-and-white versions of my games:
All game data, not just player data, are now saved between sessions in MazeCrawler and SpaceMerc (just as always has been the case in PebbleQuest).
In SpaceMerc, the player’s starting stats have been adjusted, the “Damage Vibes” setting is now “On” by default, and a bug wherein moving backwards away from an exit would cause the player to exit the current mission has been fixed.
In PebbleQuest, the effects of primary attributes have been adjusted, the base fatigue rate has been lowered, weapons and armor are now more beneficial, and a robe, shield, or suit of armor infused with a Pebble of Shadow now provides a slight bonus to physical defense in addition to spell absorption (which itself now involves a chance of absorbing enemy spells not only as energy, but also as health).
As always, I welcome your feedback along with your perusal and use (with attribution) of each of my games’ source code via GitHub:
That’s all for now. In closing, I offer my sincere thanks to everyone who’s downloaded, played, critiqued, praised, feigned interest in, or otherwise interacted with these, my humble experiments in smartwatch game development. Cheers!
PebbleQuest, a 3D fantasy roleplaying game developed for the original black-and-white Pebble watch, was released on December 25, 2014, weighing in at 25,020 bytes: 25kB or 24.4KiB. The concept for the game germinated in 2013 as I first started reading about the Pebble and other smartwatches. I was studying mobile game development at the time and the thought of creating an RPG for a wristwatch intrigued me. Before long I found myself ordering my own Pebble, typing up PebbleQuest‘s design document, and answering Team Pebble’s clarion call to “make awesome happen!”
I can’t say exactly how many hours went into PebbleQuest‘s development, but it was a true labor of love, consuming much of my spare time over the course of about fifteen months. Starting from scratch and armed only with the C programming language, the Pebble SDK, and the CloudPebble IDE, it took about two months to complete the basic foundation: a simplistic 3D environment navigable via the Pebble’s three right-side buttons, released in late 2013 under the title MazeCrawler.
As I started adding RPG elements, it soon became apparent that memory was going to be an issue. If a Pebble app’s size and memory usage cross a certain threshold, the app may still install successfully but will crash at runtime, either just after launching or after one too many allocations of dynamic memory (such crashes can also be caused by memory mismanagement, of course, so that possibility must be ruled out before concluding you’ve surpassed the memory limit). I was thus faced with the hard necessity of significantly scaling back my design. A bit flustered, I set PebbleQuest aside and spent the next few months on a slightly simpler game: SpaceMerc, a sci-fi first-person shooter released on March 23, 2014, as a last-minute entry into the 2014 Pebble App Challenge.
After that, my attention strayed somewhat to other projects, but by late September my spare time was once again dedicated almost entirely to PebbleQuest. Perusing my code with fresh eyes, I discovered several more ways to save memory, allowing gradual incorporation of, if not everything, then at least all the most essential elements from my original design. Overjoyed to see the game finally approaching my initial vision, I continued testing, fine-tuning, and polishing it until my self-imposed absolute deadline: Christmas morning.
Without further ado, I’d like to share a few details regarding PebbleQuest‘s design and development, my sources of inspiration, and the techniques and trade-offs used to provide a quality action-RPG experience within the memory constraints and other limitations of this unorthodox gaming platform. I’ll then conclude with some thoughts on the future of smartwatch gaming. If instead you’d rather just see basic information about the game and how to play it, head to the official PebbleQuest page.
Working Magic with Memory
Readers of my SpaceMerc postmortem will recall repeated assertions of “I couldn’t do this” and “I had to drop that” due to memory concerns, but it turns out I should have been more optimistic. I have since discovered several more strategies for reducing app size without sacrificing much, if any, content and I’m sure many more would have been found if only I had more time to experiment or had greater expertise with the C language.
For my fellow smartwatch app developers, I present a handful of memory-saving tips I picked up while working on SpaceMerc and PebbleQuest, some of which may be context- or compiler-dependent:
Unless you have a strong design-based reason for doing so, don’t reinvent features already present in the Pebble SDK. For example, use provided fonts rather than custom fonts, a MenuLayer rather than your own custom-designed menu, etc.
As much as possible, use integers rather than floating point numbers, and use int8_t or int16_t rather than int32_t or the generic int type. Also, where constants are concerned, bear in mind that powers of two (1, 2, 4, 8, 16, 32, etc.) can often be handled more optimally than other values. For example, rand() % 10 consumes slightly more memory (eight bytes more, to be precise) than rand() % 8. Finally, if you’re feeling bold, consider delving into the world of bit manipulation.
Avoid using your own typedef-defined variable types. Having said that, defining a struct might still be a good idea for some tasks, at least for the sake of convenience and readability, but keep them to a minimum, read this tip for reducing struct size, and ensure a struct‘s size doesn’t exceed 256 bytes if you plan on saving it to persistent storage through a single call to persist_write_data.
If you’re using function calls, array indexing, or pointer dereferencing to get at the same value multiple times within a given function, it may be better to instead get that value once and store it in a local variable, especially if more than one call/index/dereference is required to get at the value.
Keep conditional statements to a minimum, but where they can’t be avoided, if–else is often more memory-efficient than switch, in my experience. Experiment on your own, case-by-case, to be absolutely sure.
On that note, keep in mind that array indexing is often an excellent alternative to conditional tests. For example, if you catch yourself using conditional tests on an integer n to determine which string constant to copy to a text field, you can replace those conditionals with a constant array of string constants that can then be indexed by that same integer n.
In general, eliminate any function that’s only called once throughout your program. In other words, directly incorporate that function’s code into the function that called it.
Speaking of functions, although a void return type is often suitable, there are times when specifying a return value will actually decrease a function’s memory footprint even though that value is never used. This one is a bit mysterious to me, so I recommend experimenting with your own function return types one-by-one.
Finally, the most obvious way to save memory: Simplify your design, cutting out any elements that aren’t absolutely necessary. Challenge all your assumptions about what “needs” to be in the game.
One thing to bear in mind: As reduction of memory footprint rises in priority, other software development values, such as the readability and modularity of code, might need to be sacrificed to some extent (as evidenced by my less-than-ideal source code). If you’re not careful, this can make the process of modifying, debugging, and polishing your app more difficult than usual down the road.
Akalabeth Meets Arena: Real-Time Action in a Simplistic 3D World
My vision for PebbleQuest was to create the smartwatch equivalent of an old school action-RPG. I took inspiration from a variety of classics, including two of the earliest RPGs to feature real-time, first-person combat: Ultima Underworldand The Elder Scrolls: Arena.
However, where movement was concerned, I decided early on to go with abrupt 90° turns and simple forward/backward motions more evocative of older classics, such as Dungeon Master or Eye of the Beholder.
Or, going all the way back to the first computer roleplaying game ever published and the precursor to Richard Garriott’s Ultima series, Akalabeth: World of Doom, although once we reach this point I’m happy to say PebbleQuest finally manages to look better and smoother than at least one of its predecessors!
I hasten to note that, although I chose to employ simplistic 3D and abrupt movements, the Pebble device is fully capable of supporting more sophisticated forms of 3D representation. For example, this 3D FPS demo features more visually-impressive environments as well as free, fluid movements controlled entirely by the Pebble’s accelerometer (in other words, by tilting your wrist or otherwise tilting the Pebble).
Why didn’t I make use of the accelerometer? Well, accelerometer controls are fun to play around with, but, if you ask me, they end up feeling awkward when applied to games of this sort, so I chose to stick with button controls. Admittedly, my control scheme is awkward in its own way: movement forward and backward is facilitated by single-clicking (or continuously pressing) the “Up” and “Down” buttons, respectively, while turning left and right is accomplished by double-clicking those same buttons. It takes a little getting used to but was, to my mind, the best way to allow the player to turn left and right and move forward as well as backward while still leaving the “Select” button available as an attack button and the “Back” button as a way to return immediately to the main menu, all without worrying about how your Pebble is currently tilted.
For a slightly different take on button controls and another impressive example of the kind of 3D gaming Pebbles can support, check out this dungeon crawler by JeckleCed:
Clearly, that game is better-looking than PebbleQuest, but it has yet to be completed and released, mainly due to the Pebble’s memory limitations. I hope to see it released in the near future along with many other games of this sort, even if they do end up outshining my own creations. Oh, and for the record, I do have experience related to programming those kinds of richer 3D worlds, but, for the sake of keeping my Pebble games simple, compact, and easy to complete within a relatively short time frame, I opted for a more old-fashioned approach.
Now that we’ve discussed movement and the overall 3D environment, let’s dive into combat. At one point during development I considered going with turn-based rather than real-time combat, especially since casual “look at your watch now and then” games are naturally quite popular on this platform, but that wasn’t the experience I was aiming for. I wanted real-time battles governed by “dice rolls” in the background, like those of my favorite RPG series: The Elder Scrolls. Unlike the first three Elder Scrolls games, however, all attacks will deal at least a minimal amount of damage. Also, I dropped bows and arrows at one point, so there are no ranged physical attacks, but all spells are ranged, including spells from enemy mages. Finally, to compensate for awkward controls and overall difficulty, the player can attack (and move) up to four times per second, whereas enemies attack (or move) only once per second.
So, what about combat-related graphics? Spells and enchanted weapons cause an inverter layer to appear and then disappear, creating a “flash” effect. Physical attacks from enemies aren’t animated, but damage to the player is indicated by a short vibration. Physical attacks from the player generate a white line across the central portion of the screen from one random point to another. I would have enjoyed creating distinct graphical effects for each type of spell and weapon, but didn’t have enough spare memory to justify such an extravagance. As for the appearance of the NPCs themselves, I considered using bitmap files, but transparency would not be supported by such files, so I stuck with drawing primitive shapes, lines, and pixels instead. Again, in order to save memory some visual details were left to the player’s imagination. Nonetheless, I think you’ll agree that, while in active gameplay, the resulting images are sufficient to create an intense gaming experience.
The Player Character
One of the first steps in any RPG is the creation or presentation of a character (or team of characters), sometimes with customization options. PebbleQuest automatically creates a default character for you without any need to choose race, sex, class, skills, or anything else. Because you never actually see your character, you’re free to imagine his or her physical appearance and cultural background however you please. You’re also free to choose which items to equip and which attributes to increase as you level up, thus roleplaying your preferred character type, whether that’s a heavily-armored sorceress, a leather-clad assassin, or a naked axe-wielding barbarian!
To keep things simple, I settled on three primary attributes—Strength, Agility, and Intellect—corresponding to the three major fantasy archetypes of Warrior/Fighter, Thief/Rogue, and Wizard/Mage. Each time you level up, you can increase one attribute.
In a more complex RPG, I would have gone with a wider range of basic attributes, perhaps something like the six attributes of Dungeons & Dragons, the seven “SPECIAL” attributes of the Fallout series, or the eight attributes of the first four Elder Scrolls games. As it is, PebbleQuest‘s attributes and leveling system actually have a lot in common with the latest addition to the Elder Scrolls series: Skyrim.
Like PebbleQuest, Skyrim features a classless system with three major attributes, one of which may be increased each time you level up, although in Skyrim these attributes are (surprisingly) Health, Magicka, and Stamina: the quantities drained when the player takes damage, casts a spell, or swings a weapon, respectively.
PebbleQuest features a Health bar like that seen in Skyrim (and countless other games), but instead of separate Magicka and Stamina bars there is a single Energy bar that diminishes anytime either a spell is cast or weapon swung. Finally, PebbleQuest is also similar to Skyrim (and Oblivion) in that Health and Energy are both automatically replenished over time: no need to find a place to sleep.
While we’re on this topic, I’d like to argue a more general point: Simplification isn’t always bad, nor is increased complexity always good, even in a “hardcore” RPG. Balance between absolute realism and smooth, enjoyable gameplay is crucial in any game. As such, although some fans of the Elder Scrolls series were disappointed by Skyrim‘s departure from the previous class-based, eight-attribute system (among other things), I didn’t mind their abandonment of character classes, which often just end up feeling like a source of arbitrary restrictions, and I found their experiment with a streamlined, skill-based, perk-focused leveling system fascinating and effective. There are definitely some things I would criticize about Skyrim‘s design, but the leveling system and dearth of traditional attributes aren’t among them.
Getting back to PebbleQuest, although characters in this game don’t have skills or perks, they do have the following minor stats, each affected by the primary attributes and sometimes by equipment:
Health Regeneration Rate
Energy Regeneration Rate
Fatigue Rate (energy loss per attack)
Those “Power” and “Defense” stats are undeniably generic, but remember: I had to keep things simple. Rather than a bunch of separate stats along the lines of “Resilience,” “Evasion,” “Armor Rating,” etc., there’s a single “Physical Defense” stat incorporating all of the above. Might sound odd, but with memory this tight, why not? Whether you reduce physical damage through sheer toughness, dodging, or glancing a blow off your armor, it all amounts to the same thing: damage reduction. Similarly, raw power and the ability to effectively time and aim an attack are both factored into “Physical Power.” As for “Magical Power/Defense,” these too are affected not only by Intellect, but also by Agility because dexterous, coordinated movement is involved in the casting, aiming, and dodging of spells.
Perusing the full list of character stats from PebbleQuest‘s main menu will also reveal current experience points, level, depth (how deeply you’ve descended into the dungeon), and two special minor stats:
Spell Absorption (chance to absorb enemy spells as energy)
Backlash Damage (damages enemies when they physically attack you)
These start at zero but may be increased by equipping a robe, shield, or suit of armor infused with the appropriate Pebble of Power. For complete information on the effects of various items, including the seven Pebbles of Power, please refer to the official PebbleQuest page.
To Quest, or Not to Quest: That is the Question
With a name like PebbleQuest, you’d be correct in assuming you’ll embark on a quest: a quest to collect Pebbles of Power, no less! I faced two quandaries on the questing front, however: (1) whether the main quest should feature a complex storyline and diverse locations and (2) whether to include a system of side quests similar to the mission system in SpaceMerc, complete with gold coins earned as rewards that could then be spent at a marketplace. As development progressed, I weighed my priorities and opted for a simple roguelike (or “roguelike-like“) dungeon crawl as the main quest, did away with side quests, and dropped the marketplace idea. Sacrificing such desirable but nonessential elements enabled the inclusion of a wide range of stats, items, enemies, and other basic features that were far more crucial to my creative vision.
To me, the list of critical elements boiled down to the following:
A variety of 3D environments (even if the only “variety” is provided by procedural generation) filled with a variety of enemies.
Equippable weapons, armor, shields, and clothing.
Pebbles of Power that may be equipped to cast spells or infused into other items to imbue them with magical properties. Needless to say, I also hoped these would provide a fun connection to the name of the device on which the game runs!
Beyond those three features, everything else was negotiable, including “questlines” and other forms of storyline. Thus, the only narrative in PebbleQuest, aside from that generated by the player’s own imagination and unique interactions with the game world, is provided by the following text, displayed each time a new character is created:
Evil wizards stole the Elderstone and sundered it, creating a hundred Pebbles of Power. You have entered the wizards’ vast underground lair to recover the Pebbles and save the realm. Welcome, hero, to PebbleQuest!
There are, indeed, exactly 100 Pebbles that may be collected in PebbleQuest, one for each level of depth in the dungeon, meaning you must descend to the maximum depth of 100 to collect every Pebble. This arduous task is rewarded only by a simple congratulatory text:
Congratulations, hero of the realm! You’ve vanquished the evil mages and restored peace and order. Huzzah!
Each Pebble is held by one of 100 mages who constitute the “bosses” of the game and are the only enemies capable of ranged attacks. Oh, and speaking of the number 100, that’s also the player’s level cap.
One final point about questing in PebbleQuest, which also illustrates the impact one design choice can have on another: Because the “main quest” and the game overall ended up being simplistic and somewhat lacking in diversity, I feared players would bore quickly, so I decided to increase intensity by making death permanent (one of the key features of any roguelike), meaning that you must start over from scratch whenever your character dies. This feature would be intolerable in an RPG of grander scope, such as any of the Elder Scrolls, Fallout, or D&D-based titles, but it fits nicely in a simple dungeon crawler like PebbleQuest because the added tension contributes to the pleasure and sense of accomplishment derived from each victorious battle and each level survived and yet there isn’t too much frustration when a character dies because there really isn’t that much to lose nor is there a great, expansive narrative to complete.
All that Glitters…
Though gold coins and commerce didn’t make their way into PebbleQuest, I aspired to make money in the real world through this humble RPG by selling it for a dollar per download. I imagine this may have surprised some people, but, as detailed above, designing and programming this game from scratch required a significant investment of time and energy, so I felt justified in seeking a little remuneration from my fellow fantasy enthusiasts.
As a matter of fact, I initially planned on selling SpaceMerc as well, but for various reasons ended up releasing it for free, just like MazeCrawler, on the official Pebble App Store, which didn’t support paid apps at the time and still doesn’t to this day. Early on, there was some talk from Team Pebble about eventually supporting payments, but this has yet to materialize. For a few months in mid-2014, I actually delayed PebbleQuest‘s development specifically because I didn’t want to release it until it could be sold on the official store. There were a handful of unofficial online stores selling Pebble apps at the time, but I wanted to stick with the official store as much as possible and figured it was only a matter of time before they would announce they were ready. As weeks and months continued to go by without any indication they were working on that feature, I decided I might as well finish up PebbleQuest and sell it through my own website.
Sales started trickling in and I was deeply grateful for each one, but there weren’t nearly as many as I hoped, even with all the newly-gifted Pebbles around Christmastime. I posted links here and there, and my website already had an abundance of Pebble-related content for search engines to pick up, so a lot of Pebblers were checking out my PebbleQuest page, it’s just that precious few were taking the next step of making a purchase. This tale of woe is common in the indie game development world, though, so I was mentally prepared and only slightly disheartened. I also learned a few valuable lessons. For example, I should have provided a free trial version on the Pebble App Store with the option to purchase the full game through my website (or elsewhere). I arrogantly assumed PebbleQuest‘s description would be so appealing to any fellow Pebbler and RPG fan that a demo was unnecessary, but it later became clear that some folks wanted a test run before laying down any money.
In any case, by late February sales had tapered off and Pebble had revealed a new Kickstarter campaign for their next-gen watch, Pebble Time, featuring 64 colors, expanded memory, and other improvements, so I decided it was time to go ahead and provide my now humbler-looking, black-and-white RPG free of charge on the Pebble App Store as well as MyPebbleFaces.com. The code is also open source, as it was from the beginning, so feel free to check it out on GitHub and borrow from it as you make your own Pebble games. I may eventually produce color versions of each of my Pebble games, along with a handful of new Pebble apps and watchfaces, but the bulk of my time is now dedicated to screens larger than 144×168 pixels as I’m in the midst of establishing my own indie game development company: Golden Drake Studios.
The Future of Smartwatch Gaming
What does the future hold for smartwatch gaming? First of all, we can expect a lot more color as the much-anticipated Pebble Time and Apple Watch join the ranks of the already-colorful Android Wear devices. We can also expect casual games to dominate here just as they do in the realm of smartphones and tablets, though semi-hardcore games like PebbleQuest will pop up now and then. Finally, free-to-play will definitely be the norm, but the income potential from freemium games (and perhaps the occasional pay-to-play game) could be significant, as evidenced by the recent appearance of a Finnish game studio devoted entirely to wearable tech: Everywear Games.
In order to get more specific, let’s see what lessons and predictions can be gleaned from the current top seven games on the Pebble App Store:
Pixel Miner: A little miner moves across the screen, digging up pixels and occasionally finding treasure. Pixels can be spent on “Equipment” (jackhammer, goblin team, mutant mole, etc.) for deeper digging as well as “Multipliers” for faster digging. Designed from scratch with the specific characteristics of the Pebble platform in mind (as opposed to most Pebble games, including my own, which involve taking games or game genres from other platforms and saying, “I wonder if I can make something like this for the Pebble!”), I can attest to the satisfaction derived from this game and fully understand why it’s immensely popular. All the real action takes place without any user input, so it only requires occasional attention: perfect for a game that sits on your wrist. There’s also no way to lose, making it completely stress-free. Finally, I love that, in addition to toilet seats, tin cans, boots, and various gems, the miner may also stumble upon such rarities as a Fabergé egg, the Holy Grail, or the Necronomicon. My only complaint is that the game doesn’t display the time, forcing you to exit the game when you want to, you know, use your watch as a watch.
Tiny Bird: Based on the simple, surprisingly popular, somewhat controversial, and now unavailable mobile game Flappy Bird, this game does require constant attention, but it’s still well-suited to the Pebble platform owing to its one-button control scheme. Personally, I hate this game, but a lot of people clearly love it and it’s easy to build, so we should expect many more games of this sort in the years ahead.
Hatchi: A virtual pet for you to occasionally feed, bathe, and otherwise care for, just like the once popular Tamagotchi. An Apple Watch version is also forthcoming. This is another perfect fit for a smartwatch app, but here’s my recommendation: Let’s design some virtual pets with better graphics and more interactivity; in other words, pets that don’t resemble Tamagotchi!
MiniDungeon: A simplistic RPG with random events and turn-based combat. Of all the games on this list, this one comes closest to PebbleQuest in spirit, but they’re worlds apart in terms of gameplay. It’s in first-person perspective, but instead of actively moving through a dungeon, a new scene is generated each minute. Now and then, a new item is found or enemy encountered. Combat is turn-based and employs a simple menu system. I personally don’t enjoy this game, but it’s gotten more “likes” than all of my games combined, so it’s obviously doing something right, and that something is probably this: Much like Pixel Miner and Hatchi, this game doesn’t require constant attention. You can leave it running all day and simply glance down whenever you have a free moment. We can expect to see more casual RPGs of this sort, perhaps including some in the JRPG style with battle screens resembling those of the early Final Fantasy titles.
Mr. Runner: A little man continuously runs forward, except when you press a button telling him to pause, which you’ll want to do whenever something’s about to crash down in front of him. Simple and fun! Many similar games can be found on the Pebble App Store, some of which are slightly more complex such as the “runner” version of the mobile platformer Alice’s Mom’s Rescue. Speaking of which, let that be a lesson to all you smartwatch game developers out there: If you want to make something like Super Mario Bros. while still avoiding the awkwardness of supporting back-and-forth movement, just turn it into a “runner” game. Also, it’s worth noting that some popular Pebble games involve a character continuously jumping or otherwise moving up instead of to the side, including one entitled Mr. Runner UP.
Pebtris: The Pebble version of Tetris, one of the greatest video games of all time. Classic remakes are fun, even when they don’t lend themselves perfectly well to a smartwatch’s limited controls. Other classics worth checking out include Pebloid, Asteroids, Snakey, Rogue, and Chess.
PinyWings: This Tiny Wings port is graphically astounding and an excellent example of a well-polished casual game that stands to make some revenue. It’s free to try a sample level, but to unlock the full game you must make a payment through TinyPay: a “smooth payment service for Pebble apps,” currently in private beta phase. If I ever decide to monetize another smartwatch game, this is probably the model I’ll follow!
So, what’s the takeaway here? Smartwatch games should be simple and intuitive, possibly nostalgic or familiar in some way, and perhaps capable of being left on to be played sporadically throughout the day. You’ll notice that none of the top Pebble games are of the first-person action variety since these will generally fail the “simple and intuitive” criterion. That’s not to say there isn’t a niche market for such games, but they’ll never be as popular as casual games, and that’s understandable given the tiny screen size, limited controls, etc. So, if your heart’s set on crafting an experience similar to your favorite first-person game, be sure to thoughtfully consider various ways the basic concepts behind that game could be adapted to the unique characteristics and typical use cases of your target platform.
For example, say you want to create something like Minecraft. Simply cloning it with a first-person perspective would be interesting, but would also most likely result in awkward, frustrating gameplay that gets old real fast. On the other hand, focusing on the core element of block-building and employing a more small-screen-friendly isometric view could result in simpler, more intuitive, and ultimately more satisfying gameplay, as we now see in Block World!
And why not venture out into unexplored territory? If you ask me, one particularly exciting frontier for smartwatch game development is augmented reality (AR). The popular AR smartphone game Ingress is already being ported to Android Wear devices and clever game designers are sure to come up with similar territory-based games along with completely novel AR ideas specifically suited to wearable tech. Some of these may blur the line between AR and the general gamification of life. Fitness tracking, the primary (or only) function for many wearable devices, is essentially a gamification of exercise and could easily turn into AR just by adding something as simple as a number indicating the distance of an imaginary beast that will devour you if you stop or slow down too much. What other ideas can you come up with to add an extra layer of fun and excitement on top of your daily activities?
Wherever the burgeoning field of smartwatch gaming takes us, I hope it can be said that PebbleQuest and its predecessors, MazeCrawler and SpaceMerc, have contributed to its early development and inspired some of today’s young tech enthusiasts to envision and implement their own app concepts. In other words, I hope I did indeed “make awesome happen” and that I encouraged others to do the same!
SpaceMerc has been available on the Pebble App Store for almost three months now and downloaded—along with its predecessor, MazeCrawler—by well over 2,000 of my fellow Pebblers. It is also, according to my research, the first FPS game ever developed for a smartwatch!
Although this is a modest achievement at best, I can’t deny it makes me happy to think I may have made a small contribution to video game history. In addition, working on SpaceMerc has been valuable for me in terms of software engineering, game development, and game marketing experience, and I can once again attest to the joys and pains of toiling to create something original and then sharing it with the world.
In what follows, I’ll share a few experiences from my time developing SpaceMerc. If you’d prefer to see basic information about the game instead, check out the official SpaceMerc page.
Looking Back: From MazeCrawler to SpaceMerc
Having built MazeCrawler, a few fundamental challenges were already taken care of: (1) effectively portraying a first-person 3D environment on the Pebble’s small black-and-white screen, (2) handling player movement within that environment, (3) reliably saving data to persistent storage, and so forth.
Nonetheless, SpaceMerc presented several new and daunting challenges, including:
Populating the 3D environment with non-player characters (NPCs), handling their behavior, and depicting them graphically at varying depths.
Attempting to make the environment more varied and interesting.
Animating the player’s attack and handling its effects on NPCs and walls.
Designing an effective mission system.
Providing a greater sense of progress over time.
Handling an increased need for narration texts.
Doing all of the above within the Pebble‘s tight memory constraints.
That final challenge was the biggest of all and impacted all the others, so I’ll discuss it first.
I never ran into trouble with memory during MazeCrawler‘s development, but I hit the wall very quickly after moving on to SpaceMerc. Actually, I should say “after moving on to PebbleQuest,” for it was only after realizing my aspirations for that action-RPG were far too bold that I decided to create SpaceMerc as a simpler intermediary in the first place.
Even after settling on what I assumed were achievable design specs for SpaceMerc, I had to scale them way back in order to (a) keep the app itself small enough to fit in one of the Pebble’s eight allotted app slots and (b) prevent the app’s use of dynamic memory and persistent storage from crashing the game at runtime. Naturally, this was frustrating because it meant I couldn’t do everything I wanted to do and feared the gameplay experience might suffer as a result. On the other hand, it also felt liberating: by forcing me to lower my ambitions, it enabled me to reach a stopping point much sooner than I otherwise would have.
George Lucas once said, “A movie is never finished, only abandoned.” The same is true of games and all other creative works, but abandoning one’s work can be excruciating. As such, it’s helpful to be shoved in that direction, whether by financial need, a deadline, technological limitations, or some other consideration. In fact, aren’t we all glad George Lucas was forced to abandon some of his ideas while making the early Star Wars films, and don’t we wish he’d never returned to “improve” them? But now I’m getting off topic.
Another benefit of running into memory limitations was that it gave me an excuse to put on my “serious software engineer” hat and do something I suspected I ought to do anyway: comb through all my code again looking for each and every function, block of code, line of code, and code fragment that could be improved, trimmed down, or removed altogether. This meant cutting out superfluous error-checking, reducing my use of conditionals (“if” statements and the like), being careful about when I used integers versus floating point numbers, shortening string variables, eliminating unnecessary variables, and so forth. Sure, this may not be most people’s idea of a good time, but once you dive in, it’s surprising how much fun it can be. Well, maybe “fun” is the wrong word, but it feels good to have the power to solve problems and improve things.
Anyway, with the issue of memory limitations firmly in mind, let’s move on to the other challenges I mentioned.
Non-Player Characters (NPCs)
The addition of NPCs is one of two crucial differences between this game and MazeCrawler (the other being the player’s ability to shoot). I knew I had to nail this aspect of the game if I wanted anyone to take SpaceMerc seriously, but I also knew I was working with very limited graphical capabilities, not to mention limited memory. I did the best I could and overall I’m fairly pleased with the results.
Obviously, it would’ve been nice to provide a vast array of enemies, each with unique stats, behavior, and graphics, but that wasn’t feasible. In the end, I was satisfied to have seven different enemies, some of which share the same stats or graphical elements, and all of which exhibit the same simplistic behavior: pursue the player, then attack.
I originally wanted to incorporate more behavioral diversity, such as cowardly enemies running away when wounded, and more animations. I also took it for granted that some enemies would be ranged attackers (capable of attacking the player from a distance) and hoped to throw in a few friendly NPCs that weren’t just passive like the humans you’re sent to rescue during “Extricate” missions. In the end, however, I settled for seven simple-looking, simple-minded enemies that only attack at close range, only one of which exhibits any animation (the “Beast,” whose mouth opens and closes), and that appear randomly up to three at a time. [UPDATE: As of version 1.5, gun-wielding enemies are now capable of ranged attacks!] Though less than ideal, I felt this compromise was acceptable given that SpaceMerc is, after all, a smartwatch game and simply cannot approach the level of complexity and visual appeal generally expected of a modern first-person shooter.
As a final note, soon after designing the tall, bulky, intelligent race of aliens known as the Fim, I began to feel there was a resemblance between them and the mysterious grey aliens of Éric Chahi‘s masterpiece: Another World (known as Out of This World in some of its North American incarnations).
The similarity is unintentional (my aliens are block-headed and wear sleeveless shirts simply because I was able to reduce app size by not drawing necks and sleeves), but not unwelcome. I’m an ardent admirer of Chahi’s work and count Another World among my favorite video games of all time. If you’ve never played this action-adventure classic, you’re in luck: its 20th Anniversary Edition is now available not only on PC (Amazon/Steam/GOG.com) and Mac (iTunes/Steam/GOG.com), but also on Android (Amazon/Google Play) and iOS (iTunes) devices, and according to the official website it will soon be available on all the latest gaming consoles as well.
Initially, I had big plans for the 3D game world. I wanted to introduce some new wall textures and lighting effects, perhaps even outdoor locations and an occasional river of water or lava. Sadly, those features were among the first things placed on the chopping block as I started hacking away at my design specs. Variety is the spice of games, but NPC variety seemed far more important to me than environmental variety, so I made some sacrifices in this area. The only significant addition was a “door” graphic depicting the entrance/exit of each mission location.
On a related note, I originally planned on implementing in-game items for recovery of health and ammo (among other things), but elected instead to save space by allowing both health and ammo (actually, “energy” would be a more accurate term) to automatically recover over time.
The Player’s Attack
Pressing the Pebble’s “Select” button causes the player to attack, sending out a laser beam capable of burning through any enemy or wall in its path.
Drawing a simple laser beam and animating it with help from an AppTimer actually wasn’t much of a challenge, nor was it difficult to handle dealing damage to the first enemy or wall hit by said laser, but there was, and still is, one small issue: the player’s attack speed is not constant. Sometimes the gun shoots more rapidly or sluggishly than intended. It seems to be related to the number of walls in the player’s field of view, but, unfortunately, I have yet to find a workable solution to this problem (more on this later).
By the way, as I’ve been alluding to, yes, you can destroy walls in this game. If you want, you can destroy every wall you see (except for boundary walls) just for kicks. This feature was largely inspired by The Elder Scrolls: Arena, the very first Elder Scrolls title, which includes a fun wall-destroying spell called “Passwall.”
Demonstration of “Passwall” in The Elder Scrolls: Arena.
You can also increase your attack power through upgrades, but one thing you cannot do, unfortunately, is switch between different weapons. I do plan on implementing multiple weapons (and spells) in PebbleQuest, however, so you can look forward to that!
Missions are critical to SpaceMerc as they provide context, variety, and a sense of purpose. I was able to fit five (rhyming) mission types into the game: “Retaliate,” “Obliterate,” “Expropriate,” “Extricate,” and “Assassinate.” They differ enough, I hope, in their descriptions, success criteria, and other characteristics that they, along with the procedurally-generated locations and randomly-appearing NPCs, will keep the game feeling fresh and interesting indefinitely.
One mission type I’d really hoped to include was an “Escape” mission that would occur whenever you fell in battle. You would awaken to find yourself in a prison cell, but, since the Fim were unable to remove either your advanced suit of armor or the laser gun affixed to it, you could blast your way to freedom. In the end, this was tossed out in favor of a simple narration: “You fell in battle, but your body was found and resuscitated. Soldier on!”
A sense of progress is crucial to any video game, whether it be through points, leveling, loot-gathering, increasing difficulty, the advancement of a narrative, the opening of new vistas, or whatever else. Having abandoned in-game items, and not wanting to simply tally up points, I provided an “Upgrade” system in SpaceMerc whereby money earned from missions can be spent to improve your stats, presumably by visiting a technician, cyberneticist, doctor, or other relevant expert in your current corner of the galaxy.
SpaceMerc employs a narration system to (1) establish overall context the first time the app is run, (2) describe the goals and potential rewards of each mission, (3) detail the outcome of each mission, and (4) to present “Controls” and “About” information.
At first, I designed the narration system to be animated, revealing letters one at a time, but for the sake of trimming things down I later removed that functionality. I also shortened narration texts as much as I could, freeing up memory at the cost of making mission descriptions rather terse.
Looking Forward: From SpaceMerc to PebbleQuest
I may continue tweaking and improving SpaceMerc from time to time, so please share any feedback you have about the game, especially any changes you’d like to see. Most of my time and attention, however, is now reserved for PebbleQuest: the action-RPG I’ve been working towards since the moment I bought a Pebble watch.
It may be quite a while before PebbleQuest is released because I’m combing through my code yet again looking for even more ways to save memory and squeeze in content. Once complete, my hope is that PebbleQuest will offer even more than SpaceMerc in terms of gameplay variety, character customization, and narrative.
I may also build a turn-based version of PebbleQuest, in addition to (or completely replacing?) the action-RPG version, mainly because that should allow me to include even more content while avoiding the timing issues discussed above, but also because I suspect some Pebblers would actually prefer a turn-based experience.
In addition to sharing any feedback you have about SpaceMerc, please let me know what you’d like to see in PebbleQuest. In particular, would you have a strong preference between real-time and turn-based combat? If you generally prefer action-RPGs, but a turn-based RPG could offer more content, would that change your mind in this instance? Feel free to share all your thoughts and suggestions in the comment section below. And finally, thanks for taking an interest in SpaceMerc and all my indie Pebble games!
I’ve been following the news about smartwatches and other forms of wearable technology for some time now and find it very encouraging. Several impressive smartwatches are now available, including one that impressed me enough to buy it: the Pebble, which connects to iOS and Android phones via Bluetooth.
I find it to be a fun, helpful, and stylish device, but my primary reason for purchasing it is tied to my interest in game development: as soon as I started reading about the Pebble I felt it would be interesting and educational to create a game or two for this unique platform. Because roleplaying games (RPGs) are my thing, I immediately whipped up design documents for a simple 3D fantasy RPG entitled PebbleQuest along with an even simpler game, MazeCrawler, that is in the final stages of development and will serve as PebbleQuest‘s foundation. [UPDATE: MazeCrawler and PebbleQuest are now both complete, as is the sci-fi first-person shooter SpaceMerc!] Creating the virtual world for these games has entailed building my own simplistic 3D game engine: an onerous task, even given the simplicity of my design and of the Pebble platform itself, but also fascinating and instructive, just as I hoped!
And now, with MazeCrawler nearing completion and many exciting developments on the horizon with the release of Pebble SDK 2.0, I’ve decided it’s time to share my thoughts on the pros and cons of Pebble app development and the Pebble smartwatch in general as well as some comments about my forthcoming game apps.
First of all, virtually everything intended for the Pebble OS must be written in the C programming language. This is undoubtedly a “con” for some, but it’s a “pro” in my book, partly because I’m already familiar with C, but also because I have long admired its simplicity, power, historical significance, and pedagogic value. By modern standards C is a low-level language and is thus far more challenging and error-prone than higher-level languages such as Java and Python, but this facilitates much greater speed and efficiency, and by demanding a high level of care and rigor it encourages programmers to cultivate good coding practices.
If you’re interested in building a Pebble app, but are new to C programming, I recommend Stephen Prata’s C Primer Plus, 5th Edition. For those just looking to deepen their understanding of C or hoping for a quick yet thorough tour of the language, I recommend The C Programming Language, 2nd Edition: the classic work by Brian Kernighan and Dennis Ritchie, both important figures in the history of computer science, the latter being, in fact, the creator of the C language and co-creator of Unix who passed away in 2011 (to far less fanfare than Steve Jobs, sadly, but that is a topic for another time).
The simplicity of the Pebble is itself a positive feature in many ways. For a solo indie game developer like me, the small, black-and-white screen can actually be liberating: high-end graphics and memory-intensive gameplay are off the table from the get-go, so there is no pressure to create anything more than a fun and relatively simple game that can be finished in a short period of time. I also personally find it nostalgic: it reminds me of the early Macintosh computers that provided my first significant exposure to the world of multimedia and software development.
It’s also nice that, for now at least, every Pebble on the planet is virtually identical. There’s no need to worry about variations in processing speed, RAM, screen resolution, etc. This makes testing very straightforward: if your app performs perfectly on one Pebble watch, it should do the same on all of them.
Another positive aspect of Pebble development is the fact that the level of competition in smartwatch app markets isn’t (yet) as intense as that of Android, iOS, and other smartphone markets. There is excellent potential for finding a unique niche and attracting significant attention to your app. Of course, this is primarily due to smartwatch markets being smaller, but they are significant and growing larger by the minute: Pebble alone has already sold over 250,000 watches!
Finally, I’m ecstatic that the newly-released Pebble SDK 2.0 (and associated firmware update) provide several improvements and new capabilities, including:
New development tools that make it quicker and easier to build apps and send them to your watch.
Persistent storage and caching of data. This will make saving game progress much more straightforward!
Improved memory protection and logging of memory usage.
Access to raw, 3-axis accelerometer data (i.e., data about the watch’s movement and tilt). I’m not sure yet whether I’ll incorporate this into MazeCrawler or PebbleQuest, but from a game design perspective this opens up many new possibilities! Perhaps I should also start developing a 2D, top-down, maze-navigation game controlled by wrist movements…
Naturally, there are also a few cons to Pebble app development. Foremost among these, in my mind, is the current lack of a Pebble emulator and certain other more feature-rich, Pebble-specific tools to assist in testing and debugging apps. For my purposes, I’ve often been content to use an in-app text layer to report on the status of variables as the player moves about in MazeCrawler‘s virtual world, and the Pebble SDK also includes a handy logging feature that has been greatly improved in version 2.0, but it would be nice to have even more extensive debugging tools designed specifically for Pebble programs. Of course, there is an abundance of resources for general debugging of C code, but these are of limited use when dealing with issues peculiar to the Pebble environment. Perhaps CloudPebble will eventually expand to include more advanced debugging tools, including an online Pebble emulator?
While we’re on the topic of debugging, I suppose I should acknowledge more fully that, yes, there is one significant drawback to the Pebble’s reliance on the C programming language: even with modern compilers, it is a remarkably error-prone language. Knowing this from the outset, I swore I would never read or write past the end of an array or make any other memory-related mistakes, but it has happened a few times, causing my Pebble to temporarily freeze or immediately restart. One time, I even sent my Pebble into recovery mode! At first, I was concerned that I might inadvertently damage my Pebble, possibly even “bricking” it, but so far none of my misadventures have caused permanent harm (phew!) and the latest version of the Pebble SDK now provides more robust memory protection (again, phew!).
Another minor con: the standard C library is not available in its entirety on Pebble devices. This can be mildly frustrating at times, but at most it simply means a modicum of extra effort or ingenuity is required to complete certain tasks, and once you’ve accepted this fact, you may even find that writing your own ad hoc helper functions is yet another enjoyable challenge…or have I gone completely insane?
As mentioned above, the small screen size and dearth of colors may be viewed as a pro or con depending on one’s taste and the task at hand. True, it makes some things simpler, but if you want certain kinds of visual effects—such as perspective, shading, and clear differentiation of surfaces in a 3D environment—don’t expect a walk in the park. Nonetheless, if you have the requisite patience and didn’t sleep too much during your math classes, you’ll find you can accomplish just about anything with the graphics functions, animations, bitmap layers, etc., provided by the SDK. Furthermore, I’m a firm believer that, so long as the overall experience is great, most people are willing to accept “retro” graphics and allow their imagination to fill in the details.
For game development, it would also be nice to have a few more buttons on the device. The Pebble has one button on its left side, usually reserved as a “Back” button, and three buttons on its right side, generally referred to as the “Up,” “Select,” and “Down” buttons.
This is sufficient for many apps, but for games it’s often desirable to have obvious “Left” and “Right” buttons. One option would be to override the standard behavior of the “Back” button and employ it as a “Left” button, but this would likely frustrate some players as it would make exiting the game more complicated (or even impossible, if the game is poorly programmed). I chose to meet this design challenge a different way: in MazeCrawler‘s first-person 3D environment, the player moves forward and backward by pressing the “Up” and “Down” buttons and turns left and right by double-clicking those same buttons (“Up” for left, “Down” for right). Though not extremely intuitive, it is easy to get used to and is at least slightly intuitive if you play the game while wearing the watch on your left wrist: the watch will then likely be tilted such that the “Up” button is slightly to the left and the “Down” button to the right. Apparently many other developers feel the same way: the vast majority of relevant Pebble games I’ve checked out, including Rogue Watch, Pebblis, Pebloid, Paddle Wars, Droptype, and Asteroids, all follow this same convention of “Up = Left” and “Down = Right”. Of course, now that the new SDK is available, wrist movements may be a viable alternative for some games!
Finally, because I currently reside in Taiwan, I feel compelled to mention my disappointment that the Pebble OS does not yet natively support Chinese characters or any other writing system not based on the Roman alphabet. There are a few apps out there that provide support for additional languages, but those apps are still a little bit buggy and the notifications they produce aren’t as “pretty” as standard Pebble notifications, so I would like to see better options in the near future, preferably provided by the official Pebble team.
MazeCrawler and PebbleQuest
I’ve found working on MazeCrawler to be extremely rewarding. Naturally, there are frustrating moments now and then, as tends to be the case for any software development project, but on the whole I am enjoying the experience, learning a great deal, and gaining increased confidence in my software engineering skills as well as my problem-solving skills more generally. But enough about that: I’d like to offer a little more detail regarding what you can expect from my forthcoming Pebble games.
MazeCrawler will offer an infinite supply of procedurally-generated mazes for the player to navigate, the size (and thus difficulty) of which may be randomized or explicitly chosen. The point of the game will be, first, the simple joy of moving about in its surprisingly immersive 3D environment and, second, to complete as many levels and accrue as many points as possible (with larger mazes awarding more points). That’s pretty much all there is to it!
With PebbleQuest, things will get a lot more interesting. Instead of a mere “maze crawler,” this will be a full-blown “dungeon crawler“: it will offer an endless supply of procedurally-generated levels, much like MazeCrawler, but this time there will be enemies to crush and treasures to claim! There will also be an optional “main quest” storyline with several pre-designed levels, but the game will continue indefinitely even after completion of that quest. In typical fantasy RPG fashion, players will have a variety of weapons, armor, artifacts, and spells at their disposal—many of them customizable according to a feature I’m keeping secret for now—and players may choose how their character develops each time they “level up.” I’m tempted to reveal a few more details, but I think that’s enough for now.
If you’d like to stay up-to-date on the progress of these games, keep your eye on this blog as well as the following social media pages:
And finally, please feel free to leave a comment below. I’m eager to get feedback on my game projects while they’re still in development and I’d also love to hear your thoughts about, and experiences with, Pebble programming.