Write your game code so it can be re used, and your next game benefits from it. Ideally only the things that make your game unique will not carry over to the next game.??

Here’s the setup: I spent time fixing up a chunk of code for use in our asset pipeline. However, my lead coder had his own feelings about an addition I had made. What follows is my response.

 

It appears to me that there is a fundamental difference between how you and I approach coding. Please correct me if you feel this is wrong:
– you are concerned with making changes for the sake of this project.
– I am concerned with making changes for the sake of *all* projects.

This strong typed id is a perfect example. You do not feel it is a good fit for this project. Okay, I can certainly live with that. But not every game team will necessarily make that choice. And that is the core difference.

At the same time, I do not feel that we should have custom versions of scripts and sources that are specific to particular games. This leads to maintenance nightmares. It is better to have one reusable script that has options to allow each targe team to make those decisions for themselves. Then when bugs are identified and fixed by one team, Then all teams can share the knowledge without having to import it into their custom version. It just “works”. Not to mention that additional features can be created and shared to all with minimum of fuss.

There is a limit to how much options should be available before the script is fundamentally different from the original base one. But a properly designed script or bit of code will only be doing one task, and most of the time, there is rarely more than one good way to do that task. This very fact automatically limits how many options are needed in the first place. If the task is so different that it needs a lot of extra support options then it is probably doing a completely different job and is no longer sticking to one task, and should be decomposed into multiple sources instead.

One script = one task. ??Likewise, the thrift making script does one task, and is fairly compact. I do not believe it should be split into multiple files because it already adheres to this principle. To split it would make the code harder to read, not easier.

Just because it is capable of the strong typed Ids does not mean you have to use it that way. It still processes a non typed id in the same way it did. As proven by converting the existing data set. It is improved with some other cleanups that are related.??

 

I feel that few game coders consider these kinds of issues all at once. And I think we could be making much better games if we were to simply design the basic stuff reusable. Much more of our games is basic stuff than most want to admit.

Here’s an issue I’ve been wrestling with and cannot come up with a solid solution:
Should IDs be included inside structures, or is that metadata that should be encapsulated at a higher level?

Here is a more concrete example. We are tracking the state of a given Fighter in the game. This is a stateless server environment, so we need to transfer as little information as possible, but we must still describe everything. We assume there is a larger datastore on the server that has additional constant “definition” information for each Fighter.

Here is what the definition looks like for the external metadata version. Incidentally we are using Thrift, but the issue is the same in any environment.

// current state for fighter.
struct FighterState {
1: required i32 CurHealth;
2: required i32 MaxHealth;
}

struct FighterList {
// indexing
1: required map<FighterID,FighterState> fighters;

// connects a fighter to the definition datastore.
2: required map<FighterID, string> definitionIndex;
}

Immutable information is clearly separated from mutable. However, every method that needs to operate on a Fighter requires two parameters: The FighterList and the FighterID to identify which one is involved.

So this is what the information looks like if we encapsulate it all in one location.

// current state for fighter.
struct FighterState {
// indexing. this is immutable.
1: required FighterID FighterID;
2: required string DefinitionID;

// actual state
3: required i32 CurHealth;
4: required i32 MaxHealth;
}

This produces a mixed-mutability object. This feels less than ideal. Every time I transfer the state between client and server, I repeat the DefinitionID. However, if I want to pass a Fighter to a method, I can simply pass the FighterState and have enough information.

So let’s approach this in another way. What if we use compositing?

// current state for fighter. This is mutable.
struct FighterState {
1: required i32 CurHealth;
2: required i32 MaxHealth;
}

// immutable
struct FighterInfo {
1: required FighterID FighterID;
2: required string DefinitionID;
}

// combine them for runtime use
struct Fighter {
1: required FighterState State;
2: required FighterInfo Info;
}

We have now clearly separated the mutable from the immutable. We also can pass just the one Fighter to methods. But this feels very wordy. Also, the needs of the client and the server are slightly different. The server needs the complete “view” of the fighter definition, while the client can use a trimmed down “view”.

This can be simplified by merging the FighterInfo into the Fighter. Not quite as clean of a separation, but it maintains the mutability model.


// current state for fighter. This is mutable.
struct FighterState {
1: required i32 CurHealth;
2: required i32 MaxHealth;
}

// Network view of the fighter. It includes a mutable base, but the additional fields are immutable.
// This is minimal information for sending across the network.
struct FighterNetworkView {
1: required FighterID FighterID;
2: required string DefinitionID;
3: required FighterState State;
}

// the server is now able to add additional information – the complete definition for the fighter.
// This no longer must be handled in Thrift, it can be a subclass of FighterNetworkView, which simplifies accessing.
struct FighterServerView {
1: required FighterNetworkView Network;
2: required FighterDefinition Definition; // we no longer need to look this up externally
}

Now it is implied that only the base FighterState is mutable, while preserving just one parameter to methods. Additionally, this assists unit testing because there is no longer an external dependency to grab the Definition information at each use.

This still feels slightly wrong however because we are making a FighterServerView technically “mutable” because the base class is.

On the other hand, I’m used to SQL tables where IDs are regularly included with the data rather than external, necessary for lookups.

Opinions anyone?

I’m afraid to push a button.
 
User interface design is something I care about. I am a developer, which practically makes me a power user by default. And yet I still come across boneheaded design in commonly used applications. Design that would make computers less accessible to the general public. Worse, in places that didn’t previously have these issues.

Latest: Youtube on a desktop browser. Drag the playhead to sometime later in the timeline. If it’s not loaded yet – tough cookies! It will only work on the section that’s loaded. Worse – it changes the “scale” of the playhead to only show what’s loaded, but *only while you are holding the playhead.* Absolutely no semblance of user expectation.

Why is this suddenly too difficult for YouTube to manage? I know a year ago I could easily have just skipped right to where I wanted to be, and simply wait for the data to download starting at the new location. As a developer, I can imagine why this choice was made. Perhaps the data format is not well suited for seeking. Is a “please wait” indicator too much to ask? Then the playhead scale will stay consistent. The user will have an understanding of where things stand. Instead, somewhere inside Google, a bunch of extra code was written to support this “seek only within loaded area” code, with special cases for the display and input system. Someone had to deliberately break the user’s trust.

Okay, fine, I can’t move the playhead to the actual intended target. There is another button, with the tooltip “watch later.” Maybe that will download it in the background so I can close the page and return. Oops! Nope, that means??? well, I’m not exactly sure. Some menu shows up on the left side of the browser and there is no indication of how it relates to the action I’ve requested – “watch later.”

That’s not what I wanted it to do. But I’m afraid that if I push the button again to “undo” whatever I just did, maybe the page will reload and I’ll have to wait for the whole thing to reload all over again. At this point there is no trust between me and the application that it will do anything that I expect it to.

We must always keep a watchful eye on our designs, whether they be games, websites, or applications. Every “feature” needs to be examined through the lens of the intended audience for clarity, not confusion. This is an ongoing battle that has been fought for many years, and will be for many years to come.
 
Let’s not forget it!