CREATOR VOICE: GAME DEVELOPER MASTERCLASS
The Online RPG Masterclass
How we built “Amazing Creatures” in two years — the full story
In November 2017 I had an idea for game that would be my ultimate tribute to the brilliant games I played as a kid in ’90s and early ’00s. These are games that actually had a story, mystery and novelty. I’m talking about Crash Bandicoot, Metal Gear Solid, Final Fantasy, Deus Ex, and Silent Hill. These kind of games.
Notice the low-fidelity modeling, bright textures, crude environments, simple lightning — the kid in me should thank the simple graphics for letting his imagination flow. I wanted to make a game that’d remind guys like me of games we used to play back then.
Before I go into detail, I’ll just say this: yes, we decided to make an MMORPG (which stands for “Massively Multiplayer Online Role-Playing Game”). One of the questions I come across regularly, especially from people on the internet who might be interested in making games, is this: is it hard to build an MMORPG? People also tend to wonder what skills are required to create one, and there are many other associated questions. Well, I’ve been working on my own MMORPG for around two years. Now that it’s released, I’d like to share my experience with you. I hope that this article answers some of the most burning questions about MMORPG development — and, indeed, game development in general.
But to go back to the first question: Yes, it’s quite hard.
Imagine the greatest challenge you could possibly endure in product development and then some. Building an MMORPG is even tougher.
Now, this is a long article and it covers a range of topics in great depth. So I’m going to begin by providing a table of contents. This might help you to skip to sections that are particularly relevant for you. Also, I’m going to kick off this piece by exploring a couple of basic topics that I believe many founders and developers simply don’t pay attention to.
FOUNDATIONS
1. FUNDING
2. SUPPORT
BUILDING YOUR GAME
- Should I possess any development skills?
- What does building an MMORPG look like?
- How long does it take to build an MMORPG?
- Why is it so expensive to build?
- Is it hard to build a multiplayer server for an MMORPG?
- When should I optimize my game?
- Where do the ideas come from?
- What is and what is not core gameplay?
- Versioning
- Fun facts/challenges
- Is it a good time to develop my game?
- The bonus part
- About the author
FOUNDATIONS
1. FUNDING
If you already have investors or you were lucky enough to be funded in some other way, you can completely skip this step. The reason is simple: you already have partners and investors, and they can give you far better advice than I can.
However, if you have an idea — or you’ve already started your project — and you aren’t currently funded (especially if you plan to build an MMORPG using your earnings or savings), I really encourage you to read this section.
Secure your funding before you start.
In simple terms, this means you need to understand how much money you require and then enter into an agremeent with yourself that you’ll be burning that money.
Let’s say you saved $10K and you plan to develop your project using those funds (and let’s say that’s your total project funding at least for now). The next step is to ensure that these funds are not impacted by anything but your project. Don’t gamble with it, don’t invest it, don’t spend it on living, don’t play the market with it, don’t buy gold with it, don’t buy stocks with it, don’t lend it.
Game development is hectic and will affect your nerve. Don’t let it affect your funding. Always remember: if you lose your funding, you lose your project. You will lose your team. You will carry enormous regret.
This advice comes from my direct experience. In fact, it’s been a very tough lesson learned. I kicked off my project during a market decline — I was already losing money, but there was a chance that the market would recover and everything would work out. At the time, I didn’t think too much about it, because a) my pockets were pretty deep, and b) the market should recover one way or another, right?
Wrong. After more than two years, the market is still in decline as of March 2020. I witnessed my funding shrink to zero within the first 9 months back in 2017–18.
Take this from me: withdraw and secure the funding you need for your project. Period. Sure, there will never be enough funding to support all of your ideas, but at least you’ll be working from a stable and predictable resource pool that isn’t shifting under your feet.
This is the sort of conversation you may already have had if you have secured an investor of some kind. Either way, it’s important to get this bit right before you dive in.
2. SUPPORT
I was lucky.
Everyone — those who heard just a bit about my whole endeavor, those who saw the early process, my family and friends, even strangers who didn’t really know me — they were all quite positive about what I was doing.
Not every one of them understood the game or exactly what I was doing, but they were still largely positive.
You may not be as lucky. Your relatives may frown upon you making a game. Your partner may not understood why it’s important to you. And your friends might tell you you’re doing useless stuff and acting like a child.
Earlier I said that game development will affect your nerve. This is bound to become an even bigger problem if you don’t have the support of those close to you. Unless you really believe in what you’re doing and you’re willing to risk both your wellbeing and the wellbeing of the people around you in achieving your goal.
I mention all of this only because it’s important to plan around these aspects before you embark on such a massive and consequential journey. But I don’t want you to lose sight of the fact that building your game from the ground up will absolutely provide you with a feeling of empowerment — you’re creating something great, something that others will appreciate and be thankful for.
There will be moments during the journey that you may believe you’re making the biggest mistake of your life, your game sucks, you’re re-inventing the wheel and you suck as a person. Take a deep breath, go to bed, and wake up to a new day; these are small bumps in a long road, and perseverance is key.
BUILDING YOUR GAME
1. Should I possess any development skills?
This is one of the key early questions that people ask when thinking about building a game for the first time. It’s a reasonable question.
There are really two options. Either you have development skills or you possess other expertise that can’t be easily outsourced or hired. Maybe you’re a strong writer, or a great project manager, or a superb designer; there are many different types of skills you can bring to the product. At the end of the day though, technical skills are most valuable when it comes to the early stages of production. Why? Well, put simply, developers make things happen. You can have the best UI in the world, but who cares if it can’t be interacted with.
Let me give you some context about myself. I’ve built 4–5 products single-handedly as a jack of all trades. I’ve shipped 8 products with my own teams as a designer/product manager. And I’ve contributed to other peoples’ projects as their designer/art director/creative director working as part of their cross-functional teams.
This experience played out over about 15 years, during which time I learned to code — web and mobile apps, server backends — and learned a few programming languages that were entirely new to me at that time.
So bear that in mind when you consider my perspective here. I personally believe that it’s important to have solid development skills and a solid technical background if you want to build a web/mobile product.
Let’s break this down into a series of benefits and downsides.
Benefits:
- You understand the real state of your product. This is likely to be useful when talking to investors.
- You can help your developers.
- Since you know how to build a feature, you can effectively explain it to your team.
- If you have a crazy idea, you don’t let it slide to a to-do list if you have no idea how to code it. Meaning, your virtual cat feeder simulator may not really be in desperate need of integrating VR+AR sitting on Blockchain.
Downsides:
- You will be held accountable for virtually everything from scripts to UI implementation.
- Your team may rely too much on your help (which may mean that you can’t pay attention to other important tasks that require your attention).
- Your investors may not like you having that much control over the codebase and the product. Yep, first they liked it and now they don’t; it can happen.
All things considered, I’d still say it’s a big “yes” and a huge advantage to have development skills rather than to have no coding expertise at all. You’re building a product underpinned by technology, after all, so it’s important to understand what’s going on under the hood.
Bear in mind though that none of this implies a requirement to be a technical expert or a dev superhero. Some technical knowledge is better than none, and in general, the more you possess the greater your ability to drive your project forward.
But let’s dig one step deeper and consider this from another angle: building a client-side app versus a server-side app.
Why do I draw this distinction? Simply because you definitely don’t need hardcore skills to code a client-side-only app.
The very first Amazing Creatures release was a standalone sandbox mobile app. It was a single-player experience with all calculations done on the client side. It took me about two months to create all while I was learning Unity from the ground up. This experience turned out to be very useful. Going forward, I was using the client-side app as a skeleton model for the future client-server app. I wasn’t familiar with the game engine (that is, the components-driven development in Unity), so coding a client-side app provided me with a general understanding of how stuff works.
Q: Why code only a client-side app for an online multiplayer game?
A: Test ideas, test concepts, test gameplay, test eser experience, test VFX, listen to in-game music, proof-read everything as it’s experienced in-game, and maybe (maybe) on-board a few beta testers. Maybe, even on-board an investor or a fund with your demo.
Lean start up people would call this “coding an MVP”. But meh. I don’t think public MVPs or prototypes work really well with games. I don’t believe that games/movies/books are valid cases for pushing a release date out and delivering a smaller experience early — well, actually, I think it can work but only if you’re a well-known developer (like, say, Blizzard, Square, or Bethesda). In that case, sure, you can provide early access, early marketing, and so on.
But in my view — and for totally fresh/new studios like my own — I believe that going for the best quality and a more complete experience is the main way to win fans.
2. What does building an MMORPG look like?
Remember how fun it is to play RPGs. There are lots of quests to discover, lots of items to use, lots of characters to meet, and often a 50+ hour long story (as well as various side-quests that might easily add another 50 hours to that).
So, if you’re looking to actually build an RPG, you’re looking at the prospect of creating a ton of content, and translating that into a massive amount of game assets. Otherwise, it’ll simply be no fun to play your game — it’ll be too small to explore.
What’s the difference between an RPG and an MMORPG in terms of game assets? The key difference, as you might expect, is the number of people that are going to play it (and do so simultaneously). It’s one thing to create a single-player RPG, but an MMORPG is an entirely different beast — think experiences and interactions.
In a single player game, you are the protagonist. Your experience is totally unique and game interactions are designed to satisfy just a single person (you). But in a multiplayer game, your interactions may lack novelty (that is, some other player had that interaction before you). As a result, novelty isn’t part of a multiplayer game concept. However, variety is.
The more entities you have overall, the better chance you have at providing a unique interaction to the player. Something that hasn’t been spoiled by forums or player’s friends.
I think of it this way — at a single-player game 1 interaction equals 1 unique experience, however at a multiplayer game 1 interaction equals 1 unique experience multiplied by entity rarity and divided by the total number of players.
An example, perhaps.
Let’s say there are two entities (quests, NPCs, mobs, spells, items) in our game. One is quite common, the other is an ultra-rare legendary entity. We assign them a “rarity multiplier” — unseen by the players, purely internal stuff — a 1 for common entity and a 5 for a legendary one.
Now for a single player we have 1:1 chance of encountering a common entity and a 1:5 chance of encountering a legendary entity. Which means the player clears an interaction immediately for a common entity, and once in 5 draws the player will clear an interaction for a legendary entity. (Discounting the relativity here.)
As the players count grows so does change our approach to estimate interactions. A common entity now has a (1*1)/count chance of the interaction being unique. A legendary entity now has a (1*5)/count chance of the interaction being unique.
What’s the catch? The catch is that we always want an interaction to be unique, that’s the whole idea. Well, sure, we can’t make every single interaction unique, but at least we can provide that for some key entities. That’s why we have a “rarity multiplier” in the first place — to balance out the number of people playing the game (simultaneously).
The boring part would be guesstimating the number of interactions and experiences for your entities, and then coming up with a list and count for how many entities you need to maintain a non-repetitive playing experience. Equals sign fun experience.
What I’m talking here isn’t connected to art, sketches, stories, modeling or development. I’m talking about having a design document. And it won’t be a fancy book featuring characters art, their backstories and an intro word from your lead 2D artist.
Instead, it will look like this:
Boring, right? Also, very far from some magical path we took to make the best MMORPG of all time. Okay, well, let’s get to the fun part then.
Many people underestimate the amount of resources required to ship a game, let alone a MMO, let alone a MMORPG. I even got a message from an industry veterans saying that, hey, making graphics isn’t the most time consuming piece of the puzzle.
However, my understanding of games is that art quality is synonymous with game quality overall. And my design experience tells me that excellent art quality can take a substantial amount of time to achieve. Also, you of course need a decent story and lore to hook players as well as decent gameplay to make them want to play in the first place.
So let’s jump to graphics, then. This is my favorite part of the creative process. I’ll jump right into the (heavily summarized) creative process we went through during the development of Amazing Creatures.
THE APP
Day 1
This was our “idea” stage. I designed a layout that didn’t actually change that much towards the final release.
Day 60–Day 120
Left-to-right, three core game modes. A virtual pet simulation, location-based treasures, quest hunting, and a collectible cards PvP mode.
Day 150–210-ish
What took you so long, Snake?
That’s some 210+ days separating left “picture” from a playable production-ready, event-driven, location-based player-vs-player mobile MMORPG (below).
MODELS & ANIMATIONS
That’s the super-quick run through. It doesn’t include all the changes/iterations, new features, deleting bad gameplay, improving existing gameplay, adding content, writing stories and chapters, and so on — it takes almost a year to create and visually polish an MMORPG.
Also, let’s not forget that this effort and elapsed time comes from someone who has spent his last 15 years in creative/design roles and has development skills and is able to dedicate full-time hours to work on his dream. Consider how any changes to any of those dimensions may dramatically impact the time required to build something like this.
Now, in case you think I’m big-noting myself when I talk about experience, let me point out why this experience matters:
- You can estimate if something is good enough to ship.
- You understand what needs to be done right now and what can wait.
- You know if you hired the right people for the right job.
- You know when and why it’s time to let go.
- You know patience, resilience, and dedication beat talent.
- You know luck beats the above.
- You understand luck is a part of the journey.
- You understand luck is not a part of the equation.
You’ll notice a theme here. None of the above points relate to knowing Adobe Suite, 3D modeling, 2D graphics, computer science, and maths? Exactly — none. Experience nets you the soft skills first and foremost.
Mind you, I’m not at all discouraging you from trying to build a great MMORPG without having years of experience. Quite the opposite, in fact! I’m just saying that all those years massively helped, and I can’t imagine going through a project like this without having that.
Have a look at a complete creative case at my personal website: https://cases.pekanov.com/amazing-creatures/
Here are a couple of demos that show the transition between simulated gameplay (left, After Effects) and the real thing (on the right, Unity Editor screen capture):
3. How long does it take to build an MMORPG?
It took us 8 months to take off with all the groundwork — creative and coding considered, then 7 more months to code the networking and bug test the game, then 5 more months to build an MVP (sandbox single player) and then me alone working 10 hours a day for 5 more months straight (6–7 days working week).
Speaking of which: for a 7 person team, that is… drumroll… a whopping ~23,900 man/hours. Since I’m counting hours here, this will be a good guesstimate into the kind of funding you may need for a MMORPG.
If a team member’s average hourly rate is somewhere in the $50–150/hr range (depending on your region) and if you won’t be paying yourself anything as a proud founder, then you’ll be looking at $350K-3.5M to make your MMORPG with a small full-time team over the course of 2–2.5 years. Thank god there are outsourcing web sites, right?
My math here isn’t dollar-to-dollar accurate, since for the lower end I’m assuming you yourself work at zero salary, you don’t pay office rent, you don’t buy any equipment, you don’t buy any expensive licenses, you have some people working for free or very cheap, you may have some friends in, etc... Just to give you a realistic figure how much it may cost on the lower end, provided you can hustle. If you can’t manage the above lower end hustle, then at the lower end alone you will be looking at a $500k–1M figure.
Again, that went into a game that is relatively small considering its genre. Not tiny, not simple, but just not the same starting scope as the major players. If we were to create just x10 more assets and stuff (which was my original plan), we’d be looking at, I really don’t know, 4–5 years release time, at best? And we’ll still be x10 times smaller than, say, WoW or EvE. At least in terms of the sheer volume of content.
I must add that building a serious game isn’t a race.
You won’t be able to sprint through all of your ideas and just code it in a week/month. It will take time and patience to deliver. You will validate and try ideas, and that will take a lot of time.
4. Why is it so expensive to build?
There are a number of reasons why games, in general, are expensive to make.
For one, and as I pointed out earlier, games don’t make good candidates to be “lean-MVP’d”. You’ll be building your game to the point where it looks good (at the very least), which means quality art, sound, music, and VFX. These aren’t the cheapest building blocks. Other areas (like functional engine and networking) aren’t cheap either, because they aren’t areas you want to compromise.
Then it’s so expensive because as a fresh company building an entirely new product you will have to spread yourselves in as many directions as possible, as early as it makes sense.
Each direction extends your roadmap with a new branch. Each new branch adds to your development cycle. Each development cycle iteration adds to backlog and tech debt.
You’re literally snowballing ideas until you say — OK, we’ve had enough, it’s starting to look pretty good, we can put all new ideas to where they belong — their own ideas backlog.
You may well say: “Hey, let’s not experiment then — if it’s so expensive to test every new idea, let’s just build something similar to what others are doing.” Sure, that might work. It’s called building a clone, and that’s fine.
But if you’re really looking to build something that is genuinely your own — something your life and heart went into — you’ll need to experiment. I’d like to show you a few experiments we ran with Amazing Creatures.
First, we had an entirely different way of onboarding players. We’d start by telling them what their device is capable of. Actually, it’ll be better if I just show you. It looks like this:
We ditched this entire concept eventually; we felt that everyone basically understands how location-based games work. In the end, we felt that there was no need for such a literal introduction to how the actual device works.
In the final release, we introduced players to the concept of Avatars, Creatures, and The Realm through our onboarding quest (tutorial). Our tutorial is executed in a sequence of “chapters”. Each of these contains tips familiarizing the player with the gameplay, concepts, and lore:
This wasn’t the only change. We also revised the concept around Creatures and Portals.
Originally, players needed to capture or summon their first Creature. In fact, people could play the game without Creatures at all. Yeah — in a game that has “Creatures” in its name…
We started with the idea of a Void that players had to Claim. It then became an Unoccupied Space, and after being occupied, it would turn into a Portal.
I emphasized these four concepts in bold to point out that we had four (four!) gameplay entities for a very simple, essential, and straightforward gameplay scenario: getting a Creature. But it’s obviously convoluted. I don’t think anyone would have been enthusiastic enough to go through all of that.
So we tackled this by first changing how the game started. In the final release, a player always has at least one Creature — the one that’s provided at the very start. The Portals are treated simply as “free space” to host Creatures. Finally, there’s a dedicated screen to explore your bestiary:
The above examples just barely scratch the surface — in the early stages of development, we had an entirely different approach to almost everything.
So if you ever wondered why games are so expensive to build, this is why. There are lots of ideas and experimentation required before finally getting things right and settling on a final approach. I’m sure it’s probably quite similar to writing books, or filming movies, or creating any other kind of commercial art.
5. Is it hard to build a multiplayer server for an MMORPG?
Yes. And no. It really depends how you define “hard”.
I’m not kidding, either. It’s not that hard. It’s difficult — debugging broken code that worked yesterday is frustrating, and things can be ultra-tense during the final month of testing — but it’s not actually that hard once all the groundwork has been laid out.
Perhaps the most accurate (and most encouraging) answer here is: it’s much more doable than you probably think.
Remember, I’m no expert or coding guru. I’m a self-taught developer who sucks at theory, computer science, algebra (and mathematics in general). I’m a graphic designer at heart.
So, I had no idea what inheritance was conceptually, yet I employed it. I had no idea what polymorphism was, yet I also employed it. I still don’t understand the performance difference between a (switch case) statement over (if else) or (try catch); neither I find using (while)s a problem. And I didn’t do the most complex pieces, like coding the load balance and on-the-fly server instances initilaization.
Consider the genre. All in all, MMORPGs are one of the most complex types of games out there. There are lots of graphics, lots of human players interacting with other human players. It’s that last bit that’s most difficult.
Bear in mind too that your MMORPG server is, in fact, a blackbox. You can log stuff left and right, you can save states to file and review later and such, but — in general — you have absolutely no idea what’s happening at a specific moment once your concurrent player count goes past you and that guy. In MMORPGs, lots of stuff is happening at (virtually) the same moment.
This leads me to my next point, which is to say that you’re looking at building a very capable engine that will serve your game logic and states in realtime for any number of concurrent players. Well, theoretically speaking.
To mitigate the unknowns we’re using our own event reporting system along with so-called “HeartbeatX” events. Basically, we’re pinging players states back and forth and emitting events. Like everyone else, nothing new here.
Here’s one of the heartbeats functions family, function HeartbeatWorldmap(socket):
The tricky piece here is that this function calls two different layers. Which in turn means we’re keeping game data at two different separate layers instead of having everything on a shared world map layer. Thus we separate apples from apples:
- Globals is designed for human Avatars, wandering Creatures and static Treasures (loot boxes). All human-vs/to-human interactions are processed on Globals layer (but aren’t stored just there, because why would we want that if a player never entered the world map, right?).
- Locals is a dynamic collection (array) of map tiles that holds NPCs (regular Avatars, Role-based Avatars and POIs), generated wandering Creatures, and generated Treasures.
This is a pretty smart solution, if I do say so myself. And of course, the main “worker” there is CheckRespawn(), since it’s firing the actual updates to the client side based on player proximity and actual world map availability. So, yeah, no world map ping-pongs if you’re chilling at the main menu.
Now, what about that load balancer and instances initialization, you’d ask? So far I’ve got just the initial code and logic to get to that, reason being it’s not a pressing issue right now.
I talked to a few solid developers. They were all talking the game server needs to sustain at least 1,000–10,000 simultaneous connections. The server should be capable of serving 1,000,000 players at the very least. Bear in mind, though, that this isn’t something that’s going to happen at the moment your game launches. Not only are these numbers massive — and unlikely — for a brand new game, but the infrastructure required to sustain that number of players would be utterly redundant so very very early, when it isn’t required.
So, don’t think (for now) how your server is going to handle a million players.
Think about how you’ll get to that number in the first place.
This doesn’t mean you should entirely ignore potential needs around load balancing. I have implemented a soft cap and hard cap for the player count. Our server tracks the number of total socket connections (where a new socket opened equals a new player joining the game). Well, actually, a new socket may not always equate to a new player — if a player disconnects right away or joins from another device, they may temporarily have two socket instances for the same player entity for about 500 milliseconds. Reaching the soft cap merely produces a logged warning on the server end. It doesn’t interfere with the player’s experience at all — it’s purely an internal concern (it will trigger a new server instance initialization that stays hidden on the client side). But if the hard cap is reached, the player who is about to log in will be notified that the server is full and will be asked to select a less busy server instance to join. At this point, our new server instance becomes visible on the client end.
The toughest part is keeping the experience consistent regardless of the number of instances. We don’t want players joining an empty shard processing its own game state while there are a bunch of people playing on a shard that’s at full capacity (and running its own independent game state). The shards have to be dynamically initialized while the game state must be shared across all of them.
Needless to say, there are multiple ways you can scale your game. Many of the different techniques can be combined, too. But this really warrants its own specific article.
Here’s a good read on database sharding, if you’re curious: https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6
6. When should I optimize my game?
You will find many articles teaching you how to optimize your code and assets, work with profilers and debuggers, read logs, etc... You will come across many optimization techniques and best practices.
a. Should I optimize early?
Think how long it’d take to build your game. Is it days/weeks/months? Is it years? Think how often new hardware is being released and compare previous generations to current generation specs.
Here’s the thing. When your game is ready to be released, the future hardware will be superior to your current hardware to a state that your current top-tier device is future previous generation device.
Say you started mobile game targeting iPhones. You started in 2010 and the top-tier device was a new iPhone 4. Then your game has been built and polished, it took you a few years (since your game turned out to be very complex) and now you’re ready for the release in 2015.
What’s the gap between iPhone 4 in 2010 and iPhone 6 in 2015? It’s massive. Not only the software (iOS) different, but there’s a massive hardware and specs upgrade. You would’ve wasted a lot of time if you were optimizing for iPhone 4 at the very beginning.
So talking about optimizations, there are very few core concepts that you must follow, and then there are a lot of platform/software/hardware-dependent concepts that you should take in account (but no more than that, until you’re ready for the real thing).
That’s why I’m saying don’t optimize early for the target device, as this will change. Optimize for the platform, optimize for the concepts that can’t change:
- Conserve memory. Re-use and pool objects. Conserving memory will always be an issue, especially in mobile gaming.
- Minimize realtime frame-by-frame monitors. That’ll eat up the CPU. Most of the time your in-game events are… well.. events. Events have start and end time, you don’t need to check up on them frame-by-frame.
- Code considering lags and delays. Localhost is instant and fast. Remote will be not.
b. Should I polish my code?
This is perhaps a controversial question.
You will find people saying they always polish and refactor their code early, just like you will find people saying they leave it until they can’t go further with the old code, just like you will find people saying it’s not a task but a routine.
My take is that you should understand which parts of your code will/can change, and which parts aren’t likely to ever change.
For instance, it’s less likely to have a change in code setting up a database connection than it is to have a change in code pooling these connections. You’re less likely to change your login function than you’re to change your leveling-up logic.
It’s not that simple. You need to sit down and have a good look at your code. It may take you a few hours now, but this alone will save you days if not weeks/months later on.
Now when you have an understanding which parts of your code are very likely to change (fluid code), mark them so you won’t forget. Leave a comment on their dependencies (for e.g. changing avatar name → avatar profile, using a power → creature).
Now when you have a list of fluid code and dependencies, you have your list of code you will refactor. Optimize and polish each time you change something there.
And that answers the initial question — it’s not a question of “should you”, but rather a question of “how you should”. Personally, I’m excited to refactor my code. This means something’s outgrown its square pants, this in turn means the product is growing.
c. Should I test my code?
Absolutely.
I can’t stress enough how important it is to test your code. You should always be testing things. Like I wrote before: in MMORPGs lots of stuff is happening at virtually the exact same moment for lots of your active players.
How to be sure your code actually works for all of them? How to be sure your server won’t crash for one of them, thus invalidating lots of data for everyone else?
I can point out a few critical bits among all the things I’ve tested:
- Simultaneous script execution. Say, two or more players do something that may/will collide. For us that is initiating Battles (ambushes), initiating Creature Summons, capturing Creatures and picking up Treasures on a world map. A collision is a server-side event, and the client-side app must know about it, it has to be accounted for.
- Incomplete data. Say, what if a player is on a slow connection so the server response is delayed. Vice versa, what if a client-side app is too slow to send its response to the server.
- Excessive data. For us that is when a player jumps world map tiles, thus leaving the proximity area of previously spawned objects. Out-of-proximity objects don’t need to be rendered on the client-side app, they don’t need to be pinged. Just like you don’t need to send status updates regarding offline players, or players that are in their own local context (for e.g., if they were ambushed by some other player).
- Incorrectly formatted data. I was late to discover that a floating point number can actually be a floating comma number at some platforms/locales. That led to floating point numbers being treated as integers, therefore creating a huge mess instead of picky precision. Conclusion: never assume server receives client-side data in correct format, never assume client-side app correctly interpret server response. Instead, you should be getting JSON objects and parsing them.
- Realtime parameter updates. Our Avatars traits and Creatures stats are updated in realtime and are multi-parameter driven. Simply put, multiple Avatar traits can change simultaneously and affect other things, like for instance a Creature’s bonding rate (simple) or Avatar’s proximity distance to be ambushed (complex). Vice versa, Creature’s stats affect Avatar traits. Since it’s the core part of our game logic, this had to be excessively tested under multiple conditions.
d. Trust yourself.
There will be a moment when you need to look up what exactly a certain function does in order to optimize another function.
Or more like, you started optimizing function B. At some point your function B is calling A. You don’t remember what exactly A does, so you decide to have a look at… what?!
You forgot what A does, why it’s there in the first place, why it’s so poorly coded, why it’s calling this instead of that, why the function name is saying “A” while the function itself seems doing “C” and so forth.
Here you should take a deep breath. You’ve spent a lot of time already. You’ve spent nights on that particular function. Trust yourself. Trust you’ve done your best on that piece of A.
Oh, and don’t forget to attend to that A once you’re done with B. If you were confused about it, maybe it’s time to give your A a fresh look (more like a fresh stare).
7. Where do the ideas come from?
At some point mid-way through, we had multiple projects running.
We were working on Amazing Creatures (our main title), we had its standalone prequel design document in the works, we had a design document draft for a QTE isometric puzzler, and we had an experimental crypto game at an internal pitch stage.
It may sound weird, but all those multiple side-projects were beneficial to new ideas for our main title, because new ideas came from new ideas.
Perhaps, I should rephrase. New ideas came from different new ideas.
The Amazing Creatures prequel allowed me to solidify our main title lore, and hint on the protagonist. An isometric puzzle gave ideas on Avatar traits and Cards crafting logic. Oh and that crypto game helped me understand we need to focus on our main title, instead of trying to jump on a train that long departed our station.
The downside? Well, at some point I was thinking hard whether we should release the prequel first, since the story and gameplay started to turn out so fun and cool.
8. What is and what is not core gameplay?
One person, small group of friends and a fresh game development studio have one thing in common. They all have limited resources.
Which is why it’s important to understand the essential “core” gameplay your game is going to have early on and the foundation you will later grow should your game succeed.
My definition for core gameplay is that it is a set of features you can neither add to nor subtract from.
What this means is, +1 feature won’t benefit the game while -1 feature will break the game. Another way of telling is that adding a certain feature will be good for an update or an expansion pack, while removing a certain feature will eliminate the context for it in your future update.
Let’s say having location-based eandom encounters (RE) is a planned feature at your back-log (it is at ours). Question is — what other production-ready feature can not live without having RE? If the answer is “no other feature depends on having RE”, then having RE is not a part of your core gameplay.
Alternatively, say you decided to ditch detailed avatar profile and leave out just the avatar name and gender. Assuming you’re building a RPG, not having a place for player stats and attributes will break your game, because there will be no way of visualizing avatar progress for the player. Which makes avatar profile a core feature.
Once again, your entry-level goal would be defining what is and what is not your core gameplay.
For example, in Amazing Creatures the core gameplay is a mix of the following concepts:
- Roam. Keeps a Creature happy. Basically, a pet simulator.
- Journey. Interacting with other players on a world map.
- Clash (Battle). Challenging other players to a game of cards.
(I believe the most accurate definition for our game genre would be “a collectible cards location-based PvP companion pet simulator”).
Together these pieces compose our core gameplay:
Each of those pieces could’ve easily been their own downloadable game at Google Play Store/Apple App Store. However, since they are all connected they should be treated as an irreducible core gameplay scope. Here’s how various in-game features are connected to core gameplay scope “domains”:
- A player can Summon a Creature. [Roam]
- A player can Capture a Creature. [Journey]
- A player can transform (Shapeshift) a Creature into a card. [Roam]
- A player can compose a deck of cards. [Roam]
- A player can see other players around him. [Journey]
- A player can attack (Ambush) other players with his deck of cards. [Clash]
- A player can capture (win) or lose card to another player. [Clash]
This is our list of core features that makes Amazing Creatures a playable game. Though, the final goal is to also have an enjoyable and re-playable game on our hands. So here’s a list of add-on features that are making our core gameplay complete:
- An Avatar has Stamina, Agility, Magic, Power, Luck and Energy stats. Shortcode: S.A.M.P.L.E stats. [Universal]
- An Avatar has traits. [Universal]
- A Creature has Statuses. [Universal]
- Statuses grant Affects. [Universal]
- Affects influence player Avatar’s traits and/or stats. [Universal]
- A combination of Creature’s bond and Avatar’s traits and/or stats influence card strength and value. [Clash]
- A player can Summon a Creature with another player. [Journey]
- Every Creature is unique. [Universal]
- A player can add other players to his list of friends. [Journey]
- A player can use Artifacts and Powers. [Roam, Journey, Clash]
- A player can imbue Runes into cards affecting their strength and value. [Clash]
- Every card is unique. [Universal]
- A player can fuse Magistones into Creatures to grant them Powers. [Roam]
- A player can get extra items from Treasures. [Journey]
- A player can interact with NPCs. [Journey]
- A player can mug another player, the other player can evade. [Clash]
- …(the list goes a bit further down)
While we could have gone with the first list and get our core gameplay early, I think it’s far more important to have a game that is enjoyable and fun rather than a game that is faster to ship.
So what is the core gameplay? A list of features you can no longer subtract from OR a list of features making your game complete?
Since the very definition of “complete” is highly subjective, I believe the truth is somewhere in-between and there’s no secret recipe. You and you alone decide when and whether your game is complete. Therefore it’s up to you, the game designer, to compose a list of core features without stretching your available resources for far too much.
9. Versioning
We use both version codes — Application Version and Bundle Version Code (Unity) — to identify our builds. The first is to identify our app’s Major Version, the latter identifies app’s current sprint.
Usually you’d come across a version number that goes as A.B.C — where A is the major, B is the minor, C is a patch. There are also standard conventions on versioning (https://en.wikipedia.org/wiki/Software_versioning). So why re-invent the wheel then?
While we were at the Closed Beta testing stage, we wanted to make sure the players had the actual playable most recent app version.
Players could’ve missed the update e-mail, we didn’t expect them to check Google Play Store app page, we didn’t expect them to track and even notice the current app version either. So what would be the solution to make sure they always used the updated app?
The above is an if statement checking the player is using the most recent app (version in our manifest file is exactly the same as the player’s Application Version). And if it’s not, this is what players see:
The Bundle Version Code (Unity) is used just to update the Google Play Store, it’s irrelevant to the app. For example, we can have a minor visual patch that doesn’t affect the gameplay at all. Or some other client-side fix that doesn’t require a back-end update. Both affect Bundle Version Code, both result in a new app build (and Google Play Store update notification) but none of them update the actual Major App Version (the one in our manifest). None of them require the player to update the game, since none of them affect server game logic.
However, any small change to back-end logic that requires even a tiny client-side update will increment the after-point part of our manifest Major App Version (I can just say it will increment the Minor). This way we ensure there’re no client-side bugs between new apps and outdated apps.
This approach also allows us to roll-out updates faster, since we can deploy updates directly to our website not waiting for the processing/approval at Google Play Store. However, a limitation would be that we needed to build armv7 and arm64 ourselves in order to have .apks for different architectures.
We’re most likely to switch to major-minor-patch convention shortly after the Public Release and allow players continue playing if, for instance, we rolled-out just a small patch. Also distinguishing between patches and minors. This will be the next phase of our compatibility resolution.
10. Fun facts/challenges
One of Amazing Creatures’ core traits has been inspired by a very-very old and very physical game — Tamagotchi, a Japanese handheld pet simulator created by Akihiro Yokoi and Aki Maita. Yep, you heard that right, that’s a device first released more than two decades ago.
Originally, I wanted Amazing Creatures to be quite punishing. The game was supposed to be linked to the physical device. No reset/restart button. No uninstall and reinstall option to get a fresh account. Player’s mobile phone was supposed to be sort of a portal to the game itself.
See where this is going?
But then I saw that there’s virtually no way of linking a device to the game. Due to security concerns and GDPR, (now) there’s no way to have a reliable and permanent Device ID that can permanently identify user’s mobile phone (I mean, the ID that can not change under any circumstances.) I write (now), since there were no issues storing Device IDs as of 2014, the time I coded an iOS app doing exactly that.
So I changed the above concept.
I’ve added login and password authentication to the game.
Did I really add that to the world of magical Creatures, Artifacts and Powers, Magic (well, in general) and essences that crystallize in physical form? Did I really add login and password to the world that is beyond The Rift (a made up event that happened in another dimension and connected our world to “their” Realm)?
Okay, not really. I did add the authentication, but with a twist.
Remember Omikron (1999) by Quantic Dream? It’s one of my favorite games, even though I never managed to finish it.
This happens at the very start. See that bit of creepy storytelling that’s saying your soul is now a part of their world? Game designers broke the fourth wall so that the player can become the game avatar. So you’re really out of options there. This also hints on the very concept of the Nomad Soul, which players discover later on.
That was brilliant! I didn’t know any games doing that back then. Well, frankly, I don’t really know if anyone besides Quantic Dream is doing storytelling that cool. Oh, yeah, if you don’t know who are Quantic Dream, they were behind Fahrenheit and Heavy Rain.
Regarding authentication. I wanted to create something that fits the game lore and looks familiar to the player at the same time. So how about a player opening a Portal to The Realm, and thus logging into the game?
Portals are already part of game mechanics — Avatars open them to summon new Creatures. Opening a Portal is already part of the lore — Avatars are people with special knowledge and ability to produce a Calling to open one; actually that ability is a single thing that makes one the Avatar.
Maybe I need to pause here and provide a quick intro to Amazing Creatures’ lore:
That’s why players are called “Avatars” in-game — they can open Portals to summon Creatures. If you’re curious, here’s how it goes:
- The Avatar has the ability to acquire Ester, an immaterial essence granting certain magical powers. One such power is the ability to open Portals.
- The Avatar focuses Ester to open a Portal to The Realm.
- One of Avatar’s Creatures produces a Calling, literally calling to another Creature at the other side of the Portal.
- The Creatures at the other side of the Portal may join the Avatar.
As for The Rift, it was the initial breach between our world and The Realm. That’s how the first Creatures entered our world.
I think it’s an authentic and fun way to start the game; much more fun than simply logging in:
- It familiarizes the player with the core game concept (Portals).
- It’s entertaining, engaging and encourages “playing”.
- It provides an early intro to the game style and lore.
- Rune Sequence is a cool game design element that can be re-used later on for unlocking Treasures, Crafting, Quests, etc.
And it all happened because of a simple limitation on using physical Device IDs.
What about the original idea? Well. Playing Amazing Creatures is still challenging and can be punishing. You just don’t have to buy a new tamakeitaidenwa anymore, if you screwed up your game.
11. Is it a good time to develop my game?
When I was 12, my parents bought me a book as a gift. It was How To Make A Game Like Doom and it came with a CD full of content. Supposedly. I never found out, since the CD was corrupted and didn’t initialize.
The book was full of code screenshots and code listings; I think it was C and ASM. The book was ostensibly going to teach you to code your own game engine and network code — think like John Carmack. In a way, it’d teach you to be a developer no less than John Carmack. Or so the writer thought.
What I’m saying is that these were the times when you had to code your game IDE, code your game engine and code your game logic all by yourself. There were very limited IDEs, no helper tools, no StackOverflow, the internet was poor, the platform specs were shit (though, we were told 64K of memory should be enough for everything and everyone), the displays were monochrome and a Mac was called Apple Macintosh.
Today we have powerful IDEs coming cheap, we don’t have to pay a huge licensing fee to use a powerful game engine, we can consult with developers from all over the world via StackOverflow.
Is today a good day to start developing your game? If that’s what you’d like to do for the next months/years, it absolutely is.
12. The bonus part
Achievement unlocked!
For those who’ve read this far, here’s the Amazing Creatures Official Soundtrack.
It’s very beautiful. Sit back, relax and enjoy.
Amazing Creatures, the game:
Chasing Dreams Games:
About the author
Pavel Pekanov is a seasoned Creative Director, Art Director and Designer (and a Developer, but don’t tell anyone). He started his creative career in 2004, followed by the launch of his own creative agency in 2008. Ranked a top earning freelancer on Upwork (former Elance) in 2013. Launched a few startups of his own. Featured on CSS Design Awards. Former first Creative Director at QUOINE/LIQUID. Founder, Director at Chasing Dreams Games. Pavel has been helping startups, founders and well run businesses with Branding, Product Design, UI/UX and Brand Experience for 15+ years.
Personal website: pekanov.com
