What I do when I’m programming.

Posted by | Posted in Game Development, Life, Lua, Pioneer | Posted on 02-02-2013

Today, as with the last 6 weekends in a fucking row I am ill, whoop, and being the weekend the doctors are off. It’s not an “emergency” so I can’t get seen until Monday, by which time I will be ok again and they won’t know what to do… fucking fabulous.

Instead of posting about that, or how you can’t buy a laptop with a decent resolution screen these days unless it’s made by Apple, I’ve decided to describe how I approach programming a feature in Pioneer. I happen to be working on a relatively bite size one at the moment so it’s fair game.

The “Feature”:

A post over on the Paragon forum highlighted something that I’ve been thinking about for some time. Scripting up the docking and departure sequences for Pioner has always been a stupendous ballache that is only going to get much worse as we add more bays you can dock with. It’s also a problem that we can’t group certain bays with a common entrance/exit.

So I’ve taken it upon myself to add just such a feature. Once it’s complete you’ll be able to place location/orientation markers in the stations modelling program, give them certain names + numbers, and it will automatically build you a path to follow when docking or departing a station.

The “Approach”:

First you have to identify two things, what you want and what you’ve got.

Part two is usually the easiest part, often you can see what something is doing, what it’s limitations are. I go through and identify the bits that do the loading and configuring, then where they get used. How the data itself is stored in this case didn’t really matter much but in others it can be a large part of the work.

Still this is easy because all of this code and data already exists, there’s often someone to ask about anything bizarre but even if there isn’t the debugger is your friend for figuring out where things come from and go to :)

Oddly then this leaves Part One aka; “Knowing what you want.” as the harder of the two. Sometimes it can be difficult to understand what someone else wants, not just what they say they want. I find this a lot at work especially.

What do you want?

 

At work there’s an existing workflow, lots of data spread across numerous files and a multi-million line of code application that it’s all wrapped in. There’s different teams, or departments, to complicate things since they all have different priorities and requirements from the same piece of functionality that I’ve been adding. What I do for one might be bat-shit insane for another, making their life more complicated and the chance that they’ll actually use what I’m working so hard on completely moot.

As an outsider to each departments development process that makes my life a twisted train wreck because I don’t understand the actual requirements for any of them and get only the information that is presented after it’s run through each persons mental filters. they will have pared it down to what buttons they want, what data displayed and what they can do with them. What I need is to work back from this bare faced “interface” description to the underlying reasons for it.

Returning to our space station docking system example (which is a lot simpler!) we can see that I’ve actually got a pretty good description from LionHeart about what he wants to be able to do. He’s given me a longer narrative description and then a breakdown of bullet points. From here I can see that we’re going to need things authored in Max/Maya/Modo (what is it with the M’s?), minimise the scripting, and above all keep it very simple. I’ve built entire games from less description than that… god how I wish I was joking… so that’s me happy.

Am I going to implement this feature exactly as described? No, of course not.

This isn’t because I dislike LionHearts ideas, or his suggestions, or anything about it. It’s because of what I said above, I’m outside the problem and I don’t understand the motivation behind it… slight exaggeration there as I’ve played with the docking stuff before and it’s hellish, but this is an article and it’s my narrative to play with :P

To get into the problem/solution I need to do a few things:

  • See how you go about placing waypoints in a modelling package.
  • How do you name them? Orient (rotate) them?
  • How do you get them out of the modelling package and into Pioneer?
  • Once out of the modeller how am I going to them into Pioneer?
  • How does the model loader load nodes?
  • Where should this data live once loaded?
  • How do I get the order of the nodes correct?
  • Should I do this in the Lua station definition or rely on naming?
  • etc

You’ll notice the etc there because as I work through a list like that each new bit of information might make subsequent ones redundant or add new things to investigate. A lot of this is time spent modelling in a modelling package, scribbling on pieces of paper, emailing back and forth, posting on forums and reading/debugging the existing code.

There’s one more very important one though:

  • Are waypoints the correct way to go?

I.e; does it even make sense to do it using any of the methods suggested?

What are you doing?

We can immediately say “yes” to some parts, authoring right there with the model inside the modelling package – great idea, exactly the way it should be done. Previous experience tells me that’s the right way to go and if it didn’t then 15 minutes spent trying to do it via the Lua scripts would solidify the concept for good.

The waypoints however? This isn’t clear cut. I can certainly do it, even without looking at any code it’s easy to see that I can read data out of a file exported from the modelling package, I know it will have position and orientation data in there, plus it’ll be named. That’s really all I need but that doesn’t answer the question is it the correct thing to do.

Even before asking on our mailing list  I’d considered using animations instead of waypoints. That way the artist gets even more control over what happens to the ship and can coordinate the animation of extraneous events such as doors opening and closing, or gantries moving into position etc. Win win win eh?

Animation comes with overhead and some restrictions too though. You’re fixed to the path chosen by the animator/artist meaning that if you wanted to detour off to a repair bay you need more animations or to break and blend from one to another at the correct time/position/etc. That’s more complicated to do, in fact it’s a never ending spiral of complication, it’s what I deal with most days in fact and I know that it will take a lot longer to get right. On top of that it adds some complications for the modeller, duplicating some waypoints is fairly simple: copy, paste, move some of them a little, done. You can repeat that workflow if your experienced with modelling but it is more for the artist to learn up front.

The path I’ve chosen:

In the end I’ve chosen to go with waypoints initially, named according to a standard convention for approaching a station, docking with it and leaving again. Bays will be grouped together according to ships size using Lua or in the modelling package.

This was chosen because:

  • Waypoints are pretty easy to setup, name and use (Simple to use).
  • The waypoint naming standard will have to be fixed because if makes importing possible using ONLY a modelling package (less Lua).
  • The system can be converted to use animations relatively trivially later on, but most of the groundwork will be common.
  • Whilst you can group things together in a modelling package some (3Ds Max) have fecking terrible DAE (Collada) support and break when using groups so the Lua support has to be there as a fallback.

There’s also the knowledge that this will be a version 1.0 of the system, nothing exists in isolation and everything get revised eventually as requirements change. This system will be flexible, minimal and simple, that usually means  it easier to change in the future. When it gets as far as the harsh glare of the Pioneer Pull Request system it should be powerful to use, simple to use and simple to understand. What’s more I’ll hopefully get someone to road test this, they’ll be at arms length so I cannot hand hold them through it and I’ll feed that back into the development.

All that text and all that mucking around in modelling packages and Lua should have convinced you all of one thing at least, when I’m programming… I’m not usually “programming” at all :)

Andy (aka FluffyFreak)

PS: this post has been brought to you by the power of being hilariously ill, again.

Write a comment

Time limit is exhausted. Please reload the CAPTCHA.