rpg制作大师_在线RPG大师班

最新推荐文章于 2022-12-29 16:57:51 发布

weixin_26638123

最新推荐文章于 2022-12-29 16:57:51 发布

阅读量2k

点赞数

文章标签： python

原文链接：https://medium.com/super-jump/the-online-rpg-masterclass-a25a5053f0f4

版权

rpg制作大师

游戏开发大师课程 (GAME DEVELOPER MASTERCLASS)

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.

2017 年 11月，我对游戏提出了一个想法，这将是我对90年代和00年代早期儿童玩的出色游戏的最终致敬。 这些游戏实际上都有故事，神秘和新颖性。我说的是Crash Bandicoot ， Metal Gear Solid ， Final Fantasy ， Deus Ex和Silent Hill 。这些游戏。

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.

在开始详细介绍之前，我只想说一句话：是的，我们决定制作一个MMORPG(代表“大型多人在线角色扮演游戏”)。我经常遇到的问题之一，特别是来自互联网上可能对制作游戏感兴趣的人，是否是这样： 构建MMORPG很难吗？ 人们还往往想知道创造一项技能需要什么技能，并且还有许多其他相关的问题。好吧，我从事自己的MMORPG已有两年了。现在，它已经发布，我想与您分享我的经验。我希望本文能够回答有关MMORPG开发的一些最迫切的问题，甚至是一般游戏的开发。

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.

想象一下您在产品开发中可能会遇到的最大挑战，然后再挑战一些。建立MMORPG更加困难。

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. FUNDING2. SUPPORT

1.资金2。支持

建立你的游戏 (BUILDING YOUR GAME)

Should I possess any development skills?
我应该具备任何开发技能吗？
What does building an MMORPG look like?
构建MMORPG是什么样的？
How long does it take to build an MMORPG?
建立MMORPG需要多长时间？
Why is it so expensive to build?
为什么建造如此昂贵？
Is it hard to build a multiplayer server for an MMORPG?
为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.资金 (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.

但是，如果您有想法-或者您已经开始了项目-并且目前没有资金 (特别是如果您打算使用收入或储蓄来建立MMORPG)，我真的鼓励您阅读本节。

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.

假设您节省了1万美元，并且您计划使用这些资金来开发项目(并且说这至少是目前的总项目资金)。下一步是确保这些资金只受到您项目的影响。不赌博，不投资，不花钱生活，不玩市场，不买黄金，不买股票，不贷款它。

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?

这个建议来自我的直接经验。实际上，这是一个非常艰难的教训。在市场下跌期间，我开始了我的项目-我已经在赔钱，但是有机会市场会恢复，一切都会顺利进行。当时，我并没有考虑太多，因为a)我的口袋很深，b)市场应该以一种或另一种方式恢复，对吗？

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.

错误。经过两年多的发展，截至2020年3月，市场仍在下滑。我目睹了2017-18年前9个月我的资金缩减为零。

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.支持 (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.

在旅途中的某些时刻，您可能会相信自己犯了人生中最大的错误，游戏糟透了，重新发明了方向盘，并且像一个人一样糟透了。深吸一口气，上床睡觉，醒来新的一天；这些都是漫长道路上的小坎s，毅力是关键。

建立您的游戏 (BUILDING YOUR GAME)

1.我应该具备任何开发技能吗？ (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.

确实有两种选择。您要么具有开发技能，要么拥有无法轻易外包或雇用的其他专业知识。也许您是一位出色的作家，一位出色的项目经理或一位精湛的设计师；您可以为产品带来许多不同类型的技能。归根结底，在生产的早期阶段，技术技能是最有价值的。为什么？简而言之，开发人员可以使事情成真。您可以拥有世界上最好的UI，但是谁在乎是否无法与之交互。

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.

让我给你一些关于我自己的背景。我单枪匹马制造了4–5个产品，作为所有行业的杰克。我已经作为团队的设计师/产品经理交付了8种产品。作为跨职能团队的一部分，我作为其他设计师/艺术总监/创意总监为其他人的项目做出了贡献。

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.

这种经验持续了大约15年，在此期间，我学习了编码(Web和移动应用程序，服务器后端)，并且学习了当时对于我来说是全新的几种编程语言。

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.

因此，当您在这里考虑我的观点时，请记住这一点。我个人认为，要构建Web /移动产品，拥有扎实的开发技能和扎实的技术背景非常重要。

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.
如果您有一个疯狂的想法，如果您不知道如何编写代码，就不要让它滑到待办事项列表。这意味着，您的虚拟猫咪喂食器模拟器可能并没有真正需要集成位于Blockchain上的VR + AR。

缺点： (Downsides:)

You will be held accountable for virtually everything from scripts to UI implementation.
您几乎要对从脚本到UI实施的所有事情负责。
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.

最初的Amazing Creatures版本是一个独立的沙箱移动应用程序。这是一次单人游戏体验，所有计算都在客户端进行。从头开始学习Unity时，我花了大约两个月的时间来创建所有内容。事实证明，这种经验非常有用。展望未来，我正在使用客户端应用程序作为将来的客户端-服务器应用程序的框架模型。我对游戏引擎(即Unity中的组件驱动开发)不熟悉，因此编写客户端应用程序可以使我对东西的工作原理有一个大致的了解。

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.

答：测试想法，测试概念，测试游戏玩法，测试eser体验，测试VFX，聆听游戏中的音乐，对游戏中体验到的一切进行校对，以及(也许)在一些beta测试人员中。也许，甚至随您的演示一起加入投资者或基金。

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.

精益创业者会称其为“编码MVP”。但是。我认为公共MVP或原型不能很好地与游戏配合使用。我不认为游戏/电影/书本能有效地推迟发布日期并尽早提供较小的体验-嗯，实际上，我认为它可以工作，但前提是您是著名的开发人员(例如，例如暴雪，Square或Bethesda)。当然，在这种情况下，您可以提供早期访问，早期营销等。

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.构建MMORPG是什么样的？ (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).

记住玩 RPG的乐趣。有很多任务可以发现，要使用的物品很多，可以见到的角色很多，而且故事往往长达50多个小时(以及各种附带的任务，很可能又会增加50个小时)。

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.

因此，如果您打算实际构建RPG，那么您正在寻找创建大量内容并将其转换为大量游戏资产的前景。否则，玩您的游戏将毫无乐趣，因为它太小而无法探索。

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.

就游戏资产而言，RPG和MMORPG有什么区别？如您所料，关键区别在于将要玩(同时玩)的人数。创建单人RPG是一回事，但是MMORPG是完全不同的野兽-思考体验和互动。

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.

我是这样想的-在单人游戏中1次互动等于1次独特体验，但是在多人游戏中1次互动等于1次独特体验乘以实体稀有度再除以玩家总数。

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.

假设我们的游戏中有两个实体(任务，NPC，生物，咒语，物品)。一个很常见，另一个是超稀有的传奇人物。我们给他们分配了一个“稀有乘数”，玩家看不到，纯粹是内部的东西。“ 1”代表普通实体，“ 5”代表传奇人物。

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

现在，对于单个玩家，我们有1：1的机会遇到一个共同的实体，而有1：5的机会遇到一个传奇的实体。这意味着玩家会立即清除一个公共实体的互动，并且每五次抽奖一次，玩家会清除一个传奇实体的互动。 (在此相对论。)

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.

随着玩家人数的增加，我们估算互动的方法也随之改变。普通实体现在具有(1 * 1)/计数的互动机会是唯一的。传奇实体现在具有(1 * 5)/计数的互动机会是唯一的。

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.

我在这里所说的与艺术，素描，故事，建模或开发无关。我说的是一份设计文件。而且它不会是一本花哨的书，书中包含角色艺术，他们的背景故事以及您的主要2D艺术家的介绍词。

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.

无聊吧？同样，我们离创造任何时候最好的MMORPG所走的道路都不远。好吧，那么让我们开始有趣的部分。

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.

许多人低估了发行游戏所需的资源量，更不用说MMO了，更不用说MMORPG了。我什至从业内资深人士那里收到一条消息，说，嘿，制作图形并不是最耗时的难题。

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.

那么，让我们跳到图形。这是我创作过程中最喜欢的部分。我将直接进入Amazing Creatures开发过程中经历的(大量摘要)创意过程。

APP (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

第60天-第120天

Left-to-right, three core game modes. A virtual pet simulation, location-based treasures, quest hunting, and a collectible cards PvP mode.

从左到右，三种核心游戏模式。虚拟宠物模拟，基于位置的宝藏，任务狩猎和可收藏卡片PvP模式。

Day 150–210-ish

150-210天

What took you so long, Snake?

Snake，你花了这么长时间吗？

That’s some 210+ days separating left “picture” from a playable production-ready, event-driven, location-based player-vs-player mobile MMORPG (below).

将左“画面”与可生产，就绪，事件驱动，基于位置的播放器与播放器移动MMORPG(以下) 相隔约210天以上 。

模型与动画 (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.

这是超级快速的过程。它不包括所有的更改/迭代，新功能，删除不良的游戏玩法，改善现有的游戏玩法，添加内容，编写故事和章节等，这些都需要近一年的时间来创建和视觉上修饰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.

另外，别忘了，这种努力和消磨时间来自于过去15年从事创意/设计工作，具有开发技能并能够全职工作以实现自己梦想的人。请考虑对这些维度中的任何一个进行的任何更改如何可能极大地影响构建此类内容所需的时间。

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.

您会在这里注意到一个主题。以上几点都与了解Adobe Suite，3D建模，2D图形，计算机科学和数学无关？确实-没有。经验首先让您掌握了软技能 。

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.

提醒您，在没有多年经验的情况下，我绝不会阻止您尝试构建出色的MMORPG。相反，实际上！我只是说那些年都极大地帮助了我，我无法想象如果没有这样的项目就无法进行。

Have a look at a complete creative case at my personal website: https://cases.pekanov.com/amazing-creatures/

在我的个人网站上查看完整的创意案例： 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):

以下是一些演示，它们演示了模拟游戏玩法(左侧，After Effects)和真实物体(右侧，Unity Editor屏幕截图)之间的过渡：

Amazing Creatures: Summon. Before → After progress.

惊人的生物：召唤。之前→进展之后。

Amazing Creatures: Shapeshift. Before → After progress.

惊人的生物：变形。之前→进展之后。

3.建立MMORPG需要多长时间？ (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).

我们花了8个月的时间才能完成所有基础工作-考虑了创意和编码，然后又花了7个月来编写网络代码并进行游戏的错误测试，然后又花了5个月来建立MVP(沙盒单人游戏)，然后我一个人工作每天10个小时，连续5个月 (每周工作6-7天)。

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.

说到这一点：对于一个7人的团队来说，这就是…… 鼓声……高达23,900人/小时。 由于我在这里数小时，因此对于您可能需要的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?

如果团队成员的平均时薪在$ 50–150 / hr范围内(取决于您所在的地区)，并且如果您不支付给自己作为骄傲的创始人的钱，那么您的收入将为$ 350K-350万使您的MMORPG与小型全职团队在2–2.5年的时间里相处。谢天谢地，有外包网站，对吗？

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.

我在这里的数学不是精确的美元对美元，因为对于低端人士，我假设您自己是零工资的工作，您不支付办公室租金，您不购买任何设备，您不购买任何昂贵的许可证，您都有一些免费或非常便宜的人，您可能有一些朋友，等等。。。为了给您一个现实的数字，只要您能忙碌，它在低端可能要花费多少。如果您无法管理上述低端的工作，那么仅在低端，您的收入就会达到50万至100万美元 。

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.

同样，考虑到游戏类型，这进入了一个相对较小的游戏。规模不小，不简单，但起步范围与主要参与者不同。如果我们只创建10倍的资产和东西(这是我最初的计划)，那么我真的不知道，充其量是4-5年的发布时间吗？而且我们仍然比WoW或EvE小10倍。至少就内容的绝对数量而言。

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.为什么建造这么贵？ (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.

首先，正如我之前指出的那样，游戏并不是“精益MVP”的良好候选者。您将构建自己的游戏，使其看起来(至少)看起来不错，这意味着高质量的艺术，声音，音乐和VFX。这些不是最便宜的构建基块。其他领域(例如功能引擎和网络)也不便宜，因为它们不是您要妥协的领域。

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.

我们从玩家必须索赔的虚空想法开始。然后，它变成了一个无人居住的空间 ，被占领后变成了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.为MMORPG构建多人服务器很难吗？ (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.

考虑流派。总而言之，MMORPG是最复杂的游戏类型之一。有很多图形，很多人类玩家与其他人类玩家互动。最后一点是最困难的。

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.

也请记住，您的MMORPG服务器实际上是一个黑盒。您可以左右记录日志，可以将状态保存到文件中，以便日后查阅，但总的来说，一旦并发玩家数超过了您和那个人，您绝对不知道在特定时刻发生了什么。在MMORPG中，(实际上)同一时刻发生了很多事情。

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.

为了减轻未知因素，我们使用了自己的事件报告系统以及所谓的“ HeartbeatX”事件。基本上，我们来回轮询玩家状态并发出事件。像其他所有人一样，这里没有新内容。

Here’s one of the heartbeats functions family, function HeartbeatWorldmap(socket):

这是心跳函数家族之一， 函数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?).
Globals专为人类化身，游荡的生物和静态宝藏(防暴箱)而设计。所有人与人之间的互动都在Globals图层上处理(但并不存储在那儿，因为如果玩家从未进入世界地图，我们为什么要这么做呢？)。
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.
Locals是地图图块的动态集合(阵列)，其中包含NPC(常规头像，基于角色的头像和POI)，生成的游荡生物和生成的宝藏。

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.

如果我自己这么说，这是一个非常聪明的解决方案。当然，主要的“工作人员”是CheckRespawn()，因为它根据玩家的亲近度和实际的世界地图可用性向客户端触发实际的更新。所以，是的，如果您在主菜单上感到不寒而栗，就不会有世界地图乒乓球。

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.

我与一些可靠的开发人员进行了交谈。他们都在谈论游戏服务器需要维持至少1,000–10,000个并发连接。该服务器至少应能够为1,000,000名玩家提供服务。不过请记住，这不是在您的游戏启动时就发生的事情。对于一个全新的游戏来说，这些数字不仅庞大而且不太可能，而且维持这种数量的玩家所需的基础设施将在不需要的时候非常早地完全冗余。

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.

这并不意味着您应该完全忽略负载平衡方面的潜在需求。我已经为玩家数量设置了软上限和硬上限 。我们的服务器跟踪总套接字连接数(其中打开的新套接字等于新加入游戏的玩家)。好吧，实际上，一个新的套接字可能并不总是等同于一个新的播放器-如果一个播放器立即断开连接或从另一台设备加入，则它们可能会临时为同一个播放器实体提供两个套接字实例，持续时间约为500毫秒。达到软上限仅在服务器端产生已记录的警告。它完全不会干扰玩家的体验-纯粹是内部问题(它将触发隐藏在客户端的新服务器实例初始化)。但是，如果达到硬上限 ，将通知即将登录的播放器服务器已满，并且将要求其选择不那么忙的服务器实例加入。此时，我们的新服务器实例将在客户端可见。

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

如果您好奇的话，这里是有关数据库分片的很好的阅读： https : //medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6

6.我应该何时优化游戏？ (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.

假设您开始针对iPhone的手机游戏。您从2010年开始，顶级设备是一台新的iPhone4。然后您的游戏已经制作和完善，花了您几年时间(因为您的游戏非常复杂)，现在您可以开始使用了。 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.

2010年的iPhone 4和2015年的iPhone 6之间有何差距？很大不仅软件(iOS)不同，而且还有大量的硬件和规格升级。如果一开始就针对iPhone 4进行优化，那将浪费很多时间。

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:

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.
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.
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.
Code considering lags and delays. Localhost is instant and fast. Remote will be not.

b。 Should I polish my code? (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.

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.

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.

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.

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

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? (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.

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?

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:

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.
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.
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).
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 eg, 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.
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.
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. (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?!

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.

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.

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

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? (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.

不足之处？ 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? (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.

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.

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.

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.

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.

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.
Roam. Keeps a Creature happy. Basically, a pet simulator.
Journey. Interacting with other players on a world map.
Journey. Interacting with other players on a world map.
Clash (Battle). Challenging other players to a game of cards.
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”).

(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”:

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 Summon a Creature. [Roam]
A player can Capture a Creature. [Journey]
A player can Capture a Creature. [Journey]
A player can transform (Shapeshift) a Creature into a card. [Roam]
A player can transform (Shapeshift) a Creature into a card. [Roam]
A player can compose a deck of cards. [Roam]
A player can compose a deck of cards. [Roam]
A player can see other players around him. [Journey]
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 attack (Ambush) other players with his deck of cards. [Clash]
A player can capture (win) or lose card to another player. [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:

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 Stamina, Agility, Magic, Power, Luck and Energy stats. Shortcode: SAMPLE stats. [Universal]
An Avatar has traits. [Universal]
An Avatar has traits. [Universal]
A Creature has Statuses. [Universal]
A Creature has Statuses. [Universal]
Statuses grant Affects. [Universal]
Statuses grant Affects. [Universal]
Affects influence player Avatar’s traits and/or stats. [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 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]
A player can Summon a Creature with another player. [Journey]
Every Creature is unique. [Universal]
Every Creature is unique. [Universal]
A player can add other players to his list of friends. [Journey]
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 use Artifacts and Powers. [Roam, Journey, Clash]
A player can imbue Runes into cards affecting their strength and value. [Clash]
A player can imbue Runes into cards affecting their strength and value. [Clash]
Every card is unique. [Universal]
Every card is unique. [Universal]
A player can fuse Magistones into Creatures to grant them Powers. [Roam]
A player can fuse Magistones into Creatures to grant them Powers. [Roam]
A player can get extra items from Treasures. [Journey]
A player can get extra items from Treasures. [Journey]
A player can interact with NPCs. [Journey]
A player can interact with NPCs. [Journey]
A player can mug another player, the other player can evade. [Clash]
A player can mug another player, the other player can evade. [Clash]
…(the list goes a bit further down)
…(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.

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.

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

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?

Usually you'd come across a version number that goes as ABC — 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?

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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:

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:

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

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:

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 familiarizes the player with the core game concept (Portals).
It’s entertaining, engaging and encourages “playing”.
It's entertaining, engaging and encourages “playing”.
It provides an early intro to the game style and lore.
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.
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.

What about the original idea? 好。 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? (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.

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. 应该。 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.

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.

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.

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.

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 (12. The bonus part)

Achievement unlocked!

For those who’ve read this far, here’s the Amazing Creatures Official Soundtrack.

For those who've read this far, here's the Amazing Creatures Official Soundtrack .

It’s very beautiful. Sit back, relax and enjoy.

非常漂亮 Sit back, relax and enjoy.

https://www.youtube.com/playlist?list=PLQhA3nl0lMo8TGxYroTW82z8gx2acdIfu https://www.youtube.com/playlist?list=PLQhA3nl0lMo8TGxYroTW82z8gx2acdIfu

Amazing Creatures, the game: (Amazing Creatures, the game:)

https://youtu.be/rZjUaPW9dHE https://youtu.be/rZjUaPW9dHE

Chasing Dreams Games: (Chasing Dreams Games:)

https://chasingdreams.io

关于作者 (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.

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

Personal website: pekanov.com

翻译自: https://medium.com/super-jump/the-online-rpg-masterclass-a25a5053f0f4

rpg制作大师

weixin_26638123

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
rpg制作大师_在线RPG大师班

rpg制作大师游戏开发大师课程 (GAME DEVELOPER MASTERCLASS)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...
复制链接

扫一扫