Hardpoints and Workflow

One of the interesting questions dealing with a full featured editor like Blender is how much really makes sense to do.  There’s a full game engine there, and so it’s possible to create an entire game within it.  But of course, given all I’m talking about is Unity then I don’t really want to make the full game in blender.

This came to mind recently because I was thinking about hard-points to place on the ships.  The idea is similar to that handled in Galactic Civilization 2.  Each component you add can be joined against a hard-point in the existing set.  You start with a chassis which has a certain number and then you add a wing

Galactive Civilizations 2:  Constructing space vehicles from hard points.

Constructing space vehicles from hard points.

which has it’s own hard-points.  The wing attaches to one, but contains many more itself.  This allows you to build very customizable ships, and I plan to use this concept to allow the players to build their ship for space combat.  Such a feature provides a number of great game benefits, like finding (in-game) particular or rare pieces (especially those that give certain abilities when attached to the ship) and allowing them to be specifically targeted, damaged and destroyed during combat.  But the basic point is that it allows individuality and customization.

So the question was:  Who is responsible for the hard-points?  Is it the artist who places them when he designs the chassis in order to place them in the most aesthetically pleasing way?  Or is it the game designer who needs to set them up based on number of properties necessary for game balance?  Most likely for game balance the designer would only need to specify the number of hard points to allow, but it’s also possible for perhaps physical reasons, and in my case that certain specialized hard points would be needed on top and bottom since they’d rarely be seen in this pseudo 2d game.

In some way’s the answer is both, but that’s not an answer easily addressable in Blender.  The easiest way I could imagine to do this would be to have the artist generate empties (which are objects that contain only one vertex).   The game designer could also modify these directly in the blend file, which would allow, for instance, the artist to place initial hard points where he likes them and the designer could delete or move them to fit some balance notion.

However, model files as they are treated in Unity are read only.  And when considering the work-flow of a designer doing a rapid test cycle within Unity, pulling up blender to modify the location of those hard points seems like more effort than necessary.  So the next direction to take is to use an element in Unity itself.

The good news is that Unity already has a visual editing capabilities similar to those in Blender which an artist would be familiar with using.  One of the things I’ve learned over the years of programming is that the shorter the test cycle is between making a change and trying out the effects of that change means the better you can work.  In Unity it is actually possible to modify within the editor while the game is running.   When I first started testing the physics restoration on the ships, I ran the editor and pulled them out of alignment using the model editing tools while the physics was running.  The physics  would then work to fix the alignment back to the 2d plane.  This was an amazingly tight loop to fudge numbers which are not based on any physical reality in the first place.

So there is one final decision which I haven’t nailed down a direction to take.  On the one hand, I might use Unity’s empties to attach to the object and position for hard points.  These would be children in the prefab, and I’d use the script to find them when it came time to attach parts.  However, the other option would be to store them as variables in scripts.  It turns out using the GUI extension scripting in Unity you can setup widgets to modify even variables graphically.  The easiest way to handle this is to add each variable to the script for each hard point.  The script would then be attached to the object and each of the hard points would have the small edit widgets to allow the artist to change them.  If the designer really does only need to worry about the number of hard points he can decide this by attaching the appropriate script and let the artist set the actual position for each.

In the next post on this topic, I’ll address the decisions made on which methods to take for implementing hard points and post links to the prototype in-game editor.

  1. No comments yet.
(will not be published)