General Category > Game Development

How does Arcen code its games? (Architecture wise)

(1/5) > >>

Reactorcore:
Hi

I've been following how Arcen keeps updating AVWW at a rapid rate, sometimes incorporating big changes incredibly fast, got me wondering on what programming paradigm(s) is Arcen using to create its games?

By programming paradigms, I mean what kind of style of programming do you use to base the game's architecture upon? How do you organize it? Is it Component-based or Automata-based or something else?

I'm asking this because I'm currently trying to build a computer game too, but how to organize it all (menu system, game manager, save system, ingame actors and objects, gameplay logic, metagame) is something I have not yet understood on how to do it. I was hoping someone could help explain how they do it and what is their thought process while building the architecture of a full game?

keith.lamothe:
We don't use any formal method, really.  But there are certain patterns Chris and I have learned in previous jobs and evolved on Arcen's projects, etc.

Writing in C# helps dev-speed because it permits a fairly high level of static analysis and thus potential bugs (type-mismatch, etc) prevented before it's ever run.  Also, it's generally easy to find all references to a particular symbol due to the early-binding of variables (we don't use the more late-binding-oriented features of the language), which helps a lot in bug hunts.  And not using any explicit memory management (leaving it to the garbage collector) is incredibly important for cutting time spent on debugging (due to accessing memory that's not yours, double-deletes, etc).

Being a very small group (only 2 of us are coders) with a high average level of experience also helps dev-speed because we can get away with limited defensive programming and code-review because we can reasonably rely on programmer discipline to prevent things like desync-causing code (in AIW, mainly; though similar principles apply in AVWW).  That's not to say we don't make some pretty funny and devestating mistakes sometimes, but it's not like larger teams where whole positions have to be devoted to controlling the quality of code produced by other members.

Reactorcore:

--- Quote from: keith.lamothe on May 20, 2012, 02:09:20 PM ---We don't use any formal method, really.  But there are certain patterns Chris and I have learned in previous jobs and evolved on Arcen's projects, etc.

--- End quote ---

What patterns are they? I'm coincidentally currently reading about programming design patterns (Singleton, State, Factory and more), so it would be great to know what are relevant patterns one should learn for video game development.

Also C# ftw, I really like how that language is structured and how it guides the developer to type better code. I'll be using it with the Unity3D engine.

keith.lamothe:
We use singleton a lot, though that's not really anything special. 

One that may not be as obvious: we don't use inheritance for most objects that are part of the gamestate (we do use it for less performance-critical stuff), but rather for things like GameEntity or ForegroundObject (the "character/monster/tree/etc" class from AVWW and the "ship/building/etc" class from AIW, respectively) we have something like:

enum GameEntityType
- has one value for each distinct type of entity in the game, so "Darrell" is one of the npc/player-entity types, "SkelebotSniper" is the Skelebot Sniper, and "Cedar" is one of the cedar tree types.

class GameEntityTypeData
- has exactly one instance per GameEntityType value, and each instance has all the fields about that particular type of entity that never change during the game
- this has a static Initialize() method that is called when the application is first run, that calls the ctor once per GameEntityType value and stores them in a "static GameEntityTypeData[] Lookup", which can be retrieved from like "GameEntityTypeData.Lookup[(int)GameEntityType.SkelebotSniper]".

class GameEntity
- corresponds to an actual in-game entity, so if there are 4 skelebot sniper on your screen there are actually (bopping around in RAM somewhere) 4 instances of GameEntity whose this.TypeData.Type value is GameEntityType.SkelebotSniper


We use the Type/TypeData/Instance pattern all over the place.  Sometimes we just do Type/TypeData for, say, PurchaseType/PurchaseTypeData; each PurchaseType enum corresponds to a specific transaction that is possible in the opal guardian store.  But there's no "Purchase" Instance class because we had no need to have an object representing the transaction: the TypeData provides all the necessary information to handle it from start to finish, and the resulting change in your inventory is all that needs to happen, no additional intermediate or residual state.

Moonshine Fox:
Spontaneously though, concerning memory management, would writing the game in say C++ give you greater control over memory management and make the code more efficient and stable (provided you don't code any bugs :P) compared to C#, or is the garbage collector in C# so awesome it makes manual memory management superflous?

Navigation

[0] Message Index

[#] Next page