I had received excellent advice in the form of a quote on a comment for my previous entry that essentially amounts to this: don't bite off more than you can chew. However, still high off my base-building-suitcase ordeal, and with a few school projects to wrap up before Thanksgiving Vacation, it's taken until now for that to run its course.

Though I'd be a victim of binary thinking to not believe there's infinite degrees in between, I'd like to say that there's two ways to design a game in BYOND:

1. Design your game to highly resemble the out-of-the-box MUD that the built-in BYOND procs and types support well.
2. Design something radically different and shoulder all the coding overhead involved in writing your own procs and types to support it.

Skilled and/or ambitious developers will opt for the second choice, and that's fine. Better than fine: it's easier to innovate outside the box. However, in terms of producing results quickly, it's easier to mold one's dream to fit the BYOND framework rather than the other way around.

I've this week off for Thanksgiving Vacation and I'd like to have something to show for it before the week is out. If that's going to happen, it's clear I've much boxing of dreams to do.

• My triple-layer (Universe/Planet/Personal) Mass Effect-like (really more inspired by Sentinel Worlds) game has been cut back to a single-level (Personal only) design. I'll worry about making three-games-in-one when I can first establish that I've made one game.
• Given the difficulty of shoehorning the skin grid controls to handle anything other than /obj objects, and a desire to use the skin grid controls, I'll be making heavy use of /obj lists. The current design intends to cut out the usual inventory-based middleman between skill and action, leaving mob.contents as a possible vessel for these skill-to-action /obj objects, just as the default BYOND framework intended.
• Given the client.eye and client.perspective options, coupled with a desire to preserve the built-in visibility mechanisms, I've decided to stick with a single player mob rather than a whole batch of mobs the player switches between. This is especially applicable by the time verb src settings get involved.

What I'm left with looks surprisingly easy to pull off. Over the next few days, I'll see just how right I am about that.