Replacement foundation almost finished

So, middle of last week I finally bit the bullet and gutted out a lot of the prototype code in order to start rebuilding it smarter, something I’d been planning to do but putting off since before Thanksgiving. Got detoured into spiraling complexity for a couple of days with the redesign, but back on track now. Gone is the original hackey SelectionManager, replaced by a TouchInputManager, designed from the ground up to work properly with multitouch. The old line drawing code was a complete encapsulation failure, with bits and bobs spread across multiple files that it shouldn’t have really been touching, creating painful inter-dependencies that I was having to work around; new version cleanly wraps things up in a self-contained way, while providing the means to extend the behavior with custom events defined in project-specific scripts. And the re-engineered prefabs for cars and characters are structured much smarter, keeping their various components from having some of the problematic interactions they had in the original, and making the code for entering and exiting vehicles tremendously cleaner and simpler than it was before.

While caught up in the complexity spiral, I committed a cardinal sin and spent a day optimizing some code I hadn’t even bothered to profile; finally profiled it earlier today, and at first the results looked bleak, it was not even showing a 10% boost in performance compared to SendMessage, and I was feeling pretty stupid for wasting a whole day on it. Then I realized – I was profiling only one specific situation, when the message is sent and received. So I set up some test cases for the  case of sending a message which nobody is listening for – which is much more common, given the volume of messages sent by the new input manager – and in that case it was blowing SendMessage away!

With the new touch input scripts, I think I could throw together a basic clone of Flight Control in a day or two; only feature I would have to add is the detection and verification of landing vectors relative to the runway, but it would be pretty easy to implement using the events the existing line path classes do provide.

Entirely new feature, implemented a system to automatically path around small obstacles, using dynamically-generated circular, elliptical, or rectangular border paths, which can be rotated with their objects. It’s overkill, from the last phase of my complexity spiral, but ultimately it produces exactly the behavior I was needed (and more), and is cleanly integrated as an extension of the touch input and line drawing scripts, so I’ve kept it in and slashed all the other systems it was originally built on top of. This bit resolves what was the biggest frustration point in the early prototype builds, so I’m highly optimistic that once the rest of the code is integrated with the new input foundation, it’s gonna be a lot more fun and a lot less frustrating.

Still quite a few things to implement, but everything input-related is going to be easier than it would’ve been using the old system, and the new code seems to be a lot more solid, so won’t have to keep duct taping everything to prevent it collapsing as I add features like I was before.

On the asset front, have the first sets of assets coming in from my artist now, and they look great! I’d started to feel like my programmer art was pretty good after staring at it for so long, but any delusions about that were shattered once I had some proper graphics coming in to compare them to. Will have all the graphics I need for the playable demo by as soon as the end of this week, though there’ll be a lot more graphics to get done after that.

So things are moving along pretty well, I have to say!

Did you like this? Share it:
Posted in Geomys Games, Programming | Leave a comment

Geomys Unity Tutorials

With all the time I’ve spent helping people on unityAnswers in the last month, I decided I should polish some of these up, add explanations and descriptions, and share them here. The first I’m going to share is a bit arcane: Polar coordinates, and converting between simplified polar coordinates – essentially latitude and longitude – and standard Cartesian vector coordinates. I got rather carried away helping someone with this problem, and just had fun playing with it.

The meat of this one is just two simple functions, PolarToCartesian and CartesianToPolar, which do the conversion from one to the other. The rest is just a test rig to visualize and test these functions. Centered in the view is a green reference sphere; piercing this is a red “arrow,” indicating the direction of a set of latitude/longitude values, and a yellow cube indicates the position of a point vector. Click and drag to rotate the view around the object. Text fields let you view and modify the components of point and the angles, with the arrow and box elements updating in-scene automatically. You can move the box by changing it’s x,y,z position, then click “Apply to Polar” to convert and auto-set latitude and longitude, causing the arrow to point to the box, or use the “Apply to point” button to reposition the box in the direction of the arrow.

[download Unity project]

The meat is two fairly simple functions, PolarToCartesian and CartesianToPolar. I’ll let their comments speak for themselves…

function CartesianToPolar(point:Vector3):Vector2
{
    var polar:Vector2;

    //calc longitude
    polar.y = Mathf.Atan2(point.x,point.z);

    //this is easier to write and read than sqrt(pow(x,2), pow(y,2))!
    var xzLen = Vector2(point.x,point.z).magnitude;

    //do the atan thing to get our latitude
    polar.x = Mathf.Atan2(-point.y,xzLen);

    //convert to degrees
    polar *= Mathf.Rad2Deg;

    return polar;
}

function PolarToCartesian(polar:Vector2):Vector3
{
    //an origin vector, representing lat,lon of 0,0.
    var origin=Vector3(0,0,1);
    
    //generate a rotation quat based on polar's angle values
    var rotation = Quaternion.Euler(polar.x,polar.y,0);
    
    //rotate origin by rotation
    var point:Vector3=rotation*origin;
    
    return point;
}

Never put code in here before, thinking I ought to look for a wp plugin that does syntax highlighting and the like, but this works for now. I’ll likely revisit this project later, polish this up and implement proper classes encapsulating full polar coordinate routines and conversion methods into Polar2 and Polar3 classes; got an idea I might play with later that would need something like this in a robust form. For now, this demo should help anyone else needing to do the same thing get started!

 

Did you like this? Share it:
Posted in Uncategorized | Leave a comment

Diseases, Holidays, and Other Distractions

Been a while since my last blog post. Made some progress the first week of it, and was just too caught up working to think about blogging. Last week I started things off with a pretty unplesant case of sinusitus – which I’m still recovering from the lingering symptoms of, though the worst, including the severe sinus pressure headaches, lasted just a few days. Then came Thanksgiving, which was excellent. Ate a lot of good food, drank perhaps a bit too much beer, shot a few quail (and missed quite a few more), and all around just spent some great quality time with my family.

Since I got back, spent most of my time catching up on housework that had been allowed to slide while I was sick before I left town for the holiday, and beginning the process of putting out Christmas decorations. Other than that, I’ve gotten distracted again with unityAnswers, helping other people with their code instead of working on my own like I should be doing. Decided I’m going to clean up some of the sample code I’ve written and make a set of sample projects with short tutorial articles explaining them, will be writing the first of those right after this post.

The prototype got to a rough but playable demo level before the disease set in. Laundry list of minor features left to implement, mostly adding notification icons to help the player know what the hell is going on. Two main features left: extending the notification icon scripts to allow multiple simultaneous notifications, with options to either stack them in a row or alternate between them at some interval; and customizable info boxes that display when holding down on a character. The latter I’ve only got a vague plan for the design on, and I need to nail that down in order to finalize the list of minor doodads and dingbats in the formal asset list. Other biggest task is the rewrite of the line drawing code and the way vehicles are handled; the original approach I used turned into a nightmare, and I need to spend a day or two gutting a lot of that code and cobbling it back together with new glue code. Most of the technical bits are fine, it’s mainly the original gluing approach which was fundamentally flawed. Still feel like I’m in good shape to have the game code-complete before Christmas, which is a nice place to be. Got to get in gear and get the first batch of formal asset specs to my artist so he can get started soon if I want this game to be completed by early January, though!

Did you like this? Share it:
Posted in Geomys Games, Programming, Self-Indulgence | Tagged , , , , | Leave a comment

Burninate!!!

Series of epiphanies after last night’s blog and this morning, went all slash-and-burn on the technical design for the remaining features as I had them sketched out, replaced with something far simpler. Will eventually obliterate and replace the Routable stuff from my 3 days of adventure to work in the same new, easier way as well, but leaving it for now. The new code is flying out thanks to this. A month into using Unity and some of the big things are still clicking.

I came into Unity with a programmer’s toolbox built up from years of doing from-scratch programming in C and C++, so long before I’d really begun to “get” the Unity way of approaching things, I was hacking away with my existing tools. Was making measurable progress, too, but not as efficiently, in labor or end result, as if I’d been using more Unity-centric tools.  It’s continuing to come together, though, as the things I’ve absorbed slowly percolate around in the back of my head and the subconscious problem-solver starts finding the ways they more naturally click together.

Did you like this? Share it:
Posted in Uncategorized | Leave a comment

Deadline Looming, Progress Slow

So I made progress today, but not nearly as much as I should have. Let myself get distracted and wasted most of the afternoon diddling around on the web rather than working. Did get some real progress made, though, and so far the remaining features seem like they’re going to be straightforward; got autorouting cars entering the scene and stopping at the unloading zone, just don’t have them actually unloading yet. Also got despawn points implemented, and those do work. Built a system for managing rotation of the cars, but it’s partially hacked, since I haven’t made sprite versions yet and am still using a placeholder box. It also won’t apply to manually-entered routes, while whatever system I come up with there probably would work for autoroutes as well, so it might’ve just been a waste. A minor one, though, as I didn’t spend more than 20 minutes on the feature.

Trickiest thing left that I can think of is going to be having groups exit vehicles in an orderly manner, even when obstacles are present. This is essential to getting customers into the prototype, and is the first thing I’ll need to work on. Might just “cheat” and implement no-loitering-zones, where valets who stop are automatically routed out of them into adjacent valet loitering zones. That should actually be quite simple to implement, and will work at least for the prototype. Got the input methods and selection colliders tweaked. They were working great with a mouse before, but became frustratingly fiddly on the iPhone. Now works as well either way, though it’s still using mouse emulation rather than true touch support.

I found myself wondering today if I’m just complicating these core features for no good gameplay reason. Seems like I may be making the same mistake I make during LudumDare events, spending all my time on some particular piece of tech rather than focusing on getting fun gameplay up and running. Then again, the 48h time frame imposes some serious and artificial constraints, so perhaps it’s not reasonable to think in exactly the same terms here. I did only start this prototype less than a week ago, after all, so overall I think my progress has been good.

Overall, still loving Unity, though I learned that to keep an app below the 20mb 3g download limit may require the upgrade to Pro for the stripping features. That’s around $3,000 I wasn’t planning on shelling out until early next year. I’m hoping the asset set for this project won’t be too large, and will fit in 20mb without stripping, as it seems important to stay below that limit.

I also find myself wondering what hypothetical audience I’m writing these blogs for. They’re so specific to what I’m working on, and yet so vague on the kind of details that might actually be useful or interesting to anyone… but I find stopping to and explaining the upcoming challenges in semi-casual terms helps me to focus my thoughts on how to approach them in a way my technical notes don’t, so for now at least I intend to keep doing it.

Did you like this? Share it:
Posted in Geomys Games | Leave a comment