The flaw of an endless open world and how it can be overcome.

Recommended Posts

First thing's first, let's address what is perhaps the greatest flaw any open world game has, emptiness. I'm not saying that every open world game has this flaw, but if this flaw goes unchecked, it can cripple an otherwise brilliant game. Many games have overcome this and have risen to be legends such as The Witcher 3: The Wild Hunt, Assassin's Creed: Origins, and (my personal favorite) Legend of Zelda: Breath of the Wild. However, the one thing that no-one can deny about these games is that they have limits. I'm not saying that's a bad thing, rather the fact that those games have limits is probably what made them great because the developers could work extra hard to make everything they offered the finest they could. Be it through a colorful and motley cast of characters, utterly unique content, and compelling gameplay. But I'm not here to talk about your average ordinary Open World games, I'm talking about a special, new, and somewhat unrefined form of video game that offers an endless world to explore.

An example: No Man's Sky. No Man's Sky was incredibly appealing because it offered a game world whose vastness was beyond compare. It offered an endless amount of places to go, but that was it's undoing. Video games aren't just about going places, they are about doing things. When I played No Man's Sky, what I got most interested in was finding upgrades for the ship and multi-tool. But it lost it's appeal to me because I realized that despite the fact that you had an endless amount of places to go, you had a severely limited amount of things to do. Sure you could interact with the different species and scan the local fauna, but it was all the same to me, the multi-tool was your primary method of interacting with the world, but you could only interact with the world in certain particular ways.

Another example: Minecraft. Minecraft came close to defeating the flaw of an endless open world to the point where No Man's Sky tried to mimic it to save itself. You can build anything in Minecraft, and because of that, it can offer an endless amount of things to do. But it isn't the kind of thing that appeals to everyone, probably because not everyone has fun being creative just for the sake of creativity. The most creative thing I built was a flat-sided square building, first out of cobblestone, then out of solid stone, to serve as a home base for exploration, but what really appealed to me was crafting because crafting was doing something that could enhance future ways to do other things. I did have fun exploring, but once you've seen one cave, you've seen them all. So in a nutshell, Minecraft offered an endless world and an endless amount of things to do, but it did so in a way that they didn't match up well and doesn't appeal to everyone.

Some of my favorite games were (and are) Super Mario Sunshine, Banjo Kazooie, Banjo Tooie, Ty The Tasmanian Tiger 1, 2, and 3, Okami, Rayman 3, Far Cry 4 and Primal, and Sonic Adventure 1 and 2. What they all have in common is that they're sandbox games. Orthodox sandbox games generally revolve around collecting things or fulfilling goals to collect things, but collecting those things rarely serves to enhance gameplay other than to make a way to collect more of those things. But despite this, I keep coming back to those games. After thinking long and hard, I decided that what keeps me coming back is discovery and testing the limits of my skills.

Now to the hypothesis. The appeal to an open world game is endless discovery and endless things to do. But even with procedural generation, it is impossible to make a game like that without things getting a little stale and similar. Even if the game implements discoverable things that add new mechanics, eventually the players will run out of new things to discover and new things to do. But there might be a method to do it in a way which can allow the player to have a number of mechanics, tactics, and methods at their disposal so great that it would be impossible for one player to uncover them all. Instead of a discovery being just an achievement or new gameplay element, it should also offer the possibility to unlock more achievements and elements depending on how the player matches up or arranges the discovery with others. That way even if the number of discoveries is limited, the possibilities each discovery offers are beyond what anyone could do by themselves. And maybe a good way to go about it is to make the number of uses each discovery has limited so that the player has to constantly venture out in the world to get the most out of their favorite discoveries. But above all, the challenges offered to the player must not call for one specific mechanic, there might be a few that would make the challenge easier, but even if using any other mechanic would make conquering the achievement harder, it would encourage players to test the limits of their creativity and skills without making them feel restricted. How could something like this be implemented? I don't know. That's why I'm posting it here like a thesis so that maybe someone with the right capabilities would read this and make the game I and possibly many others have been waiting a very long time for. I had a few ideas myself, but that is a post for another time.

A few games that I feel helped me realize these ideas were Megaman Battle Network and Castlevania: Aria of Sorrow (Because of the number of abilities and mechanics they offered) Magika (Because of the mixing up of abilities) and Super Mario Odessey (for the different captures changing up the mechanics).

Like my ideas, want to add or expand on them, or have some of your own? Please, leave a reply!

Share this post

Link to post

Share on other sites

Elite Dangerous is pretty much No Man Sky with more interesting gameplay. It pretty much have an endless world with its 400 billion stars galaxy.

X3 is a much more complex sandbox (you can build your own space empire) which could also work in an endless map.

Mount and blade in endless space could also work.

Though an endless world is really not needed when you consider that you can sink 1000s of hours in non endless worlds of such games. It just needs to be big enough and the gameplay will take care to make it fun forever.

1

Share this post

Link to post

Share on other sites

I've been trying to make games like that for you for many years, Levi. Nobody cares and nobody is interested. I wouldn't hold your breath, nobody wants an "artificial universe". You can't give one away...

-5

Share this post

Link to post

Share on other sites

I've been trying to make games like that for you for many years, Levi. Nobody cares and nobody is interested. I wouldn't hold your breath, nobody wants an "artificial universe". You can't give one away...

Why? The only reason I can think of is that nobody has done it right yet, the community has become a little apprehensive when it comes to endless worlds and as a result, they often have cynical comments to make when faced with things like that. I know for a fact that not everyone has given up on the idea of a perfect endless world game, so if you ever shared that dream you should at least try to share your experiences and failures, or at the very least not say anything at all. BTW I hate cynicism. If everything in you says that someone is going to fail, then the best thing one can do to help them is to let them fail because their failure will offer a greater experience rather than giving up partway through, and who knows, you might be surprised.

Edited January 14 by Levi LohmanElaboration.

0

Share this post

Link to post

Share on other sites

You'd have to ask them why they have no interest in it. Not a single person has ever contacted me about it. It could just be because I am a "rock star game designer" and they don't allow us into the industry under any circumstances. They decided long ago that they didn't want to become like Hollywood, where you either have a big name actor or director or you don't get to make a big budget movie. They saw this same situation developing early in the history of their own industry with people like Sid Meier, Will Wright, and Jon Romero. They came up with the phrase "game designer as rock star" as "the worst person you can have in your office" as a means of saying "don't let the true professionals into the industry" without actually saying that. I was probably one of the inspirations for this phrase, and the poster child of exactly the types of people they didn't want to let in... because then who gets funded can be a random lottery instead of being a matter of who has the "rock stars". They don't want their business to work like Hollywood, and to do that they need to keep out anyone who might stand out among the crowd.

Share this post

Link to post

Share on other sites

You're getting way off topic Kavik, this is not the place to rehash your apparent grievances with the industry again.

If you want to discuss open world design your input is welcome. Ranting about how you think you have been wronged or "the industry isn't fair" is not - take it to another topic or blog entry if you really want to talk about that again.

Share this post

Link to post

Share on other sites

I was just answering his question, it was not a rant. I wasn't planning on continuing along those lines.

As for creating an artificial universe... "Time is the fire in which we burn."

I used to not like the fact that you had to wait so long for good games to be developed. My first console was a Nintendo GC, and it is what made me fall in love with video games. What I didn't like was that I had to wait many years for my favorite franchises to release new games. Then I got into PC gaming, and that completely changed my attitude about the subject. Some of the first games I bought for PC were so buggy, unfinished and corner-cut that they were practically unplayable until they got a lot of updates or I got a new PC. So I started to appreciate Nintendo and other companies that would rather make the fans wait than go through the shame of releasing an unfinished game. Detail over deadline.

0

Share this post

Link to post

Share on other sites

It's just personal preference, of course, but I've always only liked games on console if they are best controlled with a gamepad. Any game that is better played with a mouse and keyboard, I like better on the PC. In my mind, console games are gamepad games and anything else is better on PC. Even then, because of it's the greater capabilities and wider range of options of a PC (even if it is a gamepad game, you still have the keyboard to work with for example), I generally think of all games as being potentially better on PC. Not that console games can't be great games, it's just that there is always more to work with on PC where even if a gamepad is the best control device, you still have a keyboard and mouse to work with as well.

0

Share this post

Link to post

Share on other sites

By no means was I saying that one was superior to the other, I have bought PC games that were true gems. What I was trying to say is that to make good games, quality should be valued over the release deadline. Honestly, things are starting to getting a little too off-subject here for me, not that I'm complaining, It's just that I don't want this to be one of those posts where two people are dominating the entire conversation.

Edited January 15 by Levi LohmanSlight clarification.

0

Share this post

Link to post

Share on other sites

Instead of a discovery being just an achievement or new gameplay element, it should also offer the possibility to unlock more achievements and elements depending on how the player matches up or arranges the discovery with others.

Not realy,

All you do is obfuscate the achievements that are unlockable, these achievements still need to be made up, and these achievements will not be available from the start of the game.

you are right in the sense that, for a game that already has plenty of content, such a structuring of the content could increase the longevity of the gameplay by a percentage without getting grindy.

A good structuring of the content is something that gets forgotten in many games, but in design it comes chronologically just before playtesting.

Btw, the more common reason to make content unavailable to new players is to decrease the learning-curve.

0

Share this post

Link to post

Share on other sites

To make a computer game takes a lot of people, and all those people have to be paid. This means that, every day, a large amount of money is spent. There is great danger in saying "we will sell no wine before its time" when you spend $20,000 per day just on people's salaries. From the designer's point of view, for example, a game is never finished. It's not possible to finish a game. As our generation of game designers used to put it, "No game is ever finished, eventually someone wearing a suit rips it from your hands and puts it on the shelf".

The Star Fleet Universe is probably the best example of this. It's been "in development" for about 40 years now. Steve Cole has spent his entire life on it. Thousands of people have contributed too it over 40 years. It's nowhere near being "finished", and it never will be "finished" in terms of all 8 octants of the galaxy being complete. It is the most "complete" and "most finished" game ever made, and yet is probably another 40 years or so away from being truly "finished". SVC and the rest of us won't live long enough to "complete" it. And this is why game companies, especially computer games where a large team of highly paid people is needed, create schedules and deadlines. If they don't, they will never be "finished" because that, by our experience... takes hundreds of people 80-100 years.

0

Share this post

Link to post

Share on other sites

Designing a game to please everyone I think is probably too high a goal to acheive and likely unacheivable in fact so it really comes down to getting the gameplay right and keeping it interesting to maximise the number of people that would play it.

No Mans Sky whilst ridiculous in size, really had nothing in it once you break it down and who really cares if it had 15 quadrillion planets because it's impossible to see them all and there are other massive issues with the game.

Each planet was essentilally the same but a different color. The flora never changed and the fauna was laughable in a lot of places. When you break down the gameplay elements of the original release, it was mine stuff to repair your ship to fly to another planet and do the same trillions of times. People will get bored of that after a while as it's pointless.

Elite Dangerous suffers much of the same with it's bland gameplay relying far too much on RNG to generate content of shallow AI engagements.

Minecraft is different however OP but it depends on what you like. This is the key here and whilst you say it didn't appeal to you, it certainly does to others, especially kids it seems (Ask my 2 nephews and niece who over Christmas had me watching them for 6 hours making sure they swapped around every 15 minutes so they all got a turn LOL).

The Forest gives you goals which makes it engaging. There's also challenge and possible loss. The environment and sound is spot on, you can build and you need to hunt as well as defend yourself and there's also a story to follow.

DayZ was an open world game that millions loved and was the mother of all these open world survival games we see now. Look at a similar game, The Division by Ubisoft which lost something like 93% of it's player base in 3 months. Essentially the same game but didn't keep people long enough because after the story was done, there isn't really anything to do but play the same end story's over and over and over and over..... They added in more stuff however and the Underground is good. These games of course are not endless and if they were, it wouldn't make any difference. Humans are great at seeing patterns and if you keep seeing the same old thing, over and over, that's going to be an issue ala No Mans Sky - why did Hello Games think repetitive, simplistic gameplay was going to be a "thing"?

So I think what a lot of games miss out on when they are designed is something that compels the player to come back. That being said, some games have a finite life and that's it. Open world games though need good game mechanics that keep the player interested. So they need to offer complexity, challenge, risk, reward, creativity and unique experiences (off the top of my head). The mechanics also need to be down so that means movement, shooting, building, sounds architecture and of course the art design. All of these parts are critical and are what make great games great.

That being said, I'm not sure you can make an endless open world game and keep people playing it. After a while, people are going to move on because every game will feel samey at somepoint.

Share this post

Link to post

Share on other sites

I don't think it's really my place to reply in this thread, as 1. my answer just barely touches the subject and 2. I can do the same thing over and over for such a long time that I have psychologists lining up at the door to redefine madness.

However, I've played my fair share of open world games, including No Man's Sky, and the ones I've played the longest had this one thing in common: I could make them about me.

Minecraft didn't hold my interest for long as I was a square fellow, apparently named Steve and not much else (for me at least, I can see why the game is so popular). No Man's Sky tricked me into the hype, but while I could rename everything (if you come across a galaxy themed around latin terms for intercourse... sorry, I was running out of bands), it just stung that I couldn't rename my ship. Then Rebel Galaxy let me rename my ship and nothing else and it still did better for me.

Now, the reason I've clocked about five years on GTA is that my online character is me. Even though I am not a gun toting ginger with a seven figure bank account. But "me" enjoyed hanging in empty sessions collecting muscle cars, being a CEO, weapons dealer, collecting more muscle cars. Up to the point that I was explaining to friends I played with that doing a particular thing wasn't something "me" would do. And if anything was a repetition of moves it was GTA Online.

I know Los Santos isn't exactly and endless open universe, but it is an open world and I believe it also holds up for an open universe. Personal interest.

I don't know if I added to the conversation with this, or just enjoyed talking about myself, but that's my idea on it.

Similar Content

The more you know about a given topic, the more you realize that no one knows anything.
For some reason (why God, why?) my topic of choice is game development. Everyone in that field agrees: don't add networked multiplayer to an existing game, you drunken clown.
Well, I did it anyway because I hate myself. Somehow it turned out great. None of us know anything.
Problem #1: assets
My first question was: how do I tell a client to use such-and-such mesh to render an object? Serialize the whole mesh? Nah, they already have it on disk. Send its filename? Nah, that's inefficient and insecure. Okay, just a string identifier then?
Fortunately, before I had time to implement any of my own terrible ideas, I watched a talk from Mike Acton where he mentions the danger of "lazy decision-making". One of his points was: strings let you lazily ignore decisions until runtime, when it's too late to fix.
If I rename a texture, I don't want to get a bug report from a player with a screenshot like this:

I had never thought about how powerful and complex strings are. Half the field of computer science deals with strings and what they can do. They usually require a heap allocation, or something even more complex like ropes and interning. I usually don't bother to limit their length, so a single string expands the possibility space to infinity, destroying whatever limited ability I had to predict runtime behavior.
And here I am using these complex beasts to identify objects. Heck, I've even used strings to access object properties. What madness!
Long story short, I cultivated a firm conviction to avoid strings where possible. I wrote a pre-processor that outputs header files like this at build time:
namespace Asset
{
namespace Mesh
{
const int count = 3;
const AssetID player = 0;
const AssetID enemy = 1;
const AssetID projectile = 2;
}
}
So I can reference meshes like this:
renderer->mesh = Asset::Mesh::player;
If I rename a mesh, the compiler makes it my problem instead of some poor player's problem. That's good!
The bad news is, I still have to interact with the file system, which requires the use of strings. The good news is the pre-processor can save the day.
const char* Asset::Mesh::filenames[] =
{
"assets/player.msh",
"assets/enemy.msh",
"assets/projectile.msh",
0,
};
With all this in place, I can easily send assets across the network. They're just numbers! I can even verify them.
if (mesh < 0 || mesh >= Asset::Mesh::count)
net_error(); // just what are you trying to pull, buddy?
Problem #2: object references
My next question was: how do I tell a client to please move/delete/frobnicate "that one object from before, you know the one". Once again, I was lucky enough to hear from smart people before I could shoot myself in the foot.
From the start, I knew I needed a bunch of lists of different kinds of objects, like this:
Array<Turret> Turret::list;
Array<Projectile> Projectile::list;
Array<Avatar> Avatar::list;
Let's say I want to reference the first object in the Avatar list, even without networking, just on our local machine. My first idea is to just use a pointer:

Avatar* avatar;
avatar = &Avatar::list[0];
This introduces a ton of non-obvious problems. First, I'm compiling for a 64 bit architecture, which means that pointer takes up 8 whole bytes of memory, even though most of it is probably zeroes. And memory is the number one performance bottleneck in games.
Second, if I add enough objects to the array, it will get reallocated to a different place in memory, and the pointer will point to garbage.
Okay, fine. I'll use an ID instead.
template<typename Type> struct Ref
{
short id;
inline Type* ref()
{
return &Type::list[id];
}
// overloaded "=" operator omitted
};
Ref<Avatar> avatar = &Avatar::list[0];
avatar.ref()->frobnicate();
Second problem: if I remove that Avatar from the list, some other Avatar will get moved into its place without me knowing. The program will continue, blissfully and silently screwing things up, until some player sends a bug report that the game is "acting weird". I much prefer the program to explode instantly so I at least get a crash dump with a line number.
Okay, fine. Instead of actually removing the avatar, I'll put a revision number on it:
struct Avatar
{
short revision;
};
template<typename Type> struct Ref
{
short id;
short revision;
inline Type* ref()
{
Type* t = &Type::list[id];
return t->revision == revision ? t : nullptr;
}
};
Instead of actually deleting the avatar, I'll mark it dead and increment the revision number. Now anything trying to access it will give a null pointer exception. And serializing a reference across the network is just a matter of sending two easily verifiable numbers.
Problem #3: delta compression
If I had to cut this article down to one line, it would just be a link to Glenn Fiedler's blog.
Which by the way is here: gafferongames.com
As I set out to implement my own version of Glenn's netcode, I read this article, which details one of the biggest challenges of multiplayer games. Namely, if you just blast the entire world state across the network 60 times a second, you could gobble up 17 mbps of bandwidth. Per client.
Delta compression is one of the best ways to cut down bandwidth usage. If a client already knows where an object is, and it hasn't moved, then I don't need to send its position again.
This can be tricky to get right.

The first part is the trickiest: does the client really know where the object is? Just because I sent the position doesn't mean the client actually received it. The client might send an acknowledgement back that says "hey I received packet #218, but that was 0.5 seconds ago and I haven't gotten anything since."
So to send a new packet to that client, I have to remember what the world looked like when I sent out packet #218, and delta compress the new packet against that. Another client might have received everything up to packet #224, so I can delta compress the new packet differently for them. Point is, we need to store a whole bunch of separate copies of the entire world.
Someone on Reddit asked "isn't that a huge memory hog"?
No, it is not.
Actually I store 255 world copies in memory. All in a single giant array. Not only that, but each copy has enough room for the maximum number of objects (2048) even if only 2 objects are active.
If you store an object's state as a position and orientation, that's 7 floats. 3 for XYZ coordinates and 4 for a quaternion. Each float takes 4 bytes. My game supports up to 2048 objects. 7 floats * 4 bytes * 2048 objects * 255 copies = ...
14 MB. That's like, half of one texture these days.
I can see myself writing this system five years ago in C#. I would start off immediately worried about memory usage, just like that Redditor, without stopping to think about the actual data involved. I would write some unnecessary, crazy fancy, bug-ridden compression system.
Taking a second to stop and think about actual data like this is called Data-Oriented Design. When I talk to people about DOD, many immediately say, "Woah, that's really low-level. I guess you want to wring out every last bit of performance. I don't have time for that. Anyway, my code runs fine." Let's break down the assumptions in this statement.
Assumption 1: "That's really low-level".
Look, I multiplied four numbers together. It's not rocket science.
Assumption 2: "You sacrifice readability and simplicity for performance."
Let's picture two different solutions to this netcode problem. For clarity, let's pretend we only need 3 world copies, each containing up to 2 objects.
Here's the solution I just described. Everything is statically allocated in the .bss segment. It never moves around. Everything is the same size. No pointers at all.

Here's the idiomatic C# solution. Everything is scattered randomly throughout the heap. Things can get reallocated or moved right in the middle of a frame. The array is jagged. 64-bit pointers all over the place.

Which is simpler?
The second diagram is actually far from exhaustive. C#-land is a lot more complex in reality. Check the comments and you'll probably find someone correcting me about how C# actually works.
But that's my point. With my solution, I can easily construct a "good enough" mental model to understand what's actually happening on the machine. I've barely scratched the surface with the C# solution. I have no idea how it will behave at runtime.
Assumption 3: "Performance is the only reason you would code like this."
To me, performance is a nice side benefit of data-oriented design. The main benefit is clarity of thought. Five years ago, when I sat down to solve a problem, my first thought was not about the problem itself, but how to shoehorn it into classes and interfaces.
I witnessed this analysis paralysis first-hand at a game jam recently. My friend got stuck designing a grid for a 2048-like game. He couldn't figure out if each number was an object, or if each grid cell was an object, or both. I said, "the grid is an array of numbers. Each operation is a function that mutates the grid." Suddenly everything became crystal clear to him.
Assumption 4: "My code runs fine".
Again, performance is not the main concern, but it's important. The whole world switched from Firefox to Chrome because of it.
Try this experiment: open up calc.exe. Now copy a 100 MB file from one folder to another.

I don't know what calc.exe is doing during that 300ms eternity, but you can draw your own conclusions from my two minutes of research: calc.exe actually launches a process called Calculator.exe, and one of the command line arguments is called "-ServerName".
Does calc.exe "run fine"? Did throwing a server in simplify things at all, or is it just slower and more complex?
I don't want to get side-tracked. The point is, I want to think about the actual problem and the data involved, not about classes and interfaces. Most of the arguments against this mindset amount to "it's different than what I know".
Problem #4: lag
I now hand-wave us through to the part of the story where the netcode is somewhat operational.
Right off the bat I ran into problems dealing with network lag. Games need to respond to players immediately, even if it takes 150ms to get a packet from the server. Projectiles were particularly useless under laggy network conditions. They were impossible to aim.
I decided to re-use those 14 MB of world copies. When the server receives a command to fire a projectile, it steps the world back 150ms to the way the world appeared to the player when they hit the fire button. Then it simulates the projectile and steps the world forward until it's up to date with the present. That's where it creates the projectile.
I ended up having the client create a fake projectile immediately, then as soon as it hears back from the server that the projectile was created, it deletes the fake and replaces it with the real thing. If all goes well, they should be in the same place due to the server's timey-wimey magic.
Here it is in action. The fake projectile appears immediately but goes right through the wall. The server receives the message and fast-forwards the projectile straight to the part where it hits the wall. 150ms later the client gets the packet and sees the impact particle effect.

The problem with netcode is, each mechanic requires a different approach to lag compensation. For example, my game has an "active armor" ability. If players react quick enough, they can reflect damage back at enemies.

This breaks down in high lag scenarios. By the time the player sees the projectile hitting their character, the server has already registered the hit 100ms ago. The packet just hasn't made it to the client yet. This means you have to anticipate incoming damage and react long before it hits. Notice in the gif above how early I had to hit the button.
To correct this, the server implements something I call "damage buffering". Instead of applying damage instantly, the server puts the damage into a buffer for 100ms, or whatever the round-trip time is to the client. At the end of that time, it either applies the damage, or if the player reacted, reflects it back.
Here it is in action. You can see the 200ms delay between the projectile hitting me and the damage actually being applied.

Here's another example. In my game, players can launch themselves at enemies. Enemies die instantly to perfect shots, but they deflect glancing blows and send you flying like this:

Which direction should the player bounce? The client has to simulate the bounce before the server knows about it. The server and client need to agree which direction to bounce or they'll get out of sync, and they have no time to communicate beforehand.
At first I tried quantizing the collision vector so that there were only six possible directions. This made it more likely that the client and server would choose the same direction, but it didn't guarantee anything.
Finally I implemented another buffer system. Both client and server, when they detect a hit, enter a "buffer" state where the player sits and waits for the remote host to confirm the hit. To minimize jankiness, the server always defers to the client as to which direction to bounce. If the client never acknowledges the hit, the server acts like nothing happened and continues the player on their original course, fast-forwarding them to make up for the time they sat still waiting for confirmation.
Problem #5: jitter
My server sends out packets 60 times per second. What about players whose computers run faster than that? They'll see jittery animation.
Interpolation is the industry-standard solution. Instead of immediately applying position data received from the server, you buffer it a little bit, then you blend smoothly between whatever data that you have.
In my previous attempt at networked multiplayer, I tried to have each object keep track of its position data and smooth itself out. I ended up getting confused and it never worked well.
This time, since I could already easily store the entire world state in a struct, I was able to write just two functions to make it work. One function takes two world states and blends them together. Another function takes a world state and applies it to the game.
How big should the buffer delay be? I originally used a constant until I watched a video from the Overwatch devs where they mention adaptive interpolation delay. The buffer delay should smooth out not only the framerate from the server, but also any variance in packet delivery time.
This was an easy win. Clients start out with a short interpolation delay, and any time they're missing a packet to interpolate toward, they increase their "lag score". Once it crosses a certain threshold, they tell the server to switch them to a higher interpolation delay.
Of course, automated systems like this often act against the user's wishes, so it's important to add switches and knobs to the algorithm!

Problem #6: joining servers mid-match
Wait, I already have a way to serialize the entire game state. What's the hold up?
Turns out, it takes more than one packet to serialize a fresh game state from scratch. And each packet may take multiple attempts to make it to the client. It may take a few hundred milliseconds to get the full state, and as we've seen already, that's an eternity. If the game is already in progress, that's enough time to send 20 packets' worth of new messages, which the client is not ready to process because it hasn't loaded yet.
The solution is—you guessed it—another buffer.
I changed the messaging system to support two separate streams of messages in the same packet. The first stream contains the map data, which is processed as soon as it comes in.
The second stream is just the usual fire-hose of game messages that come in while the client is loading. The client buffers these messages until it's done loading, then processes them all until it's caught up.
Problem #7: cross-cutting concerns
This next part may be the most controversial.
Remember that bit of gamedev wisdom from the beginning? "don't add networked multiplayer to an existing game"?
Well, most of the netcode in this game is literally tacked on. It lives in its own 5000-line source file. It reaches into the game, pokes stuff into memory, and the game renders it.
Just listen a second before stoning me. Is it better to group all network code in one place, or spread it out inside each game object?
I think both approaches have advantages and disadvantages. In fact, I use both approaches in different parts of the game, for various reasons human and technical.
But some design paradigms (*cough* OOP) leave no room for you to make this decision. Of course you put the netcode inside the object! Its data is private, so you'll have to write an interface to access it anyway. Might as well put all the smarts in there too.
Conclusion
I'm not saying you should write netcode like I do; only that this approach has worked for me so far. Read the code and judge for yourself.
There is an objectively optimal approach for each use case, although people may disagree on which one it is. You should be free to choose based on actual constraints rather than arbitrary ones set forth by some paradigm.
Thanks for reading. DECEIVER is launching on Kickstarter soon. Sign up to play the demo here!

I am animator by hand, and i am doing game animation for at least 8 years so far. During the last 2 years, i came with a idea for game and maybe some day, i want to start indie game company. As i am thinking to start game company, i am also thinking what kind of value i can give to the company. For example, am experience in animation,sales(I was selling web development services, before i jumped to gaming), bit of rigging- just not for production, i am learning on the side as well. The rest of the gaming production, like modeling, concept art, texturing, i am total noob or to say better, i am no near interest to do modeling for example, don't have such a patience to do it. But before characters and things are made for animating, what the hell i am would do?
Also, what is the ideal size of the founding team of a game company? Positions to be filled mostly are, Concept artist, Modeler/Texture artist, programmer, animator-rigger. And later would need more people to join, like more animators, programmers, sound, fx,etc.

And lastly, do i need to have something,like a prototype, to show people and get them interest, or should i ask someone i know, for skill that i lack, for example, Modeling would be great, texturing and rigging, and to start all together from scratch?

Hi all, I am starting to develop a tactics game and ran into a problem I had not thought of. I began by drawing a screen with a hex grid, and this is no big deal. I got that working fine. But, I realized it didn't look quite right. This is because in most strategy games, you're not looking straight down. There is a bit of a tilt. Attached is an example of what I mean. The hexagons on bottom are larger than the hexagons on top, and I'm unsure of how to go about adding this effect. Especially when you consider that some maps may be of different sizes.
I'm not sure if this is the right place to post something like this, but it seems as though some sort of linear transformation would be applied? No? I don't even know where to begin in a problem like this.
Thanks.

I have limited programming experience in C++, but have always had a passion for games. Where do I start? I have a rough idea of the type of game I want to develop and am ready to commit the time necessary to learn new languages. Are mobile games too difficult to begin with? Should I begin learning the basics of keyboard controls before attempting touch screens? I would appreciate any input or advice!
Thanks!
Nick1

Dene Carter, Managing Directory @ Fluttermind LLC (@fluttermind)
From Indie to Fable and Back. 30 Years of Wisdom.
Started writing games in 1984 when he was 14 years old. What has he done in 33 years?
Druid - Commodore 64
Original Dungeon Keeper core team
Fable franchise
and more
Indie through AAA.
"I am an idiot" - first learned in 1984, and every year after.
Rockman - made $7500 for 2 weeks of work. Figured he could make 26 games a year, or $438k in today's money.
Takeaway: Really stupid at 14.
Even in 1980's, developer only got 12-14% royalties.
(Side note: Dene is fun to listen to. Recommend this on the Vault when it goes online.)

You are not your players.
Made a black and white game on a Spectrum, which was color. Did it because he was poor. Problem is his audience were not poor, and had color TV's. Reviews were not nice.
Players see things completely different to you. Do not forget that your players have not seen the game as much as you.
Avoid difficulty/complexity-creep. The real world has distractions and beer - they don't care about your game as much as you do.
Test your mobile game on the toilet - that's what your real players do.
Fundamentally, players live inside their own brains, not yours.
Those you ignore will ignore you in return. Design for your players' minds, not for you.
Generalizing is Really useful
"An expert who is too narrow has difficulty colaborationg" - Valve Employee Manual
Did a lot of things over the course of his career. Everyone did everything in the 1980's and 1990's. Most developers generalized.
Developing a broad skill-set aids communication. Large teams require collaboration and clear communication.
Knowledge breeds respect (never say 'JUST'). 'Just' suggests a task is easy. It might not be.
Ignorance is an energy. Don't forget you are human. You are designed to adapt and can do anything if you put your mind to it.
Be a human. Learn a skill outside your area. Programmer learn how to 3D model. Artist learn how to code. Learn music, theater. Think of yourself as an artist.
Rapid Team Growth is Dangerous
"If your team can eat more than two pizzas, it's too large." Werner Vogels, Amazon VP/CTO
Early Fable - 3 developers. Communication very easy. Later Fable, team grew bigger. At 12 people rumor mill started to develop. Can't have everyone in every meeting at same time. Pockets and cliques develop.
Fred Brooks. Communication paths don't grow linearly. Team communication grows exponentially. [n * (n-1)] / 2 8 people on team, 28 connections.
Ringelmann Effect - "Larger groups lead to less motivation & coordination & productivity."
Decreased motivation - larger group, start to feel like a cog in the machine. Decreased coordination - communication pathways explode.
Suggestion: Increase identifiability. Make sure everyone knows everyone's contribution.
Most of all: think before growing your team.
Blandness Has Its Uses
Pursuit of excellence can be wasteful. Sounds counterintuitive.
Blandness helps disguise repetition. Think reusing assets. Players notice the patterns.
When asking for something to be made, communicate the context of assets - how will they be seen or heard? Often find they need to be bland.
Prototypes Can Be Misleading
Experiential games are difficult to prototype. More useful for mechanical games.
Fable only came together at the very end - threw away at least one entire combat system. Looking back, it wasn't polished not necessarily bad.
Bland prototypes are better than ugly ones for experiential. Keep prototype completely separate.
Define prototypes success criteria.
Art Style is More Important Than You Think
Curate rather than create
Style can hide the fact you can't draw. Restrict complexity.
Style is marketing. Unique style tells players there may be something unique about your game.
Streamline Your Process
What is your iteration cost? Recognize your cost to try something and learn from it.
Making your life easier is real work. Resist self-sabotage. (context of making tools)
Closing Thoughts
Don't let technology dictate your game's core promise.
Static screenshots have to look good, too. No 1 pixel lines.
Don't worry about the things people don't ever get to see.
Don't panic if your game sucks - fix it.
Editor thought: Really enjoyed this talk. Dene is a fun speaker, and his advice was raw, real world advice for anyone aspiring to make it in game development.