Archive for the 'Technology' Category

Kelly checks her work items. Uh oh, a client freeze. The KickStarter milestone’s been slipping and the money is starting to run out. Right now, showstoppers are exactly what they don’t need.

Thank god Jack’s the one on the forums trying to pass a vote on paring back the milestone requirements. If he can’t get the ‘No’ vote lower than 43%, refunding that percentage of the users will send them insolvent. It takes preternatural calm to operate at the intersection of community management and project management. Continue reading ‘Game development in 2021’

As a game developer I’m terribly jealous of the data-gathering schemes that companies like Valve and Bungie have going. Take Valve for example: they have detailed stats of where players get killed in their games. This is invaluable stuff for creating a consistent level of difficulty. I decided that I wanted a system like this of my own.

I started designing a database and looking at server-side programming languages. After I’d been working on this for a couple of days, I thought “logging events and aggregating statistics is incredibly common, someone must’ve done this already. If only I could use their code…”

Today I was walking along Courtenay Place and caught a scent that I hadn’t smelled in a long time. It brought back the strongest memories of old video arcades, Ghosts ‘n’ Goblins and pinball machines. It was like MAME had come to roost in my head for a moment.

When I tried to figure out what I was smelling, I realised it had come from the pokies machines in a pool hall that’d walked past. I still can’t pin down exactly what it was. Pine chipboard cabinets riddled with borer and marinated in tobacco smoke? Maybe I can just smell the coin-op?

One of the things I’ve been screwing around with is Unity 3D. Unity is a heavily data-driven game engine with an integrated level editor.

It’s so heavily data-driven that all the game code is written in script and the native code layer is almost entirely hidden (only in the pro version C++ plug-ins can be created). The engine contains most of the systems you’re likely to need for a game: 3D rendering with shaders, a level editor, a 3D asset pipeline, a physics engine, a rudimentary GUI system, network state synchronisation and RPC.

Unity is the subject of all kinds of hyperbole around the web. Back when I first heard about it, I wondered how much of the praise was down to Mac-heads who were simply delighted that the authoring tools were Mac-only. Since then, they’ve ported the tools to Windows and I’ve discovered that it really is pretty damn nice. It’s extremely quick to learn – I had a playable prototype of the game mechanic that I was trying out on Day 2 of using it.

Unity’s greatest asset is its clean design. It has a beautiful component architecture where you write update methods and event handlers in script, encapsulate them into component objects and then assemble them into game objects via drag ‘n’ drop. Exposing tweakable parameters is merely a case of declaring a component member public.

Unity is my first choice for prototyping, but I’m doubtful it’d be flexible enough to ship a full-scale game based on it. The drawbacks are:

No script debugger. The editor offers excellent facilities for inspecting and changing object properties in a running game session, but there’s no line-by-line script debugging.

No load/save framework. In spite of all the network serialisation stuff, you’re on your own when it comes to writing out a save game. There’s Dot-Net’s object serialisation and I/O though, so it’s not completely low level.

The GUI framework looks to be somewhat bare in places. No modal dialogs for example.

The physics API is an intelligently chosen 80% solution. It caters to the common uses of physics. If you’re in the weird 20% like Portal or Braid, you’ll probably spend more time fighting Unity than worthwhile.

That said, it’s superb for what it is and it’s been getting more flexible with every release. It’s a taste of the future of game development. Ideally, the only code required for a game should be gameplay-specific. Middleware has been getting steadily more and more comprehensive, and I can see the day when the only folks working on engine-level stuff work at Unity, Autodesk, Epic and Intel.