Mar 052016
 

SDKI like Software Development Kits (SDK), they have saved me so much time and effort over the years. An average AAA game can contain quite a few while those written in Unity easily have more by a factor of ten thanks to the Unity Store.

I thought it would be an excellent idea to list a few of the issues I have encountered, hopefully this will help raise awareness of the problems you can cause if your thinking of building a new SDK, library or package that you want others to integrate into their game.

Directories and Files

Use relative paths, and never assume your files will be located at a specific location. If your SDK is isolated correctly and uses relative paths it means I can place the library anywhere in the project structure with minimal wiring.

There is no guarantee that everyone on the project is working out of the same directory structure,  tools such as CMake create visual studio solutions that use hard coded paths which makes placing your SDK under source control that much more difficult.

Avoid using common filenames; platform.h, types.h, list.h, object.h can cause conflicts with other files especially when all these SDK’s are brought together. It helps a lot if you were to use a naming convention similar to myawesomelibrary_types.h.

Classes and Naming

Everything that is part of your system should be encapsulated by a namespace and that namespace should be specific to your SDK. Like the file naming make sure your name space is unique to your SDK and doesn’t use common words such as; memory,  manager, controller, interface, etc.

On one hand this next point isn’t a big deal, but that is only the case because we have lived with it for so long in development…

In almost every SDK there is a class buried somewhere in it simply called object, when having discussions you have to prefix every reference to “Object” with what type of object you are talking about; Physics Object, Game Object, Sound Object, Sound Emitting Object, Network Object, Cloud Object, In-game actual object, System Object, Projectile Object, Generic Object, FX Object, etc. It’s exhausting.

Other words have caused similar issues such as Zone, Area, Level, Thing, Blob, the list goes on but you can see my point, in the games industry we have a problem, we use the same word to mean different things.

In short you can really help the people using your SDK by coming up with something not so generic and conflicting with other development terms.

Updates

This should be part of your business! If you do not plan to or can not maintain the SDK you shouldn’t be releasing it.

One of the first things I look for when I evaluate an SDK is; Does the SDK have regular updates? If it has not had any point release updates then that would mean the developer is not giving it the attention it needs, nothing is ever 100% bug free. It also tells me that the developer is not really interested in the SDK and is very unlikely to fix bugs if and when I come across them.

I would say this issue is more of a point towards Unity developers and others linked to a specific engine, when the engine is updated your SDK should also be updated to make sure it is at the least warning and error free.

Communication

I am using your SDK which means I will find bugs and I will make improvement suggestions, I am trying to help you make a better product so have a way for me to communicate that information to you. Email or web interface is great, but communication back is also appreciated, even if it’s a web page of current issues, it helps me a lot and can effect how I schedule my time and resources.

And lastly

There are a few SDK’s that it has been an absolute pleasure to integrate into my games, these are the one’s that slide into a project without any hassle and generally work first time. When those developers release something new you can bet I am one of the first that take a look at what they have to offer (PS give me a way to sign up for news on what you are doing).

 

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)