Posts Tagged games
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.”
Slight change of tone today: I’m going to share a few thoughts about (video) game theory, because it’s been on my mind lately and also because I’ve been re-watching lots of Extra Credits episodes.
In order to understand a few things about the design I’m planning on implementing Species, it might be necessary to understand my personal preferences when it comes to games themselves. Role Playing Games which focus heavily on stats and levels and inventory management? Not keen on them. I dislike Real Time Strategy games as a rule (alright, I have some nostalgia surrounding Age Of Empires 1 and 2, and even I had to admit that Warcraft III was fun at times, but otherwise I can’t stand them). Turn-based strategy? Doesn’t interest me. MMORPG’s? *hiss*
What all these have in common is micro-management. The more I have to manage, the less fun I’m having. I’d much rather pilot a single fighter in Freelancer than a fleet in Eve Online, and I’d rather play as a soldier in Battlefield Vietnam (I’m not keen on the more popular battlefield games, but I had loads of fun mastering the impossible-to-fly helicopters in BF:Vietnam) than as a general in Command and Conquer.
I prefer to focus on and control a single entity directly in my games, not try to manage multiple groups of entities.
With that in mind, it might be surprising that it’s me building a game like Species. It has all the classic elements of a Real Time Strategy game: large groups of units controlled by their own AI. Indeed, I’ve had to adopt several RTS-conventions in the programming and design, like health-bars and selection circles. And then, underneath that, it has a statistic tree that puts most RPG’s to shame, and it has a unique series of stats for every single unit (disregarding clones).
The difference lies in what I’m going to offer the player. The simulation is sacrosanct: the player will be able to interact with it, but they won’t be able to control it. So they won’t be able to select a large group of creatures and tell them to migrate to a specific location. The creatures need to decide to do that on their own.
But that doesn’t necessarily leave the player helpless. They might, for example, be able to plant a lure that will attract those creatures to it, or perform an action that causes the creatures to follow them. This is macro-management, which is a whole different animal.
A good example of this sort of macro-management can be found in From Dust, an interesting but also fairly short game with a similar premise to Species: a game built on top of a simulation. In this case, the simulation is geography: the landscape changes and morphs on its own, with earth eroding, water picking up silt and depositing it when it reaches the sea, rivers changing course when they are blocked, lava flowing and creating rock as it cools, and so on. In From Dust, you don’t select tribe members and tell them where to go and what route to take: you simply tell them what you want them to do (‘colonise this’, ‘retrieve that’) and they work out the rest themselves. You aid, but never control, your tribes.
That’s a good description of the gameplay I have in mind for Species.
Of course, I’m releasing Species to the public pretty early, even by the standards of alpha releases. Kerbal Space Program (I’m sure I’ve mentioned that KSP is awesome at some stage, haven’t I?) was originally released at 0.7.0: Species will be released as a 0.4.0, with no player avatar and only the essentials of the simulation set up. There will be a bit of placeholder functionality: things like feed, kill, clone… but it’s a bit early in the piece to get too excited about the gameplay, because as far as I’m concerned there is no gameplay in the Alpha. At this stage it’s being released as a simulation: an interesting experiment… but not a game.
I can guarantee that will change significantly in later versions, however. Current long term plans for gameplay include artificial selection pressures and genetic manipulation techniques, environmental manipulation, discovery and collection (for example, the ability to slowly unveil the in-game tree of life by taking DNA samples and finding the fossils that creatures occasionally drop when they die), and a variety of (optional) achievements and challenges. I may have to set up a wiki or something to keep track of all my idea’s and how they are progressing.
But these are long term goals. As excited as I am about some of them, and as much as I think they have potential to broaden the appeal of the game, I’ll hold off while we’re in the alpha stage and work on polishing the simulation (I’ve got so many idea’s for that too! Squeeeee! *ahem*).
Right now though the priority is on less interesting (but necessary for release) features, like adding a Menu system, improving the UI, and opening up to the player functions of the game that I had previously been hard coding within the development environment (things like save/load functions, terrain generation, and whether the code generates ‘blank slate’ creatures, like in Dev Vid 2, or ‘random’ creatures, like in Dev Vid 3).
So the alpha won’t be as exciting as all that, but it will hopefully be a pretty big first step.
* * * * * *
“Huh. Not many jokes today either. Truth be told, I’m starting to think he’s kinda freaked out by the idea of actually releasing something in a semi-official capac- oh crap he’s curled up into a fetal position and is hyperventilating again. Gotta go!”