According to many, open-world is fun. Perhaps it's the sense of freedom, progression, or influence upon the world which tickles a player's funny bone. Whichever it is, if there's anything we game designers know, it's that it's hard to pull off.
Firstly, what is an open-world game? Trusty Wikipedia reports,
A video game in which a player can roam a virtual world and approach objectives freely, as opposed to a game with more linear gameplay.
Yet with such a notion of a player freely wandering into wherever they please comes bundled with a set of issues which, if not dealt with properly, will make or break your game. Most prominently...
Imagine you're making a game with a linear main quest where monsters gradually get stronger as the player progresses and gains more power. You wake up one day and decide open-world is the one feature which has to be included in your game. So you go ahead and remove all travel restrictions, and add a bit of side content.
The ingenuous player decides to delay your main quest and spend some time on side quests. "Those monsters sure keep getting stronger," thought the player. "I need to do some side quests so I can stay one step ahead of them."
Lo and behold, your carefully crafted power balance is completely destroyed, leaving you with an overpowered player to wipe the floor with any poor monster who dares cross his path.
I'm sure you can imagine an alternative where the player is wrecked in side quests meant for a more powerful player.
So how do you solve this? Let me just quote a little thing I've read in the vast cosmos of the interwebz:
Game design is pretty much one giant [CENSORED] ball of borrowing
In other words, in order to do things properly, we need to study the work of others, and see how they've done it.
Let's take a look at the amazing Skyrim. How does it handle its level scaling?
Different locations in Skyrim have different inherent difficulties. In other words, some dungeons are designed to be too difficult for low-level characters to enter.
That is to say, every location has a minimum and a maximum level. Say we have a dungeon from level 5 to 30.
If the player enters before the minimum level at, say, level 2, they enter a dungeon with stronger level 5 enemies and better loot. If the player enters within the level range, for example, level 15, the dungeon would contain level 15 enemies. And if the player enters after the maximum level, that is, 30+ they get to wipe the floor with level 30 enemies.
Such a system allows for intricate risk/reward balancing. As in, "Just defeated a horde of trolls 10 levels above yourself? Here's some awesome loot to compensate." and "Done wiping the floor? Here's your two septims."
Well there you have it. You've learned to avoid a game-breaking problem with open-world games. And in the solution, apply a new fun mechanic giving the player choice; and lots of rewards for daring ones.
What do you think of the proposed solution? Have you encountered other problems with open-world games? Leave us a comment with your thoughts.
Tags: Project Management
Most games never reach completion. Most of us know this -- especially programmers, who typically leave a trail of dead projects in their wake. Well-intentioned projects, but incomplete projects none-the-less.
What steps can you take to increase the chances of actually finishing, and get your game to that glorified "done" state?
At Deen Games, we work in a team of two (or I sometimes work alone), part-time, without funding. The steps below outline our process -- one which, if we applied it consistently, would lead to us finishing many more games. Each step in the process fulfills a specific purpose, which I will explain along the way.
But first, a quick detour on why games fail.
Why do we fail to complete games so often? When you look at the bigger picture (across mutliple projects and teams), you find a number of common reasons:
Having summarized the main failure points, let's dive into the process and see how we get around some of these issues.
We don't really use agile; we just work linearly given whatever amount of time and energy we have (since we're part time). However, you can always break these stages into different stories and apply them to an agile/iterative life-cycle.
Every good game starts with a good vision. What are we trying to build? Is it a completely procedurally-generated 2D RPG, an Android game that teaches Arabic vocabulary to kids aged 4-8, or a stealth-based MMO? Write it down.
The vision should be clear, and should list what we want to achieve by releasing this game; it should also be composed of highly motivational statements for the team. When motivation slumps, we can review this, and get a burst of re-energizing/motivation.
At Deen Games, we develop Islamic and educational games. The next step is to write down our goal: what do players get out of playing this game? The learning goal can be grand (eg. acquire fluency in a new language) or benign (get exposure to Muslim culture specific to Yemen), but it needs to be decided up-front. Again, write it down.
Without this, we tend to abandon projects because they don't make the world a better place in some way.
The core game loop (or loops) of your game, are those activities and actions the player plays over and over and over again. In a typical platformer, that's running, jumping, dodging; in an FPS, it's seeking weapons/ammo/armour, shooting, and dodging.
This is really the fruit of the game design; the place where we codify the vision and learning goal into the actual gameplay. This is how players learn (through experience), and how we communicate that through the actual mechanics (instead of simply a story or dialog).
This forms the core of your game; without this, your game won't be fun; motivation fizzles, fast.
I learned of Risk Analysis during my studies as a PMP. You want to analyze your project and find any risks -- those sneaky issues that, if they occur, could (or will certainly) cause the downfall of your project.
Using risk analysis, you can quickly identify risks like the following:
Here in the process, you want to mitigate or minimize the risks. For example, maybe you're working on an underwater sea-life themed infinite runner, and your risk is that you need really good art. Your options might include:
In the worst case, if the project just can't be done, this is the time to go back to the brainstorming phase and see if you can come up with something different. Alternatively, you can acccept the risk and move on (but this often leads to failure).
Many games are not fun. And nothing is more demotivational than investing hours and hours into a game that's boring or tedious. In this stage, prototype your game and find out what combination of features makes it fun.
While prototyping is an art (and science), and something you should read more about, here are some of the key take-aways for this stage:
Chances are, you will find that your prototype isn't the fun experience you thought it would be. No problem, recycle -- add things, change things, remove things, and iterate until you find the balance that is fun -- or until you get tired (there's no way to make a butterfly simulator fun ... or is there?).
Show your prototype to your team members (hopefully they worked on it with you), friends, and family. Provide them with instructions (since the game likely has none). Listen to the feedback people give you on what works and doesn't; but be weary of suggestions for improvement (these are usually terrible and have nothing to do with your game vision and objectives).
If you can get someone else (or a number of players) to agree that your prototype really is fun, even at this stage, you're in business.
If you didn't go back to the drawing board on your game, congratulations! You have an idea that sounds and plays fun. This is the hardest part -- all you need to do now is complete it and ship it.
Your game probably requires a lot of stuff -- levels, entities, art, algorithms, characters, text, a tutorial, and more! At this stage, you probably realize that you can't possibly finish this game in a decent time-line (unless it's a very, very simple game).
You now need to focus on shipping. To do that, you need to pare the game down to the core essence of the game. In a way, you already did this: you focused on your core game loop, and prototyped it until it was fun. You should now have a good idea of what your game entails.
Now, think about every feature, every level, every piece of content. Ask yourself constantly: can I live without this? Can I ship my game without this? Or maybe not -- maybe, without this one element, there really is no game.
Organize your list of stuff into two broad buckets: MVP (really really need it) and a v2.0 bucket. Anything you don't need, keep it in the v2.0 bucket until after you complete the release (we'll come back to this).
Keep your list of MVP items close at hand; ideally, you want to also prioritize it (in case you lose motivation in the middle and still want to ship something).
Once that's done, crank out your game. There's no magic to this; focus on the code, the content, everything and anything you need. As you work through things, you may come up with new ideas or realizations of things you need to do; constantly ask yourself again, can I ship without this? And keep focused.
Translation is a difficult and complex process. Chances are that, within your circle of team members (and possibly family members or good friends), you will find people who are fluent in more than just English.
Enlist them to translate your game into their native language! While the translation might not be great, it's much better to ship something than to wait endlessly for that perfect translation to spring into being.
Of course, if your game isn't easy to localize, you need to fix that first. And next time, make it localizable from the start! (Tip: it's easy enough to make a single class that fetches strings for the current language and returns them, and loads a simple JSON/XML/etc. file that contains the game strings.)
When you finally finish your slog through the backlog of work, test the game thoroughly; test every possible feature, level, piece of content, and option. Enlist your teamies and friends -- they often find bugs by trying different workflows. (You tend to test the same content over and over and over during development, and get blind to the other options.)
Once that's done, congratulations! You're ready to ship your game. Build the final executable, prepare your website/marketing material (eg. tweets), and unleash it on the world.
At this point, we're technically done. You could put your game down and walk away, or take a breather to work on something else and come back. Either way, if you decide to invest more in your game, here's the good news: we're not done yet!
If you're blessed enough to have a big following on Twitter, or Itch.io/Steam/etc. (or the app store for your mobile platform), you will hear feedback. Listen to everything, and make a note somewhere. You need to sift through and prioritize this feedback, and decide what to ship (and not ship).
Remember that v2.0 backlog of deferred work we created while finding our game MVP? Revisit it, look critically through it again, and rework it or reprioritize it.
Given this combined backlog of stuff to work on, you can go back to the "brainstorming" phase. Pick a set of features, dust off your prototype, and add them. How do they affect the user experience? Are they worth integrating into the main game?
When you know the answer, you can put those changes into your game and ship another small release. (Testing thoroughly is a good idea, and test automation helps here.)
Publishing multiple small releases tends to give you more visibility and feedback across the internet, so repeat this as many times as you like.
In this article, we covered a lot of ground. We started by looking at some of the common reasons game development projects failed, and then looked into our Deen Games current (ideal) process to see how we work around many of these failures.
In doing so, we take a project through the stages of:
Do you see any holes in our process? Do you have another process or different steps that work for you? Drop us a comment and let us know.
After a few months of stagnation on the blogging/marketing side, we're finally back! We hope, inshaAllah (God willing) to publish regular (or at least semi-regular) updates to our blog and our current maintainer's Twitter account.
Accordingly, we also ditched our old, homebrew-coded blog for something sleek and production-grade (built in Pelican) blog.
Enjoy, and as usual, hit us up on Twitter to let us know what you think.
The last couple of weeks mostly entailed playtesting and game-balancing tweaks. As a result, we made a few visible changes:
You can see these changes in the GIF above. We plan to continue playtesting and tweaking in the next weeks.
We also nerfed the images back to coloured blocks, because that makes it easier to focus on gameplay rather than asthetics.
This week, we implemented the final feature work (seals and sharks). We left out one item (squids) due to a lack of time. You can see both seals and squids in the GIF above.
As well, our artist finished the main character sprite, and it gives a game a very different look.
We also nailed down the final resolution at 960x540. You can click the image above to see the full size.
Next week, we plan to add squids, and brainstorm (and add) more upgrades. Then, we can start polishing this game and release the first (minimal) version to get some user feedback.