VR

Well, it's been a while since I've posted anything.  The primary reason?

My Vive finally arrived.  It is quite amazing.  I have to say that it definitely lived up to the hype.  Also I'm glad that I spent the extra on the Vive rather than a Rift.  I think the 'room scale', and especially the hand controllers add a lot to the experience.

Besides playing lots of VR games and whatnot, I've been experimenting with SteamVR in Unity.  There are a lot of difficulties around locomotion and motion sickness, though you can pretty well mitigated them, it seems.

I'm fiddling with a bit of a branch of Jumpship, more oriented to piloting a single ship ala World of Warships.

Avoiding Code Coupling: Messaging Systems

A pretty common feature of, well most any game, is clicking on some object to select it or get information about it. Or mousing over it for a tooltip, etc. In whichever case there needs to be some connection between the visual game object displayed, and the behavior and data behind it.

Unity Project Organization: MasterControl and SceneControl

As I said in the previous post the way I design my scenes revolves around the MasterControl and SceneControl classes.

The MasterControl is the omnipresent 'god object'; it will persist through every scene in the game.

A SceneControl object is the controller for a single scene.  This is where you'll find the logic for setup/teardown of the scene, as well as data that needs to be centralized or persisted during the scene.

World of Warships

I've gotten pulled into playing World of Warships with some friends.  Pretty enjoyable, and I've always had an interest in naval history.  As a kid I always had those big picture books 'Battleships of WWII' and the like around, so it is right up my alley.

I'm considering recording some games and throwing them up on YouTube.  I have a channel where I've occasionally put demo videos for projects I've worked on.

Or, I could just play and not bother doing any actual work.  Hm.

Unity Project Layout, Part Three: Logical

Apart from having discreet scenes, Unity pretty much has no 'opinion' on the logical organization of your program.

There isn't a lot written on this that I can find (ok, online, maybe there are print books).  Most of the advice is general, but sound: Separating interface from game logic (I'd go further and say you should separate game-state from game logic as well).  Name things clearly.  Etc.

There's a lot on folder structure, but not on game structure.  I'm not necessarily talking about the gameplay code (platformer vs real-time-strategy vs RPG, etc).  What I'm going to ruminate about is the structure around that; handling startup, state,  game data, save data, etc.

And, as always, everyone has there own way that (probably) works for them.  This is simply how the manner I've deal with these issues has evolved.

Unity Project Layout Part Two: Physical

Unity, when starting a project, creates a bunch of folders in the root project directory.  The only one we typically concern ourselves with is the Assets folder.  That's the folder where all of our, err, assets go.  Scripts, models, textures and so forth.

So really when we are talking about how a Unity project is laid out on disk (which seems an odd archaic reference, since I'm using an SSD these days), we're talking about the Assets folder.

Unity Project Organization Part One: N+1 Different Answers

I believe there are two topics at the root of a discussion of Unity project structures.  These are:  file organization and game (code) organisation.

Note that this is all simply my opinion, mostly based on a slow evolution through several projects.  That, and many years of general software development practice.

You'll find as many opinions on this are there are people offering them (someone posted on the Unity forums that "If n people reply to this thread, you're going to get at least n+1 different answers. ;-)").  As an aside, here is a decent article that has some opinions on the subject:  50 Tips for Working with Unity (Best Practices).