Design for the Future; Parent/Child Transforms (Non-Game)

PART THE FIRST: DESIGN FOR THE FUTURE

Design in this case, refers to code planning/architecture, not visual or interface design…  I have a few game ideas that I have not posted about here yet.  However, as I was thinking about them today it occurred to me that I should start working with my planning of Killing Horizon with the future program(s) in mind.  I won’t worry too much about it, but it will be something I keep in mind.

How I try to abstract something now while working on refactoring/re-architecting Killing Horizon should at least be partially predicated on those projects I want to see come to fruition next.  So, I guess I’ll make my own framework to help me get some basics working.

I also have a bit of a vague theory based upon physics I call STEM (Space, Time, Energy, Matter).  No, I didn’t take it from L Ron Hubbard 😛  Everything in the design can be seen in some manner as relations of objects in “space” (however that may be defined) and in time…  So abstract out some of these fundamental concepts and figure out some of the basic actions that can be performed (adding, subtracting “health” (energy))…

Some of these things are already taken care of by Unity (position in space is a Matter-Space relationship, movement is Energy added to matter moving it through Time (yes, we’re ignoring relativistic effects, sorry Einstein!)).  But things like “attack” and “damage” are common constructs that I should plan in this thing.  Production rates, spawn rates, waves/frequency.  Storage of energy (laser beams) — that can be seen as a sort of economic system: A conversion of one type of object into another (for instance, my asteroids are converted into black hole “mass”/size when they collide with it)…  Or they convert into “energy”(damage) when it hits the ship, and smaller matter (smaller asteroid chunks).  The damage (kinetic energy) is then subtracted from the ships health (a form of energy)).  Some powerups can be seen as converting matter into energy (bomb explosion) or vice versa, or transforming one form of energy into another (absorption shields to regenerate health), or one form of matter to another (helmet upgraded with an alloy layer added to it)…

Furthermore, really interesting design comes when you start dealing with the transformations of these properties not just energy<->matter, but adding in time and space into the mix.  Energy can be added to speed up movement through space (thus reducing time).  Energy can be saved in a bank and spent later.  The delay of spent energy, the storing up of this energy can be seen as a time transform on energy.  You delay the expenditure of energy in the short term to have the energy grow (through time) into a larger amount.  It’s very abstract, but it’s when you get to those issues and start thinking of the relationships between these things that you might find some unique ways to come up with interactions with objects in your world beyond just “shoot, bang, die!”  Even if it IS just shoot bang die, you can still use these abstractions to help you formulate a way to remove a level of detail from your systems and make them more generic/universal.

In the end, a lot of game design comes down to economic transactions between values of various related systems.  Balance is fine-tuning that economy to make sure there is no one dominant “player” or factor in these systems.  If anything is too dominant, the game is over before it’s begun, or players lose out on flow.  That sad, sometimes players like really difficult games, so you might ramp those factors up.  But ideally, a game has some semblance of  homeostasis between these systems to keep things balanced and organically flowing.  You could say that game design is ultimately a process of Cybernetic-Economic Design of Systems for Entertainment.

PART THE SECOND: CLOCKS AND TRANSFORMS

Philosopher’s throne strikes again.  While sitting upon the mighty porcelain “chair” ruminating on the issue of my clock (see previous entry regarding the clock app idea I have), which had a skewing of the seconds hand while it rotated, I came upon a potential solution, and after trying it, I found it worked like a charm!  The rest of the code for this little app should be easy as heck.

So, the clock is going to have the seconds hand attached to the “pointing” end of the minute hand (instead of, like most clocks, attached to the center of the clock).  I should also point out that the hand is not a traditional hand.  In fact, let me just give the mockup I made.  The grey circle both the tip of the minute hand and the second hand.  The triangular pointer is actually the second hand.  As the seconds pass, the grey circle rotates clockwise (no pun intended), until it hits the next minute, and the circle itself now moves one more degree clockwise…  The large white circle is obviously the hour hand.

I did not have these textures applied to the cube objects that were rotating (acting as hands) — just a basic cube image.  But the cube geometry was distorting, and so obviously if I had a texture applied to the cube, it would have been warped.  And not in a fun cute way, but vastly distorted and straight up wrong.

So, how did I resolve this?  Simple.  I added a child transform of the minute hand that was NOT the second hand itself.  This way I could have the second hand attach to that object, and since it would not be stretched as the minute hand is (the minute hand, being a long, thin (and invisible to the user) pointer thing, is what caused the distortion in the first place, somehow that rotation of the parent adds to the rotation of the child and distorts it.)  From what I was reading somehow this does not pass on to grandchildren, so if I figured I would manually set the position of the second hand (instead of the simple drag/drop that Unity provides, I’d have to do it in code).

Interestingly, I didn’t even have to do that. I just dragged the seconds object directly onto the “attachment node” that sits between the parent(minute) hand, and itself, and it automatically worked!  No need to deal with code, no need to make extra computations.

This was a very pleasant surprise.  I was worried that I’d have to write code, and of course, if you have to write more code, there’s always more room for mistakes and debugging, yada yada.  Nope!

The next phase of this project will be to determine fonts, colors, and a few other issues (how to deal with minutes… do I just let the transparent circles pass over?  Do I make the minute circle literally display the minutes as it moves (that is, instead of being transparent and showing the numbers underneath, just show the actual minute value, while the circle hand rotates around).  I think that’s probably too much work and unnecessary, but from a user perspective, I think it’s fair to ask what makes the most sense.

Clock Mockup1

Leave a Reply

Your email address will not be published. Required fields are marked *