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).

JumpShip

So:  JumpShip.  A crunchy space empire game inspired by Starfire, Aurora and perhaps a bit of MOO and its various descendants.

I've spent quite a bit of time over the last month or so laying the groundwork.  My Mercurial repository shows the first commit 5 weeks ago.  Pretty steady work until the great-food-sickness struck myself and my daughter (hereafter known as the Stainless Steel Brat) down for about three days each.  Not fun.

Anyway, I'm pretty pleased with the progress I've made.  Its still pretty rough, and missing a lot, but the basics are there.

Over the next serveral days I intend to do a series of posts detailing the hows and whys, of what I've done.  This will be for my own future reference, as well as (hopefully) useful material for anyone who might want to undertake the same sort of project.  Possibly just generally useful programming and design tips.

I think I'll proceed in something like the following order:

• Structure:  How I lay out a Unity project.
• Planets-A-Go-Go:  Star, planet and moon orbits in a thousand star systems without meltdown.
• Setup Data:  Or:  How DO we keep all our setup data out of the executable?

Well, I can think of a dozen other interesting things, but I'll start with those, I think.

So It Has Been A Long Time...

...since I posted anything here.

Quite a lot has gone on; moving, various work adventures, my daughter graduated from college and moved in, etc.

For quite a few months I stopped doing any work on my side projects (Retrograde, etc).    That said, I have done a few things, and have started back working on a new project.