It’s slightly buried in there, but I spotted this:
It’s slightly buried in there, but I spotted this:
It’s slightly buried in there, but I spotted this:
Beware – latest version of Google Docs has the Gmail bug whereby emails (documents) randomly disappear and become completely inaccessible (this happens a few times a year with Gmail’s IMAP client). With Gmail, you can use the web interface to get around it and see the actual email – but with Google Docs, I don’t know of an alternative route. What you get is that Google appears to have deleted your data, with no comeback.
I just saw it now with Google Docs where a doc created yesterday allegedly didn’t exist any more – it had been removed from history, from recent documents, and … most distressing of all … it resulted in zero hits if you searched for it.
There’s none – it’s just Google’s software being stunningly bad (again).
You have to wait. And pray. And wait some more. And click random things. And pray some more.
For me, clicking around on the different tabs on the left hand side (Home, All Items, Owned by Me) after a minute or so it randomly reappeared.
I’m coming back to this topic more and more, because these abuses of web and HTML services are getting more and more damaging to the users.
If the “old” version of Google Docs doesn’t have this bug, it doesn’t matter – Google has already confiscated it from us. Unlike the core concept of desktop, laptop, and home computers … Google repeatedly takes the software that you possessed, and destroys it, for no reason other than to make things a little easier for engineers who don’t like to support the bad code they shipped.
That’s what this is about: people who use Cloud/SaaS to avoid taking responsibility for the apps they created.
Two things here: if you run any Rails site, check out the security hole ASAP if you haven’t already. You might be safe – but given that even GitHub wasn’t, I’d double check if I were you. (The Rails community seemingly isn’t patching it – and there’s nothing recent on the Security list. Which leaves me going: WTF? The evidence is right there on GitHub of how bad this is right now, in the wild).
Secondly … what just happened? Apart from doom and gloom and “the end of every unpatched Rails site on the planet”, there’s a fun story behind this one. As someone put it “it’s the whitest of white-hat attacks” (i.e. the “attacker”‘s motives appear extremely innocent – but foolish and naive)
It seems that GitHub got hit by the world’s nastiest security hole, in Rails – trivial to take advantage of, and utterly lethal. The hole appears to allow pretty much anyone, any time, to do anything, anywhere – while PRETENDING to be any other user of the system. So, for instance, in the attack itself, someone inserted arbitrary source code into a project they had no right to.
Hmm. That’s bad. It effectively destroys GitHub’s entire business (it’s already fixed, don’t worry)
But it gets worse … it’s a flaw in the RoR framework, not GitHub itself (although apparently GitHub’s authors were supposed to know about the flaw by reading the Rails docs, as far as I can tell from a quick glimpse at the background). Rails authors have (allegedly) known about it and underestimated how bad it is in the wild, and left Rails completely open with zero security by default.
So, allegedly, the same attack works for most of the web’s large Web 2.0 sites – any of them that run on Rails.
Who was the perpetrator of this attack? Ah, well…
Classy. Dangerous (high risk of someone calling the police and the lawyers), but if people won’t believe you, and *close* your issues, claiming it’s not that important, what more amusing way to prove them wrong?
I can’t state this strongly enough: never attack a live system. Just … don’t.
Any demonstration of a security flaw has to be done very carefully – people have been arrested for demonstrating a flaw allegedly *at the owner’s request*, because under some jurisdiction’s it’s technically a crime even if you’re given permission. In general, security researchers never show a flaw on a real system – they explain how to, and do it on a dummy system, so no-one can arrest them.
(why arrest the researcher? Usually seems to be no reason beyond ass-covering by executives and lawyers, and a petty vindictiveness)
Homakov appears to have been ignorant of this little maxim, hence I’m writing it here, let as many people as possible know: never attack a live system (unless you’re very sure the owners and the police won’t come after you)!
On the plus side, they fixed it within hours, on a weekend. And then proceeded to tell every single user what had happened. And did so in a clever way – they put a block on all GitHub accounts that practically forces you to read their “here’s what happened, but we’ve fixed it” message. They could have kept it quiet.
Which is all rather wonderful and reassuring.
On the minus side, IMHO they rather misrepresented what actually happened, portraying it more as a malicious attack, and something they fixed, rather than what it was – the overspill from an argument between developers on some software that GitHub uses.
And they initially reported they’d “suspended” the user’s account. Normally I’d support this action – generally it’s a bad idea to let it be known you’ll accept attacks and not fight back. But in this case it appears that GitHub didn’t read the f***ing manual, and the maintainers apparently (based on reading their tickets on the GitHub DB) refused to accept it was a serious problem – and apparently didn’t care that one of their own high-profile clients was wide open and insecure. The attack wasn’t even against GitHub per se – it was against the Rails team who weren’t acting. IF it had e.g. been a defacement of GitHub’s main site, that would have been different, both in impact and in intent. Instead, the attack appears to be a genuinely dumb act by someone being naive.
Seems that GitHub agreed – although their reporting is a bit weak, it happened days ago, but they never thought to edit any of their material and back-link it.
“Now that we’ve had a chance to review his activity, and have determined that no malicious intent was present, @homakov’s account has been reinstated.
…and it’s pleasing to see that their reaction included a small mea culpa for being unclear in what they expect (although anyone dealing with security ought to be aware of this stuff as “standard practice”, sometimes it’s not security experts who find the holes):
“We haven’t been as clear as we should have been on how to responsibly disclose security problems, and for that I’m sorry. To prevent future confusion about security-related account suspension, and to make explicit our stance on responsible disclosure, we have added a section entitled Responsible Disclosure of Security Vulnerabilities to our Security policy.”
I’d expect: shame, weeping, and BEGGING the web world to forgive their foolishness. I’m not sure, but it’s going to be interesting to watch. As of right now, the demo’s of the flaw are still live. I particularly like one commenter’s:
drogus closed the issue 5 days ago
5 days ago
“I’m closing it (again).
@drogus was close it, but it still open.
kennyj closed the issue 5 days ago
“github bug?” LOL, no – massive security flaw :).
There’s good reasons for adopting Mongo, I’m unconvinced (but open-minded) that performance is one of them. Here’s a ROFLMAO viewpoint on it:
Obviously, MySQL’s not perfect, but in most cases I’ve seen, it’s been lack of competence on the developer side, and the lack of basic DBA skills – not problems with MySQL itself – that’s broken scalability. In which case, I’m a little suspicious that a company that fails to scale MySQL will equally fail to write their code correctly on Mongo. In many ways, throwing away SQL makes it much easier to prevent scalability…
The IM maintainers seem to be taking a leaf out of Apple’s book: if you don’t purchase the latest Apple OS upgrade (that most people don’t need), you can no longer use their software.
If you follow their 4-line install instructions, you’ll get:
dyld: Library not loaded: /usr/X11/lib/libpng15.15.dylib
Referenced from: …. /ImageMagick-6.7.2/bin/convert
Reason: image not found
…because that precise version of that library isn’t included in OS X generally, it’s only part of Lion, and it’s not included with ImageMagick – and ImageMagick for some reason has been compiled to refuse to run with anything except that precise version. Why? no explanation of this on the download page. I assume it’s just someone wasn’t paying attention, and went and linked a specific library. If so, it’s very frustrating that a simple noob mistake has just locked out anyone who’s not running Lion. Sigh.
Yes – I could go and download the source, and debug it, and fix it myself, because it’s Open Source. But if I’m going to consider that, then it would be cheaper to:
And what about if I were running this on a server (which, after all, is what IM is really here for)? Basically, I’d just be screwed :(. Unless I was happy building from source, with all the pain and suffering that entails.
Overall, it gives me the strong feeling: stop using ImageMagick. It’s too risky. Which is very sad, because in the past it’s been very popular in some (server) teams I’ve worked on, where it helped us do lots of great things (and, IIRC, some of the people I worked with contributed some small minor fixes back to IM. Although this was so long ago I might be imagining that).
IMHO, Flickr/Yahoo has one of the best user-authentication systems I’ve ever seen. I’m sure it’s no accident that Twitter (eventually) moved to a system that is extremely similar.
(NB: I don’t know if flickr copied if from someone else, but they were the first I remember seeing like this, many years ago)
It’s so sensitive that it’s currently blocking FlickrEdit’s (bad, broken, buggy) implementation. Not just with an error; not even with a warning … but with giant red letters, a yellow background, and a warning icon:
I was pretty annoyed that the app was seemingly so poorly written it wasn’t doing the desktop-based auth that it should be – and that it popped-open a web browser and “told” me to login (Flickr’s auth-system is slightly more seamless than that, and a much better user-experience).
But I was very impressed that Flickr noticed it too, and decided to warn me that this might be a scam of some kind…
…is this open-source project buggy, or has someone hacked the source and put in a virus? Hmm…
Well. I’ve contacted the project owners, and informed them. Interesting to see what they say.
In the meantime, I have so much faith in Flickr’s authentication system (e.g. I know that it doesn’t share passwords) that I’m happy to go ahead and use the application. There are very few systems where I’d do this, but flickr’s (approach) is one of them.
Conferences don’t make these public.
But they should.
So … here are the evaluations (from the audience) for our panel session at AGDC 09.
Judge for yourself whether you want to attend any future sessions featuring us again (Adam Martin, Bill Dalton, Rick Lambright, Joe Ludwig, Marty Poulin).
All of those are above average, and I’m glad that a particularly high number would recommend the session to their colleagues.
It seems that we did particularly well on fulfilling the remit (very high number for “met expectations”), and that our speakers had an awesome ability to communicate (almost 10% higher than average for the other speakers at the conference).
Comment 4 – yeah, something I’m unhappy about too, (it wasn’t our fault, it was the people running the conference), but there was nothing for it but to grin and carry on. Someone screwed-up the radio microphones, and we lost a lot of time at the start waiting for them to fix it. There was nothing we could do – they had connected the mics from a different room to *our* speakers. We didn’t find out until the person in the other room started talking, and it all came out through our speakers :(.
Comment 6 – we covered 4 topics (oops, audience can’t count :P). We all wanted to do more, but at GDC conferences, the organizers only give us 1-hour slots. With 4 speakers + moderator, I think that was pretty good, especially considering the time we lost at the start.
Perhaps someone will clone this format for a future conference (seems a good idea), and try to get a 2-hour slot for it?
With some WordPress-Fu, I’ve added a page that’s a category and auto-includes links with custom meta-information.
Or, in other words, there’s now a page where I can effortlessly post all my various bookmarked links to do with MMO development – and add my own commentary to each link – which you can’t ordinarily do. Which is why it’s taken me some time to get around to it (previous efforts to do this without customizing WordPress, or using plugins only, failed).
The (practically empty) page in all it’s (non-)glory can be found here:
Over the coming weeks, I’ll be posting much more stuff to it. I hope.
So, what’s the connection between ES and MMO, that I’ve so tantalisingly been dangling in the title of the last three posts? (start here if you haven’t read them yet).
The short answer is: it’s all about data. And data is a lot harder than most people think, whenever you have to deal with an entire system (like an MMO) instead of just one consumer of a system (like the game-client, which is the only part of an MMO that traditional games have).
Obviously, we need to look at it in a lot more detail than that. First, some background…
I work at a company where managing and directing a subset of the global core-tech is part of my day-to-day job, and I’ve been trying to find good, positive ways forwards. After a year in this role, I’m looking back and wondering whether it’s working for us, and where it’s been good and where it’s been bad. I don’t know what the perfect solutions are, so I’m just going to document the issues I’ve been wrestling with, and my current thoughts on what causes them, and my current ideas on what can be done to fix or avoid them. Personally, although I’m confident there is at least some role for some form of central technology in many games companies, I’m not sure yet what that role is.
Interestingly, there are no clear definitions on Google/Wikipedia for either “central technology” or “core technology” (the two main names I’ve heard used throughout the games industry). I see that as a warning that this is pretty under-explored territory I’m heading in. Cool.
The vague definition is: “sharing technology between multiple game-project teams and taking any new technology created during a game project and re-using it afterwards for other projects”.
There appear to be two major concepts wrapped up in the central-tech teams that I’ve seen. Some teams have only one of these, some have both. Usually, there are substantial examples of both, mixed within the same team. Often, the team has one focus in particular, but people outside the team in the rest of the company pick one or the other to *believe* the team has as their focus, depending upon what they personally most want out of the team. When this is divergent from the team’s own internal focus, things are off to bad start already.
Centralised technology (control, direction, authority, mandating):
– control: deciding what technology to create for “general use” by game-project teams
– direction: researching and reporting to the teams what tech is needed over the coming years by all game teams (yes, including telling teams themselves what they need)
– authority: deciding all general and long-term technology choices for ALL game teams, and making decisions on what tech teams are allowed to create and use
– mandating: forcing game-teams to use the centralised technology
Shared technology (re-use of common code, standing on shoulders of others, increased stability, decreased startup costs)
– re-use: finding code that gets written the same way on successive projects, and turning it into a library then never re-writing it again
– standing on shoulders: getting a domain expert to write difficult code once, turning it into a library, so that people who don’t understand enough of the tech to write it themselves can leverage it into future games without having to learn it themselves
– stability: using code in multiple successive projects so that eventually, after a few projects, it is extremely heavily tested and bug-fixed, much more so than any code written and used for the first time in a given project
– decreased startup: reduce the amount of time after a project goes into production that it takes to get the “first playable” version of the game running, because a lot of “typically useful” code already exists; unlike “re-use”, this is NOT necessarily code you will keep in the long-term – it’s just a leg-up to get you started quickly
In some cases, Central Technology / Core Technology teams have been growing on game development companies like mould on a piece of bread in recent years – gradually expanding their remits (and team sizes) until they end up affecting (usually negatively, despite the best of intentions!) every part of game development. I’ve had lots of experiences with centralised tech depts, although all of them in the games industry – interestingly, I never saw any software company even consider doing this when I worked in mainstream IT (across various industries), only games companies. And it seems a relatively recent phenomenon, too – at least at the scale that we see nowadays.
Typical problems cited by game-teams and third-parties affected by coretech (NB: these may not be fair!):
– a bunch of non-game programmers inventing arbitrary (undirected by user) solutions for potential (not verified because no concrete use-case) problems for not-yet-existent (haven’t started production yet) projects
– forced upon game-teams who have to twist and force their game into the inflexible (already built, without knowing the game-teams requirements because the game-team wasn’t around at the time) mould of the now-built core-tech (ask any EA employee about centralised technology initiatives…)
– generates pointless tools that are always in search of a problem to solve
Ultimately, the more bitter and cynical end of the spectrum of those who’ve experienced coretech come up with something that veers towards one of:
– it’s an excuse to spend infinite amounts of money forever without clear benefit and no oversight or restraints on feature set or spending
– it’s an excuse to take freedom and power away from game-teams and centralise it under an authority who has no reason to care if the game ships on time or with most appropriate feature-set
I suspect those two ultimate, generic criticisms map to the two typical definitions – the former to “shared tech” and the latter to “centralised tech”, although I’ve not looked at that in detail.
Most (not all!) of the experiences I’ve personally had in games companies have been failures, some narrowly (managing to achieve good things, but failing at what they were originally setup for), some spectacularly (failing to provide anything good at all, and even dragging down one or more game-projects with them). Some flailed about and killed projects in their wailing death-throes, others gorged on the corpses of the projects they’d killed and rose again from the bones of what was left, like some undead creature (which is a worrying precedent: “how do you kill that which has no life?”). It’s fair to say my experiences have been mostly bad ones :) … BUT: until it was called “central tech” or “core tech” the *same kind of initiatives* (re-using code, centralising decision-making, making powerful proprietary libraries) seemed to work well, generally, in teams that I was in or working with. The failure cases seem (at least in my small amount of experience) to be a relatively modern problem.
Speaking to people throughout the company where I currently work, and working with some of our pre-existing core-tech teams, I’ve found myself more and more asking a simple question: “why do we have Core Tech?” The answers have been illuminating…
“to write everything-including-the-kitchen sink, then on each game project only use the bits you need”
“recycle code from an existing project”
“I don’t know”
“write code that can be used and re-used in multiple projects”
“share the really cool and difficult stuff that one team did with other teams so they can benefit from its brilliance”
This has made me realise / remember a couple of things:
– non-programmers, and many inexperienced programmers, grossly underestimate the ratio in development time/cost between “making code that solves one problem” and “making a generic solution to a whole class of problems of which the current problem is just one example”. The first explanation described above is usually prohibitively expensive by *a large factor, maybe even an order of magnitude*, but many people seem unaware of this
– CT is sufficiently ill-defined and *poorly marketed internally* at most games companies that many internal dev staff genuinely don’t know why it exists or what purpose it’s supposed to be solving, let alone have the opportunity to rate the success or failure at that purpose
– many people notice that game development often involves re-solving or re-performing similar tasks, and wish for a perfect world in which you only ever have to do one “kind” of solution once, and then you get to re-use it forever after. That is largely true in mainstream IT, but sadly this seems to be far from the truth with games development. Personally, I suspect that the day the technology becomes derivative is the same day you realise your game itself is derivative, and has lost most of it’s fun.
I also wonder: if we don’t have CT, are you saying we wouldn’t re-use code? As a programmer, do you avoid finding code from old teams and finding ways to use it in your current project? Isn’t this a *basic part* of your job, part of what we pay you to do?
Is CT something that gives game-programmers an excuse to be less diligent than they would otherwise willingly be, thereby setting the scene for them to later complain that it’s “not as good as if I’d written it myself” (which is one of the cruelest things I’ve seen game-teams do to their CT teams, even if it’s true).
Project teams steal the best hires
– Project teams, especially Producers and Leads, have a hugely difficult problem (ship a game on time, and make it “fun”, so it sells well) and a huge amount of personal buy-in (if it fails, they have no second chance: their sole responsibility is that one project), and a huge amount of measurability of success (how many sales does the game make?). They have a vested interest in finding the best of the best people, and they have – ultimately – large budgets to recruit them with. If someone really good at developing code for games is in central tech, they usually get stolen for a game-team sooner or later. Central tech departments have too little visibility (how do you measure the brilliance or crapness of your coretech? there’s no sales figures!), no concrete deadlines (they randomly invent them, or borrow a game-project’s deadlines, but they really don’t sink-or-swim on that project-deadline like the game-team itself does!), and usually restricted budgets (if not, well, that’s when the unlimited-spending-without-reason problem kicks in…). They also are rarely as cool as working on a “real game”: most people joined the industry to Make Games, not to Write Random Code For Someone-else’s Game. CT finds it hard to retain the best people…
Writing code a second time is generally a lot cheaper than modularising the original version
– …I’m hoping this is self-obvious. But sadly it means that it is ALWAYS easier for any individual game-team to re-write *from scratch* the code they wrote for their last game than it is for CT to make the generic version that they’re usually asked for. Game-teams then get pissed that the CT team seems incompetent compared to them (they notice that the time they have to wait for CT to do something is MORE than it would take them to do it themselves).
CT is always setup as an “ongoing” task: there is no defined beginning or end to what they do. Games companies (developers and publishers) are very specifically geared towards “project-based” tasks.
– From the funding, to the project management, to the staff rewards schemes, everything about the games-industry is setup for project-by-project operation. We know (sort-of) how to make project-based development work (reasonably) well. We don’t really have ANY experience in non-project work – certainly anyone who’s only ever worked in the games industry (who are strongly self-selected by current standard recruitment procedures) will have no experience of non-project development. Is it any surprise we often screw it up? Moreover, is it any surprise that we have such difficulty making the non-project CT team be respected and understood by the purely project-based game-teams?
I’ve been kicking around some ideas on new directions to pursue. These may not be that great, but at the moment I don’t have to make any decisions, I just have to provide options, so I’m interested in any suggestions or alternatives…
This is one thing I’ve been trying: what *I* needed most urgently out of CT was the *expertise* component, and actually I didn’t really care about the code re-use etc. I knew I would, but I had a more pressing problem of two projects that lacked the necessary expertise in Network Programming to make an MMO. So … I created a tiny team dedicated to doing the network code for any game, and explicitly NOT to writing reusable network technology (NB: many years ago I ran a failed network middleware company, so I had a healthy apprecaition of how difficult and time-consuming it is to write generic network systems; I knew we simply did not have the time to write that stuff when we had projects already in full production that needed network code NOW).
Because of that, we can’t share the technology they create. Not yet, anyway. But we *can* share the expertise of the people in the team. They have to do a fair amount of international travel (bummer). So far, it seems to be working OK, but … it’s too small a sample and it’s been running too short a time (do you have any idea how hard it is to recruit really good network coders? :( ) to make any firm measurements of the success or failure of the approach.
I’ve seen a couple of examples of this, usually where senior people were frustrated by the progress of CT but needed some new example of the kind of stuff it was providing – so they went and started their own new pet-project to provide that, but outside the remit of the CT group. I’ve seen examples of this that were positive, and examples that were negative. Politically, it’s likely to cause a shitstorm as far as I can see, no matter how you sell it (unless this is blessed by CT itself, and none of the examples I’ve seen were their idea, although IIRC one of them did get CT’s agreement – they just knew they didn’t have BOTH the expertise AND the budget to provide it, so were happy to not have to take responsibility for it).
Certainly, it’s been the fastest way to get real significant progress on anything major: by doing it as a project, and going through the “standard” greenlight – pre-production – greenlight2 – production – ship cycle that all games companies are accustomed to for their games, large amounts of money have been secured quickly, and the projects have got going quickly.
The idea with this one is to overcome both the antipathy between game-teams and CT (by making them part of the same team), and also to ensure “automagically” that the CT team-members are working stuff that is guaranteed directly applicable to a real game – because they’re reporting to the Producer of a given game-team all the time.
If it works out well, this could solve all the problems. Although I’m not yet sure I understand how – in the long term – this is any different from having no CT at all. As noted earlier, this is closest to how I remember things working well before the idea of CT gained widespread popularity. OTOH, I’m not sure if that same situation will even work nowadays – the industry has changed a lot since then.
I’m not sure about this, but my vague memory is that CT grew in popularity and – more importantly – commonness (i.e. how many companies were doing it) in parallel with the axing of internal game-engine teams and the move towards licensing external game-engines.
I have suspicions that a lot of the confusion of “what do we have central technology for?” comes from this, two-fold:
– a) those companies that didn’t entirely get rid of their engine teams had people left a bit stranded, who ended up being folded into CT, and then tended to carry on working much as they had inside the engine team, despite the different overall task of the dept (and this happened partly because of the lack of clear direction from management about what the new team was for anyway)
– b) many of the companies that dispensed with their substantial proprietary engines they’d been using for years then jumped to Unreal et al found that actually the licensable engines weren’t as good as they’d been lead to (or had lead themselves to) believe: they couldn’t go back to having an engine team, but they needed a way to reduce the huge budgets they were spending on just basic modification and fixing of the external tech, that weren’t easily justifiable on the game-budget (because they weren’t forseen, and were adding NOTHING to the game’s end feature list), so they ended up creating a CT team to hide / provide the budget to do that kind of work
I could be completely and utterly wrong here – this is just some ideas that have been kicking around in my head recently.
EDIT: I’d also like to point to this good post about game-engines, and why you shouldn’t build them (not necessarily a “never do it” argument, but an explanation of why you might want not to).
Sometimes, it’s the little things you do that get noticed
Last year I would have ranted about how retarded it is that game data is either entirely inaccessible to the web, or only accessible to an “official” website. …This year, however, is all about the positive. Rather than rant about no one providing such a feed, this is an un-rant about someone providing such a feed.
I found this via a news post about character sheets being viewable online at 3rd-party sites, making the assumption this meant an XML feed was available, and then digging through the forums until I found the post with a link.
This is really cool, I should tell you, just in case you don’t get that.
Receptions like this help keep us motivated to keep doing more of them :).
Also known as: Nobody expects the Spanish Inquisition!
(because I’m now deviating from the original schedule I outlined in Part 1; what the heck, it was only a rough agenda anyway…)
First of all, there’s a bunch of good questions that have been raised in response to the first two posts:
Let’s start with that last one first.
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.
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:
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…
…was my section in the fourth GPG book from Charles River Media. And, sadly, although I tried to put some resources up on the web, a series of unfortunate events led to that all disappearing.
But now … they’re back! (and I’ll be adding more followup stuff in the coming weeks/months)
A few years ago, entity systems (or component systems) were a hot topic. In particular, Scott Bilas gave a great GDC talk (http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf – updated link thanks to @junkdogAP) on using them in the development of Dungeon Siege. The main advantages to entity systems were: