Objective-C Reference for OpenGW, the game world simulation engine.

OpenGW is used to implement game rules and data in a modular, engine-agnostic way. This makes it easy to port existing game code to other game/rendering engines and platforms by only having to adapt view-specific code.

The architecture of OpenGW is designed with maintenance and ease of use in mind. OpenGW supports any kind of game. But most importantly OpenGW supports you by enabling you to write better game code, faster.

Visit the OpenGW website for more info.

General Advice

Your Memory shall be __weak

You should always declare references to OGW objects as weak (__weak for ivars, weak for property), be it on the view side or within OpenGW code. Always start out by making the reference to an OpenGW class weak, and only ever change that when it isn’t sufficient and fully understood why a strong reference is needed.

Rationale: Entities, categories, aspects, values, tasks, etc are always retained in containers when used properly for as long as needed, and should be free to deallocate when no longer in use. Thus there’s usually no reason to keep strong references to any of these objects. This is particularly true for cases where you only need a reference to the object in order to speed up access (caching).

Not following this best practice may cause retain cycles and memory leaks. Following this best practice makes memory management within OpenGW a breeze, and worry-free.

Exceptions: the view needs to keep a strong reference to the OGWWorld object for it to remain in memory. And any Jobs you may want to be able to re-run at a later time (within an aspect class) may also require a strong reference.

OpenGW shall have no knowledge of the view

In your OpenGW classes, never make any reference to a view-based class. Instead, use delegation. See the command/delegate pattern implemented by OGWPlatformerCommandsAspect.

This ensures your code remains independent from the view/renderer.

The view shall exert no direct control over OpenGW

In your view classes, never make any reference to or use of any classes other than the world or a view’s entity. Always ask yourself: is this something I could do entirely on the OpenGW side? If the answer is yes, do it on the OpenGW side even if that may add another indirection (ie “do something” message + “did something” delegate return message).

This ensures the coherence of the game world and will aid in debugging issues.

Through the command pattern (ie entity “should” do something) a command aspect controlling the entity can implement any safety checks before issuing the actual command. For example it could first verify that the entity is still alive and in a mode where it can do that thing. The command aspect could (only when needed) send a delegate message telling the view that the requested command could not be executed. Likewise the command pattern can expose the “check” functions for specific commands so the user interface can test if a certain command can be executed, which then enables and disables buttons accordingly. See the command/delegate pattern implemented by OGWPlatformerCommandsAspect.