Fundamental Pieces of an ORM2 Model

Since this game is going to be based on the graphical notation of Object Role Modeling v.2 (ORM2), one of the first steps is to build the model so that the game mechanics can interact with it. It's a bit like creating a sports announcer who knows the rules of the game and can narrate events as they happen.

In ORM2, there are three main components to the model:

1. Object Types
2. Fact Types
3. Constraints.

First, Object Types. OTs can be thought of as, well, types of objects. "Bird" or "Car" are types of objects. "Thanksgiving dinner" or "My Jeep" are instances of those object types.

Fact Types (FTs) are how OTs relate with each other and with themselves. They describe relationships, and are composed of roles and readings. A FT with one role is called a unary fact type. An example of this would be "Bird is alive". Obviously we'd prefer that our Thanksgiving dinner bird does not meet this criterion. FTs also come in binary (2 roles), ternary (3 roles), quaternary, quinary, and so forth. Anything over three roles is usually called "n-ary" because let's face it, nobody remembers their Latin prefixes these days.

Given the OTs "Car" and "Person", we can choose to relate them to each other in many ways. The relationship is written out with the name of the OT serving as a placeholder in the reading. "Person drives Car" and "Person was hit by Car" are two sample FTs. Now, replace an Object Type with an object instance. "Tyler drives JeepABC" is true-- I do drive a Jeep! Its license plate isn't ABC, but you'll just have to use your imagination. "Tyler was hit by MinivanOfDoom" is also a true fact. Not sure what ever became of that car....

Finally, we come to constraints. They're what keep two people from driving the same car at once, or a person being their own grandparent. The subtleties of information modeling are often in the constraints. There are many kinds, but for the purposes of prototyping my game I'm only dealing with uniqueness constraints.

A uniqueness constraint covers one or more roles in a FT and ensures that AT MOST ONE combination of objects in those roles ever happens. In "Person drives Car", a uniqueness constraint over Person would mean that "For each Person, that Person drives AT MOST ONE Car." Put the constraint over Car instead, and it turns into, "For each Car, AT MOST ONE Person drives that Car." Don't worry too much about the bold and italics and capital letters; that's just me showing off that I can dissect constraint verbalizations and you can't. Yet.

In a future post I'll toss in some pictures to demonstrate the graphical notation.

Frameworks

Part of the joy of programming is learning about how different types of things are made. Game programming is VERY different from "classic" web programming. Depending on the project, a developer could be coding business workflow engines, database infrastructure, image manipulation systems, or even making a new language that other people will use to make their programs.

Each of these fields has its own tips, tricks, techniques, and pitfalls traps! And while it's fun to learn them all from the ground-up, it's also nice to be productive every once in a while. So in the interest of spending my time working on the actual game instead of re-inventing the wheel and writing my own game infrastructure, I need to choose a framework.

In my list of game development links I've come across a few different frameworks, and there are a few considerations to take in:

1. Compatibility with mobile platforms.
2. Does it manipulate HTML directly, or does it render inside a canvas element?
3. Are all the images bitmaps, or can vector objects be used?

Many things to think about and try out.

Time to make a game!

For the past year or so I've had an idea for a video game that would teach the basic "vocabulary" of data modeling in a fun, interesting way. As I start to develop in earnest, I'm going to update this blog with conceptual and coding examples.

Nothing much to post tonight, other than the announcement.