The following are hand-picked sections from the syllabus of the 3-year Cambridge University CS course. These are just syllabus, i.e. describing what you need to learn / teach yourself.
Category: programming
Part 2 – What is an Entity System?
Sadly, there’s some disagreement about what exactly an Entity System (ES) is. For some people, it’s the same as a Component System (CS) and even Component-Oriented Programming (COP). For others, it means something substantially different. To keep things clear, I’m only going to talk about Entity Systems, which IMHO are a particular subset of COP. Personally, I think Component System is probably a more accurate name given the term COP, but then COP is improperly named and is so confusing that I find if you call these things Component Systems they miss the point entirely. The best would be Aspect Systems, but then AOP has already taken ownership of the Aspect word.
An entity system is simply a part of your program that uses a particular way of breaking up the logic and variables of your program into source code.
For the most part, it does this using the Component Oriented Programming paradigm instead of the OOP paradigm – but there’s subtleties that we’ll go into later.
Another couple of days since the first one-day effort, and SFE single player is now working, albeit with a seriously crap AI:
Networked games use the internet, and the difficulties of making these games evolve on Internet Time, which means that the articles people wrote as recently as a year ago on how to make a networked or multiplayer game are already out of date. Most of the literature is more than 5 years old, and some as much as 10 years old – hopelessly out of date in the modern world of internet and online gaming.
Anyway, to get you thinking (I’m not providing definite answers here, but just some stuff to make you think about more carefully about how you’re doing your networking), here are some common rules that perhaps no longer apply the way they used to:
A few years ago, I wrote an article for Develop magazine – “10 MMOs you don’t want to do”.
Here’s 8 things you really shouldn’t do but that might seem like a good idea if you’ve never made an MMOG before.
All these are examples of things that have been done on real MMO projects, usually MMORPGs.
- use off-the-shelf middleware from the enterprise industry. It’s designed for completely different usage-patterns and cannot cope with MMO style usage. Equally, initially distrust anything from traditional Big Iron companies.
- think that Grid Computing will somehow magically solve the problems. It won’t (c.f. previous point).
- aim to code the server in a scripting language. You *can* run some scripts embedded in the server, but not the server itself – but even that can screw you when you’re trying to run thousands of scripts at once
- assume that front-end load-balancing will solve any problems. It won’t, all it does is increase the efficiency of your cluster by a small amount. And it usually won’t provide you with failover, because most game designs will end up kicking you from your server if it dies, so the failover never gets used at that level.
- ignore performance testing until mid-way through the project. If performance tests at 10% of the way through production say it’s slow, that means you’re in deep trouble – it does NOT mean that “we’ll come back and optimize it later”. Optimizing netcode and server code is NOT like traditional single-threaded local-only optimization: many of the things you’re dealing with (like LANs, and TCP/IP stacks) run orders of magnitude too slowly, so your optimization comes from imaginative system-architecture, not from optimizing small chunks of code at a time.
- ignore billing concerns in your core game design. Non-free MMOG’s are entirely about billing, which means that you have to design it in, and build it in to the tech design from an early stage. Retrospectively adding billing hooks and billing information to existing server codebases is often about as easy and effective as retrospectively making your code secure. Just don’t go there.
- hire an academic who specializes in networking, especially a PhD student (this gets done quite often). All this means is that they’ve obsessed with a very narrow slice of the many many problems, and generally they won’t know WTF to do about the rest of the problems. That’s no better than just promoting a general programmer to become “the new Server specialist”
- innovate on both technology AND game design at the same time. Either do a traditional MMO so you can re-use all the existing common wisdom for design, and get to market (or at least a stable GDD) fast, and use the slack that buys you to focus on better tech, or use the most boring tech you can think of (instance lots; do lowest-hanging-fruit in your tech design) and innovate on the gameplay
I reserve the right to come back and edit this to make it ten once I’ve had more sleep and can remember two more :)…
No, it’s not, it’s really not. In fact, source code is probably the worst form of documentation, it fails in most of the roles that documentation is actually required to fulfil (see bottom of this post for a shortlist).
But something else is…