Changing Minds

Yes, its true. I've read this book. Picked up in the airport to pass time on the plane. Ostensibly about ways to change someone's mind about something, it actually reads more as a series of anecdotes about the way various people ( mostly "VIPs" ) have changed their own minds about things.

In a way its almost reads as a a pop-sci book for business managers. ( I can't quite put my finger on why I feel that way, perhaps just based on the particular stories he relates. )

Overall probably the most interesting thing in the whole book is his theory of multiple intelligences - the idea that there isn't just one number that (re: the bell curve) that you can rank people's intelligence against. Then again I suspect (hope?) that's a commonly held -- though perhaps not often articulated -- sentiment.

He's a good writer with apparently lots of published work so I wouldn't be surprised to find out that he has some really engaging books out there. This one was just fine, but not, on the whole, super-exciting, nor incredibly thought provoking.
See full post...

Strings

Strings cause both memory and performance problems in games. While perhaps not the most pressing issue in game development, it would be useful to have a guide to common string issues. Such a guide would contain:

• Categorization and analysis of the typical uses of strings in games
• Comparison of different kinds of string packages available in C/++
• Tips and tricks for optimizing string usage, including a comparison of various string hashing algorithms

Over time I hope to add bits and pieces of this to the site. Contributions welcome.
See full post...

String Categories

Some major categories of string usage.

Currently in no particular order:  

Display Strings

unicode, or other swappable, multi-language friendly strings that appear on screen. alternatives: none known, but how these strings are stored and referenced can be key to making a game easy to translate.  

Format Strings

string that describes how data, including other strings, will appear on screen. alternatives: hard coded string / data composition

Player Input

strings defined by the person playing the game, typically winds up being a display string at some later point. examples: run-time configuration (consoles), names of user characters, names of servers, passwords, chat, etc. characteristics: changes infrequently, often kept for long durations, sometimes saved as part of user data. may or may not be unicode.

Object Names

designer or artist defined names, used for labeling, searching, identity tests examples: names for placed objects, npcs, special weapons, etc. characteristics: typically changes only during edit cycles, often offline. may be used for NameConventionMashing alternatives: guid, but often some nice/pretty name that designers can remember needs to enhance the guide

Named Variables

a variation on object names, artist or designer defined names used for labeling properties or variables in scripting. characteristics: while potentially convertible to non-string based representations often the string name is kept for debugging or logging.  

Type Selection

predefined names, usually exposed by a programmer, used for type-type comparison. examples: inventory item class types, internal dialog or window class names, user commands. alternatives: unique ids, enums, type classes

Logging

debug strings for use during development. examples: timing, trace outs, etc.

Errors

often not differentiated from logging strings even though some percentage may become display strings. examples: asserts or other hard coded error detection alternatives: centralized error codes ( enums or #defines )

File Names and Paths

location or names of files on disk. may be used as part of app configuration, NameConventionMashing, or search.

• configuration example:
• D:\games\gamename\data
• C:\gamename\data
• naming convention mashing:
• ui\theme\evil\window.png
• ui\theme\good\window.png
• load time search:
• data\weapon\biggun\*.wav

Data File Parsing

some data files ( xml, ini, yaml, etc. ) are based on text. parsing needs may include:

• parsing of value:
• "true", "false", "atoi", "atof", etc.
• mapping data to data:
• esp. searching for pieces of assets, ex: mesh names, material names, locater names, etc.
• name based selection:
• finding type, object, or variable names.

See full post...

R-Object

Intent

Provide a clean, robust, mechanism for controlling the relationship between two objects.

Motivation

Connection style relationships between pairs of objects are common in games: A player flying a plane, an enemy npc equipping a weapon, or even particles generating from a smoke stack, and so on. By introducing a "relationship object" that exists for the lifetime of the relationship you can provide any methods needed for control over the relationship all in one easy to find place. The relationship object in the first example above might expose an interface for controlling the plane's physical inputs: ailerons, etc. in a simplified manner: perhaps, for instance, just a: SetDesiredRoll()

Benefits

Helps to reduce complexity of object code by keeping relationship management out of the main object hierarchies. Specifically it provides:

• Clear separation between each object's encapsulated interface and the interface that *only* exists when the two objects are connected to each other;
• Clear separation between different kinds of relationships between the same objects;
• Clear separation between different kinds of relationships for different kinds of objects.

This pattern becomes particularly useful in multiplayer games. The creation and destruction messages for the object provide clear communication to all players about the existence and nature of the relationship. Member methods provide good event style notifications; member variables provide well isolated data replication blocks.

Related Work

• Facade: Overlaps this pattern somewhat in that they both can provide a simplified interface -- facade implies a permanent, architectural, relationship; whereas the R-Object provides an explicitly temporary interface that changes based on the particular objects involved.
• Adapter: Mechanism that takes user input ( via a game controller, mouse, keyboard, etc. ) and maps it onto the capabilities of the relationship object's interface.
• State: Lifts control over the relationship into classes based on behavior; helps sustain the relationship object by keeping the control over the relationship object itself out of the two classes involved in the relationship to a third-party.

Liabilities

You pay a tax in the form of additional classes and more distributed ownership of responsibility. Its also worth noting that the relationship object itself requires its own memory allocations. The additional class complexity ( again: in exchanged for reduced interface complexity ) may not be necessary in some cases, especially where:

• the control mechanism remains invariant through the course of the development cycle
• the r-object only handles concrete or "leaf" classes of the objects involved in the relationship
• one of the objects in the relationship only exists as long as the relationship exists
• the interface for the relationship is small and easily understood.

For instance: the particle effect relation described above can work with this pattern, but the additional class may not be worth the work. Particle effects are typically either attached to something or not ( so: their relation is fairly invariant during development ). Additionally the relationship control between the two objects is generally fairly simple: perhaps just its creation ( attach ) and its destruction ( detach ). In this case its probably clearest to simply put attach / detach ( and update ) control directly into the particle effect itself.

Alternatives

In most cases, since games tend to deal in exceedingly concrete terms, its possible to think of one primary object as controlling the other, secondary, object. The primary objects in the above examples would be: the player, the npc, and the smoke stack; the secondary objects: the plane, the weapon, the smoke. In my own experience I've seen both primary and secondary objects take over the interface for the relationship. Generally speaking, if there's any amount of polymorphism in the secondary object class, then the relationship will reside there. If, the secondary object class tends to be of uniform type, with little if any derived behavior, then the relationship may live in the primary object. Weapons, for instance, might have a lot of behavior differences, but still can posses a relatively standard set of inputs (ex. begin/end firing ) and so may get control over the relationship built into their class. Player characters, however, may have several different appearances, but not a wide variety of control mechanisms, and so the control over the player character itself may be built directly into the primary: player or actor class. Reuse pressures may also help decide where the code for a particular relationship gets placed. For instance: if npcs and player are able to use the same weapon interfaces, then the code for the relationship may live primarily in the weapon; if not the code for managing the player-weapon control may move into the player class, and npc-weapon control in to a separate npc class.

Known Uses

I implemented a variant of this relationship for a prototype game to good success but haven't ever used it in a production environment. Looking through games with open (mod) source: Half Life, Unreal, Quake ( though quake isnt quite applicable as its written in C ), and yes even MechCommander2, I see secondary-object oriented implementations in almost all cases. I think the primary motivation for that architecture remains: if its relatively trivial to create class types, its straight forward enough to simply bake control and behavior ( and even networking manipulations ) straight into the secondary object. Wherever differentiation between player and npc object behaviors are needed its relatively easy to simply create player ( and npc specific ) weapons. The main expense ultimately being large interfaces on both actors and weapon classes to handle variations in control mechanisms. The closest implementation I've found is perhaps the controller classes in UT, which does pull out control over character ( and vehicle? ) into a third party class. It seems primarily specialized to handle different kinds of NPC control over different kinds of actors ( vehicles, turrets, etc. ), though there is also a PlayerController.uc. The differences between their controller class and this pattern is two fold: 1) theirs handles every type of control mechanism in a single class rather than splitting different control types into different classes; 2) theirs also does the job of translating input into action, whereas that would be the role of a separate adapter class with this pattern.
See full post...

New Look

I've always been curious about web-development software but I've never actually gotten my hands dirty with anything other than HTML or Flash before.

It's, of course, impossible to have been in software development and not have picked up bits here and there, but I've never actually tried to doing anything even moderately interesting web-wise with PHP nor even CSS.

This weekend I spent a bunch of time learning about them ( plus mySQL and the Wordpress API ). I've always been impressed by how relatively simple the web-browser is but then how much infrastructure goes into making web sites. I'm even more so now actually having played with it a bit. Its quite simply a whole other world apart from game development.

More than the language of PHP and CSS I'm curious what people's work flow is like. Just like knowing C/++ doesn't automatically mean you would know how to write Windows apps well, "knowing" some of PHP and CSS now, I'm curious how people apply that knowledge day by day to efficiently get work done.

Some examples:

• Do people generally setup development locally and then upload when they are done?
• Do they work remotely, terminal style?
• Are most people developing with XWindows or the like to mitigate the terminal pain?
• Are there auto-complete style editors for PHP? How about embedded Help?
• How are bugs tracked down in PHP? [ My technique was to simply edit ( in some cases locally, in some cases remotely, in some cases via chris pederick's awesome firefox extensions ) and see what broke / worked but that makes you miss the compiler error-checking step. ]
• How in the world do people view the cascade of styles that formats any particular line? Or worse -- any particular blank space on a page? ( it took me 2 hours to get rid of 100 pixels... grrr.. ) How are those styles "traced back" to the lines of source that created them?
• How do you view web-sites, or pieces of them, "flat" ( many pages in one view ) so you can see how changing styles and scripts affect the layout across the whole site?

Note: its been about 10 years since ive actually had to do anything productive with a unix server but I'm happy to say I still remember my way around ok-ish. I wish i remembered my emacs keys though. I think I'm way too bonded to Source Insight for my own good. I'm sitting here using pico and was just about ready to put my eyes out.

I did try out PHP in Eclipse but i have to say -- eclipse keeps giving me strange errors. I love the RCP concept but eclipse *is* rather unfriendly to get setup. It hasn't for me run right out of the box. I wanted to try out PHP in NetBeans as well but it didn't seem to recognize the language -- maybe I was missing a plugin?? I will say, although Source Insight's parsing of PHP, especially HTML embedded PHP, sucks horribly it was still better than Eclipse -- at least I could look up / jump to functions without having to get my PHP interpreter properly configured.

That's it for now.
See full post...