Okay, first things first.
Species Alpha 0.4.1 comes out in a week, on Sunday 15th July.
Check the still-ongoing development thread for info on what it contains: over here I’m just going to say “gene splicing and head animation” and leave it at that.
Now on with the show…
I was originally going to keep this planned feature a secret, since I’ve never done anything like it before, but Skylimit preempted me in the comments by simultaniously coming up with a fairly similar idea. I would call that memetic convergent evolution if I was trying to be thematically pretentious, but since I’m still trying to maintain the illusion that I don’t think I’m smarter than everybody else I won’t.
Anyway, the feature is, quite simply, Online Multiplayer.
Now before I go any further, I want to draw everyone’s attention to a particular archetype/stereotype. On many games programming forums, there will be a few new threads with a title like “help me make my game”, or “my game idea” or something equally vague. They will often be the first post by this particular user, (and in many cases the last) and will consist of something like this:
“i have a game idea for a great game I want to make its an MMORPG and wil make lots of mony but I don’t know how to program what do i do plz help”*
And it is always, always, an MMO. I don’t know why, and I’m not even going to try to guess.
I mention this archetype so that I can say: this is not me. I know my limitations, and a genuine MMO is fairly well beyond them. What I’m suggesting for Species is not so much a way to play the game with other people as a way to expand the creatures world by connecting one border of your map to theirs and allowing creatures to wander fom yours to theirs, thus ‘combining’ your CPU power.
It’s at this point that I get excited, because this grid of connected worlds utterly demolishes the biggest restriction we have on the game: performance. Suddenly, the world of Species can be as close to infinite as makes no difference. We go from petrie dish to planet in one hit! And with some sort of multiplayer map view, you could see how the descendants of creatures from your world are doing other worlds, and in the overworld in general.
My plan is to connect the borders directly: essentially making it so that, to the creatures, there are no borders at all. There won’t be any ‘migration’ routine or any decision on the creatures part to go to the next world over: they’ll just cross the edge in the course of their usual wandering and appear in your neighbours world. I like this idea because it means you’re not just connecting standalone worlds and allowing them to pass creatures to each other: you’re actually expanding a single, gigantic world.
And then my excitement starts to die down as I consider the problems this poses.
On the immediate, border-to-border scale we’ve got time accelleration. Imagine a world running at 10x connected to a world running at 1x. Things turn into an episode of Dr Who at the border.
This problem isn’t too bad, though, compared to others. What about players connecting and disconnecting? This is the equivilent of huge chunks of terrain, and all the creatures and vegetation in them, appearing and disappearing with no warning.
So far we’ve come up with four solutions, none of them ideal:
Static. This mode ensures the player can keep their world and their position in the overworld, no matter what.
– – When a player disconnects their world ‘freezes’: creatures can no longer pass into, out of, or through their world.
– – The advantage is that the overworld as a whole remains static across multiple sessions: perfect for small, organised simulations, where you can turn all machines in the network on at the same time.
– – The disadvantage, obviously, is that entire chunks of the map can vanish and become impassable if someone shuts the game off.
Dynamic Player. This mode sacrifices player persistance to enable a large, semi-static overworld.
– – When a player disconnects, another player on the network (someone at the ‘edge’ of the overworld) or an incoming player automatically loads and begins simulating their world.
– – The advantage here is that a large, disorganised network can still run a relatively controlled and scientific simulation.
– – The disadvantage is that you as the player won’t be able to call any particular world or species your own.
Dynamic Overworld. This mode keeps player persistance and prevents impassable grid squares by turning the overworld into a constantly-shifting and changing environment.
– – When a player disconnects, someone else on the network (probably a neighbour) has their entire map picked up and moved into the vacant spot. (this may initiate a cascading shuffle, since someone else may now have to occupy their spot)
– – The advantage is obvious: the player gets to keep their map across multiple sessions and also connect to a large, disorganised network.
– – The disadvantage is the effects mobile terrain. A particularly lucky map could move halfway across the overworld, seeding it’s creatures into other maps the whole way.
Virtual Overworld: This mode treats the overworld not as a 2d grid of terrain, but as a web of connected nodes.
– – When a player disconnects, rather than their neighbours being physically shuffled about, only the links are re-arranged, with the nodes being pulled into position by a web-physics simulation similar to what the Mod Manager has.
– – The advantage’s are similar to the Dynamic Overworld option, with the overworld being less mobile: rather than shuffling world bits about, the borders will just grab onto each other and tie the web tighter together. And when they re-connect, they can return to the same spot and connect to the same neighbours.
– – The disadvantage is that it can’t be represented as a ‘planet’ of contiguous terrain anymore. If you’re having trouble visualising what I mean: which square is connected to the north-east corner of square 8 in the far-right diagram above?) As a result, rather than zooming out to some sort of impressive satellite view showing mountains and forests and rivers, we’d need to display the web of connected nodes.
The other problem is that some of this conflicts with other idea’s we’d had. We had considered building the AI facility/science lab that will serve as the player avatar into the crater walls. This neatly solves the problem of the buildings and nursary taking up space and getting in the road of the wild creatures, means I don’t have to implement per-creature collision for them which is a performance bonus, and it looks cool. Unfortionately, if the overworld is meant to be contiguous, the crater has to go (at least in multiplayer), which means we’re back to the original, relatively boring idea of dumping the science base in the middle of the map.
Actually, even if it’s not contiguous, we’ll still need to ‘connect’ the map to it’s neighbours somehow so that there’s at least an explanation for where the disappearing creatures at the border are going. I’m pretty sure the blind legless slugblobs aren’t quite capable of scaling the crater walls.
I’m actually in need some suggestions here: this is all very much long term stuff (we haven’t even worked out the design style for the science base yet: all I’ve got in my notes is “somewhere between jurassic park, NASA, and a volkswagon-factory”), but it’s presenting some interesting design challenges. How do we reconcile the need for an open overworld with the need for overworld stability? Where do we put the AI complex and nursary? How many roads can a man walk down?
*footnote: In the interests of keeping this post constructive and not just laughing hysterically at the n00bs: if the archetype above sounds like you (minus the lack of grammar), here’s a few suggestions:
a) Start small. You’ll learn a lot faster making a 2D game or a mod for another game, and you’ll screw up your large project less in the long run because you’ll make all the beginner mistakes in the small project, rather than in the large.
b) What programs you should be using depends on how keen you are and how much prior experience you have. If you’ve never programmed before in your life, try making a simple Pong clone in Macromedia Flash or Game Maker, or better yet in Visual Studio’s Windows Forms Designer (that will also introduce you to Visual Studio, which will help later). You can do it in an afternoon (there’s loads of online tutorials around), and it will at least give you a very basic idea of what is involved. If that goes well, grab a copy of Vistual Studio and decide what programming language you want to learn. I like C#, but really, the similarities are more important than the differences. If you can program in one language, you can learn to program in most of them.
c) If you’re already a programmer, or you’ve done (b) and decided this programming stuff doesn’t seem too hard, you’ve got a few options: use/mod an existing game engine (if you’re making an FPS, you might as well start with the Crysis world editor or the Unreal Engine), download a genre-independant game engine (I’ve heard good things about Unity), or download a framework like XNA or even just native DirectX and build your own engine. Which way you go depends on how keen you are: if you want complete freedom and are willing to pay for it with increased time and effort, go straight for XNA or DirectX. If you’re happy to be somewhat restricted, but get your game out months in advance, go for a pre-existing engine.
d) Don’t try to make games on your own for the money. The AAA industry is already doing that, and they’ve got rediculous budgets to throw at it, so competing with them is useless: if you want a part of that action you’ll have to go
sell your soul to join them. And if you want to make loads of money from the indie crowd, ala Minecraft, you're not going to get away with pandering to what you think they want, because they want originality (which is a nice way of saying they don't have the slightest clue what they want until they see it. Seriously, imagine pitching the Minecraft concept to anyone prior to the game being made). If you're going to sell to the indie crowd, then you need to be making games because you want to make games, not for any other reason.
“We will of course be laughing hysterically at the n00bs anyway in an attempt to crush their naive enthusiasm under wave upon wave of sadistic cynicism.”