Is It Hard to Develop a MMORPG?

How we built a MMORPG in just about 2 years (actually, it’s more).

And they say games are fun.

Skip-ables

-1. Funding
0. Support?

The stuff

Should I possess any development skills?
What building a MMORPG looks like?
How long does it take to build a MMORPG?
Why is it so expensive to build?
Is it hard to build a multiplayer server for 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

In November 2017 I had an idea of a game that would be my sweet echo to the brilliant games I played as a kid in 90s-early 00s. Games that actually had a story, mystery and novelty.

I’m talking about Crash Bandicoot, Metal Gear Solid, Final Fantasy, Deus Ex, 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.

Internet people are asking is it hard to build a MMORPG, why MMORPGs are so expensive to build, what skills go into developing one and so on and so forth. I’ve been working on my own MMORPG for about 2 years and now when it’s released I’d like to share the experience. I hope my article answers the most popular questions asked about MMORPGs and games development, in general.

Short answer — yes, it is quite hard.

Imagine the most difficult trope you’d endure with your product and then some. Building a MMORPG would be harder than that. Consider my article lead, for example.

As I’m writing this I can’t help smiling, because the first version of my article lead was — “learning [fuck up] is a noun”.

First, let me cover the basic stuff which I believe many founders and developers don’t really pay attention to.

-1. Funding

(How often do you see “negative one” at lists, huh?)

If you’ve got investors money or were lucky to be funded by one of the venture funds, please skip to the next part. Reason being — you have partners and investors. They will tell you better.

Those who aren’t funded or plan on building a MMORPG using their earnings/savings, please-please, you’re most encouraged to read this one.

Secure your funding before you start.

Secure, huh? In simple language this means you need to understand how much money you need and then enter into an agreement with your own self that you’ll be burning that money anyway.

Let’s say you saved $10k and you plan on developing your project with that, and that’s your total project funding (at least, for now). Here’s a thing you must do after that realization — make sure that budget isn’t affected by anything but your project. Don’t gamble with it, don’t invest with it, don’t spend it on living, don’t play any market with it, don’t buy gold with it, don’t buy stocks with it, don’t lend it.

Because if you do, you may lose it. Game development is hectic and it’s going to affect your nerve. Don’t let it affect your funding. Always remember you will lose your project, if you lose your funding. You will lose your team. Your pride will suffer and mirrors will be hard to look into.

This intro comes directly from my experience. In fact, it’s a very hard lesson learned. I entered my project at a decline — I was losing money already, but there was a chance the market recovers and everything works out. I didn’t think too much about it, because 1) my pockets were pretty deep, 2) well, it should recover one way or another, right?

Wrong. After more than 2 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–2018.

Take this from me and use it — withdraw and secure the funding you need for your project. Period. Sure, there never will be enough funding to fund all of your ideas. But at least you won’t lose it for being stupid.

I guess now you know why those “invested in” could skip that part. Investors have already shared that with them.

0. Support?

(On the other hand, zeroes are much more common.)

I was lucky.

Everyone I knew, everyone who heard just a bit about my whole endeavor, everyone who saw the early process, everyone at my family and friends, every stranger who didn’t really know me — all those people were quite positive about what I was doing.

Not every one of them understood the game, or what exactly I was doing. But still, they were quite positive about the fact.

You may not be as lucky. Your relatives may frown upon you making a game, your girlfriend/wife may not understand why it’s important to you, your friends may tell you you’re doing useless stuff and acting like a child.

See how making your product becomes a very frustrating experience, if there’s a lack of support?

That’s why I’d say don’t even start, if you don’t have the support of those close to you. Unless, you really-really-really believe in what you’re doing and willing to risk yours and theirs well-being trying to achieve YOUR goal. AND willing to face consequences if you fail.

I must also tell you this.

Building your product or startup from the ground up provides you with an empowering feeling of creating something good, something that other people will appreciate and be thankful that you managed to build something that useful and unique.

Then the other day you think you’re making the biggest mistake of your life, your product sucks, you’re re-inventing the wheel and you also suck as a human being and as a person, also professionally too.

Then you go to bed, sleep and it’s a new day.

1. Should I possess any development skills?

I don’t really want to turn this one into a FAQ, but… (I think I already did.) It’s a popular question asked primarily by founders building their first product, so let’s roll with it.

Here you really have two options. Either you have development skills OR you possess the expertise that can’t be easily outsourced or hired. This can be really strong writing, conceptualizing, design — anything that you bring to the product. At the end of the day, however, tech skills are most valuable when it comes to an early stage product. Why? Well, developers make things happen. You can have the best UI in the world, but who cares if it can’t be interacted with.

My backstory is that I’ve built 4–5 products single-handedly as a Jack-Of-All-Trades, shipped 8 products with my own teams as a Designer/PM, took part in a few other people’s products as their Designer/Art-Director/Creative Director working as a part of their teams.

That took me about 15 years, during which 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.

Now this gives me some perspective. I believe ones should have very solid development skills and a solid tech background, if they want to build a web/mobile product.

Benefits:

You understand the real state of your product. If, say, your investors are curious how it’s going, you won’t need an excuse to talk to your actual developers.
You can help your developers.
Since you know how to build a feature, you can effectively explain it to your team. When we learn, we learn together.
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. Ew!
Your team may rely too much on your help. Yikes!
You may end up making too much on your own instead of delegating shit. Hello, devhell and welcome to back-log.
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. People!

All things considered, I think it’s still a big “yes” and a huge advantage to have dev skills rather than not to have any coding expertise at all. You’re building a tech product after all, you have to understand what’s going on under the hood.

I’d like to draw a line between your future client-side app and server-side app. Quite obvious, they serve different purposes. My point is that you don’t need hardcore skills to code just a client-side app.

The very first Amazing Creatures release was a standalone sandbox mobile app, a single-player experience with all calculations done at the client-side. It took me about 2 months, while I was learning Unity from the ground-up.

It turned out to be very useful. Going forward, I was using that client-side app as a skeleton model for the future client-server app. I wasn’t familiar with the game engine [I mean, the components-driven development in Unity], so coding a client-side app provided me with an understanding how stuff works.

Q: Why code only a client-side app for an online multiplayer game?

A: Test ideas, test concepts, test gameplay, test User 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 startup people would call it coding an MVP, but meh. I don’t think public MVPs or public prototypes really work with games. I don’t think games/movies/books are the cases for pushing for a release date and releasing early. Unless, you’re a known developer (like, say, Blizzard, Square or Bethesda) then yes, you will provide early access, early marketing and so forth.

For fresh studios like mine, I believe going for the best quality would be the one and only way to win fans.

2. What building a MMORPG looks like?

Remember how fun it is to play RPGs—lots of quests to discover, lots of items to use, lots of characters to meet and a 50+ hours long story (and various side-quests easily adding another 50 hours to that).

If you’re after a RPG, you will be looking to create a ton of content, translating it into a massive amount of game assets. Otherwise, it’d be simply no fun to play your game, it’d be too small to explore.

What’s the difference between a RPG and a MMORPG regarding the game assets? Well, the difference is the number of people that are going to play it and do that simultaneously.

It’s one story if your game is a single-player RPG, but it’s an entirely different story if it’s a MMORPG. Think experiences and interactions.

At a single-player game you are the protagonist—your experience is unique, game interactions are designed to satisfy just a single player (you). At a multiplayer game you will interact with something that may have lost its novelty — some other player had that interaction before you— therefore, novelty is not 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 a fancy book of what did our path to making the best MMORPG of all time look like.

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 reply from one of the industry veterans saying that, hey, making graphics isn’t the most time consuming.

My understanding is that a quality game is synonymous to having excellent art quality. And my design experience tells me excellent art quality can take a substantial amount of time. On top of that you need a decent story/lore to hook up players and a decent gameplay to make them want playing.

What about the graphics? My favorite part, the creative process. Let me fast-forward the creative process we had during the development of Amazing Creatures.

The app

Day 1

Initial draft.

This was our “idea” stage. I designed a layout that didn’t actually change that much towards the final release. Note: image courtesy of MetaMask. (Yeah, I know it’s a fox.)

Day 60–Day 120

Left-to-right, three core game modes. A virtual pet simulation, a location-based treasures and quests hunting, and a collectible cards PvP mode. [Does it sound like having 3 different games?]

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.

The models and animations

First: a fast-forwarded creative process for a Chico.

Next: idle animation for the Gallooper.

Not mentioning lots of changes, new features, deleting bad gameplay, improving existing gameplay, adding content, writing stories and chapters, etc., etc. that’s almost a year to create and visually polish a MMORPG.

Not mentioning it comes from someone who spent his last 15 years in creative & design AND has the development skills and expertise AND has all the time he needs to work on his dream. Perhaps, this pretty much answers the article question.

I believe most of you will raise their eyebrows saying — so yeah, who cares if you’ve got 15 years of something or not — and I’d like to point out why having experience is important:

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.

See how many points go to the importance of knowing Adobe Suite, 3D Modeling, 2D Graphics, Computer Science and Maths? Exactly, none. Experience nets you the soft skills, first and foremost.

Though, I’m not discouraging you to try and build a great MMORPG without having years of experience. Quite the opposite, in fact. All I’m saying that those years helped massively, and I can’t imagine going through all without having that.

Have a look at a complete creative case at my personal website: https://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 a 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. For a 7 people team, that is… drumroll… a whooping ~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.

Thinking, team average hourly rate is somewhere in $50–150/hr depending on your region and you won’t be paying anything yourself as a proud founder, 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. Well, thanks God there’re outsource websites, right?

My math 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 dunno, 4–5 years release time, at best? And we’ll still be x10 times smaller than, say, WoW or EvE. At least, considering the amount 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, games don’t make good candidates to be lean-mvped. You’ll be building your game to a point when it looks good (at the very least)—which means quality art, sounds, music and VFX. Not the cheapest building blocks. The alternative won’t save much budget either, because you’ll be building your game networking and engine to a point when it functions good (again, at the very least). Networking and engine are also not something you’d 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 back-log 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 back-log.

You may 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 other’s are having. Yep, that may work. It’s called building a clone.

If you’re into building a genuine game, something your life and heart went to — you will experiment. I’d like to show you a few experiments we had with Amazing Creatures.

First, we had an entirely different way of on-boarding players. Telling them that their device is capable of… it’d be better if I just show you. Like this:

We thought explaining the essentials would help the players understand the game better.

We ditched that entire concept later on, since everyone understands how location-based games work. There’s no need for such in-depth lifeless intro into how the actual device works — it’s not rocket science.

In the final release we introduce a player to the concept of Avatars, Creatures and The Realm with our on-boarding quest (tutorial). Our tutorial is executed in a sequence of so-called “chapters”, each of them containing a series of tips familiarizing the player with the gameplay, concepts and lore:

We don’t explain how a mobile device works. Instead, we let the player experience it by engaging the game.

Then we had an entirely different concept of Creatures and Portals.

Originally, players needed to capture or summon their first Creature. People could play having no Creatures at all. Yeah… in a game that has “Creatures” in its name. Anyways.

So how would you get your first Creature? What was the original idea? We had a concept of Void that a player had to Claim and then it became an Unoccupied Space, and once it’s occupied it becomes a Portal.

My bold emphasis is intentional for you to see we had 4 (four!) gameplay entities for a very simple, essential and straightforward game scenario — getting a Creature. I don’t think anyone would’ve understood that trope or been enthusiastic enough to go thought it. So complicated, right?

First, we changed how the game is started. In the final release a player always has at least one Creature, the one that’s given at the very start. The Portals are treated simply as “free space” to host Creatures. Finally, there’s a dedicated screen to walk around your bestiary:

Left: Void space → Claim Void → Unoccupied space → Summon Creature → Portal.

Right: Portal → Creature.

With the above examples I just barely scratched the surface, because at the early stage we had an entirely different approach to almost everything.

If you ever wondered why exactly games are so expensive to build, it’s that’s why — lots of ideas and experiment before finally setting things right. It’s probably quite similar to writing books or filming movies, or creating any other kind of commercial(-ized) art.

5. Is it hard to build a multiplayer server for MMORPG?

Yes. And no. Depends how you define “hard”.

No, really. I’m not kidding, it’s not that hard. It’s difficult — debugging broken code that worked yesterday was frustrating, things went ultra-tense most of the final month of testing — but it’s not actually that hard once all the groundwork has been laid out.

Perhaps, the correct answer would’ve been — it’s much more doable, than you’ve probably thought.

First things first, I assure you I’m no expert and coding guru. Second things second (because — logic!), I’m a self-taught developer who sucks at theory, computer science, algebra (and mathematics, in general), computation, working on formulas and algorithms, and many-many other things. Remember, I’m a (graphic) designer, after all.

I had no idea what inheritance was, theoretically, yet I employed it. I had no idea what polymorphism was, yet I also employed it. I had no idea what a singleton was, yet — you guessed it — I employed it (though, tried to avoid). I still don’t understand the performance difference among a (switch case) statement over (if else) or (try catch), neither I find using (while)s a problem.

I didn’t do the most complex pieces, such as coding the load balancer and on-the-fly server instances initialization — which I’d love to code, and I’ve already got some thoughts on that one.

Consider the tortoise. As the fable teaches us, it may appear that… ahem… where were we?

Consider the genre. All-in-all MMORPGs are one of the most complex games out there — there’s lots of graphics, lots of human players interacting with lots of other human players. This last bit is the hard part.

Also knowing 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 players count goes past you and that guy.

Also this:

In MMORPGs lots of stuff is happening at the (virtually) very same moment.

Which leads to me saying 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. 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):

This tiny pocket monster is responsible for timely world map updates. Yep, for everyone.

The tricky piece here is that this function calls two different layers. Which in turn means we’re keeping game data at (more logic!) 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.

I don’t really want to play the Know-It-All card here, but this is a pretty smart solution. 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 (at the very least, huh?). How about thinking how you’re going to get there, smart-ass?

You know what? That is not something that’s going to happen at your game launch. Not only the numbers are huge for a fresh-out game, but the infrastructure to sustain that number of players would be so redundant so very-very-very early.

Don’t think how your server is going to serve a million of players.

Think how you get to that number in the first place.

So the only thing I’ve laid out for far-future balancing, is that I have a logic that utilizes a so-called soft cap and hard cap for the players count. Given our server tracks the number of total socket connections, a new socket opened equals a new player joined the game.

Well, most of the time it is, unless a player disconnects right away or joins from his other device — in that case we’ll temporarily have two socket instances for a single player entity for about 500 milliseconds (because after that time our HeartbeatPlayer() will enforce a disconnect on the duplicate; um, well, technically that’ll be the player himself who pulls the plug on the twin).

Reaching the soft cap would merely produce a logged warning on server end. No interference, internal stuff. However, it will trigger new server instance initialization which stays hidden on the client-side.

Reaching hard cap will notify a player who is about to log in to the game that the server is full and will ask to select a less busy server instance to join the game. At this point our new server instance becomes available (visible) on the client-end.

The hard part would be keeping the experience universal no matter the number of instances. We don’t want players joining an empty shard processing its own game state, while there is a bunch of other people playing on a shard that’s on its full capacity running its very own game state. The shards have to be dynamically initialized, while the game state must be shared among all of them.

Needed to say that there’re multiple ways you can scale your game, and you can combine those too. But this is an entirely different article, written by someone much more skilled than me.

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 pre-pre-previous generation to current generation specs.

Here’s a 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 pre-pre-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) upgrade, but 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 change ever.

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 The Fucking Fuck?

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 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 puzzle, 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, literally, new ideas came from new ideas.

Perhaps, I should rephrase. New ideas came from different new ideas.

Sketches and early art for the Amazing Creatures prequel:

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.

Meaning, +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 Random 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, at Amazing Creatures the core gameplay is a mix of the following gameplays:

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:

Summon, Battle, Explore—three experiences that compose Amazing Creatures experience.

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 one single gameplay. It is thanks to the core features and here’s our list (square brackets indicate the original gameplay mode):

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 at 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.

App Major Version as seen at our manifest.json file:

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—no more anxiety about players forgetting to update:

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’s 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.

Old-school storytelling:

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 forth wall so that the player can become the game avatar. So you’re really out of options there. You must solve the mysteries, or… well.. you know, soul and stuff. 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 put, I don’t really know if anyone besides Quantic Dream is doing storytelling that is cool like that. 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 in 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.

[Brief 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, that’s how it goes:

The Avatar has the ability to acquire Ester, an immaterial essence granting certain magical powers. One of such powers 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.
One of 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. [EOF]

I think it’s an authentic and fun way to start the game, let alone simply log in to the game:

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 gift, a book.

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 (it’s the thing when your 4x CD-RW drive doesn’t recognize a CD [creepy sound attached]).

The book was full of code screenshots and code listings, I think it was C and ASM. The book was (supposedly) 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 a very beautiful piece. Sit back, relax and enjoy.

Amazing Creatures, the game:

Chasing Dreams Games:

https://chasingdreams.io

About the author

Pavel Pekanov is a seasoned Creative Director, Art Director and Designer (and a Developer, but tss-s tell no one). 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

And now my story has ended. But my journey has not.