Moving to the .com!

This blog is moving! Future posts will be made to the new .com website. The blog is under the NEWS tab.

http://www.cleverous.com/

Thanks!
- Lane

How To use the Rift with Mecanim characters for head orientation

So a while back I made this video:




 




... And then proceeded to get quite a few requests on how it was done, so I made a real quick tutorial on how you can approach it.




 




 This requires Unity Pro and Playmaker for the IK stuff.

 Have fun! =)

Brevis: Development Progress Update 2

   Oculus Rift

If you haven't put the Rift on your head yet then you should be aware that you are really, really missing out. It puts you in the game, its going to be huge, you'll flip when you see the depth and scale it can introduce... The problem is, some of the totally awesome stuff you can do with the Rift and head orientation is really incompatible with non-Rift control schemes... For example, using your head to stare at an enemy to get a lock on for your intercepting missiles. That's something you can't do without the rift and keep the same control of the ship. You can literally now use your head as part of the control scheme and it feels super natural and fun.

So essentially, if you want an awesome Rift game that really gives you the fun factor of the Rift and embraces it rather than tries to squeeze the Rift in as an "optional addon" then you have to remove the ability to play without it. This is both unforunate and really great because on one hand players will be sad that they need a Rift to play but on the other hand it guarantees that there will be really cool new functions and features in a game that drastically introduce new and fun means of experiencing the game and interacting with it.

Bottom line: Brevis is Rift Only, but expect awesomesauce.

   Unity 5

The Project will be updated to Unity 5 when available. This includes the switch to using Enlighten and PhysX 3.3, among other very cool imrpovements and optimizations. It will use DX11 only features.

   Lighting

A huge drawback to using the Rift is optimization. Duplicating the views and using two separate cameras means doubling the amount of rendering you have to do for the game. This is extremely taxing on the game. The good news is that the nice people behind Sunshine (the light shafts in the game) have hugely optimized their asset so that it can reuse information between cameras which means a big boost to optimization since we only have to compute it once, as well as a slew of other updates that give more front end control over the quality and such.

Stats:
Previously:
Drawcalls between ~5k - 8k
FPS between 35 - 50

Now:
Drawcalls between ~1k - 3.5k
FPS between 60 - 75

And this is on my current hardware. The target for Brevis is next year's gear, really, and since I've got a bulk of the heavy perf hitters in the game already I think I can safely assume that this is going to run smooth!

   Explosions

I like explosions. They're pretty. I always like to mention that these are constantly being improved. There is currently a fairly traditional approach to the explosions and effects ingame, but there is potential that this will switch into a significantly more delicious detonation of thine enemies by using Pyroclastic effects via DX11. I took a whack at doing some preliminary stuff but was having trouble making it scale in the project and distort the effect like I wanted so i've put it on the backburner for the time being.

   Artificial Stupidity Intelligence

The AI in Brevis is actually starting to act fairly smart. Other than avoiding asteroids which it actually does exceptionally well now, it can chase targets, lead them, attack them, destroy them, then do other things that it might feel necessary such as wandering in circles and going to places that I tell it are places that it needs to go. Stuff like that.

   New Ship

I learned a lot when I did the Free Oomph Kit Models, one of those things is that seeing stuff in front of you when you're flying a ship is freaking important. GUI, hull shapes, and cockpit design is all really important to deliver immersion and eye candy to a player when they're cruising through the game.

Fortunately, I like making delicious models so the new ship is populated more along the lines of where it should be. The first ship (Blenny) was made for maximum visibility. This new ship (Falcon) is made for maximum awesome.

   VR Nausea and Controls

Another thing that is hard to nail down is the sickness and nausea that you can get by using the Rift. The majority of the sickness induced will come from poor implementation of the control scheme which leads to unexpected results and disorientation when what just happened is not what your brain expected to happen.

So far, in the standalone builds I've put out there the results have been positive in terms of how acceptable the levels of disorientation are and we're in the very early stages of development so I feel pretty confident that I can eliminate the majority of sickness caused by the game itself and that makes for a much better play experience. Us gamers tend to get on long stints with hours and hours of screentime and even skip meals while playing "just one more mission"... I certainly wouldn't want to take that away from anyone because the game made them feel ill, so this is a very high priority issue for me. And FYI, there is no 'muscling through' the game if it makes you nauseous, your brain can't cope with that crap and you'll rip that thing right off your face.

   Voice Acting and Character Interactions

I've started on some basic voice acting and begun looking into lip syncing the characters with facial animation. I have a brand new mic that is totally sweet and have started on some DIY home recording stuff for this kind of thing.

   Music

Killer tracks can be a huge part of the game. At the moment I'm planning to do all of the music myself. I have some history with basic composition and the software I'm familiar with has grown significantly since I last used it. I've done some mockups when looking at the new features in FL Studio and have been pretty happy with everything. I hope to nail down some basic features in the game like better character interactions, combat with the AI, weapon FX, space debris, ship customization interfaces, Holodecks, ship UI, etc... And then make a quick trailer which will feature some of my original music made for the game, soon, as in <8 weeks.

AI update & new ship block-out!

Well I finally got a chance to put some time into the AI, and it's running much smoother now. =)

The system is pretty flexible, and I could scale a variety of AI and weapons from this one system. I separated the FSMs to be serving more concise purposes and they're communicating based on some rough rules which seems to be able to keep it behaving like I want.

Combat was the most significant addition, I've added a Lead Target action which allows me to input the estimated weapon projectile speed and the enemy will steer toward an intercept point when it acquires a target. This is going to be really cool when I get the homing missiles added and they have to lock on to you before firing. Setting that up is nearly trivial, just change the weapon speed for the lock-on, change the conditions for firing to require a bool and he would start firing homing missiles after locking on with rudimentary intelligence.

I wish I had time to make this like I really want. There are so many really amazing algorithms, ideas, and methods to create hugely scaleable AI that has much better locomotion than these guys but I simply don't have the time, so we'll have to make due with the regular tricks =)

This will be available for download on the Playmaker forums hopefully tonight so you can take a look at it yourself and see how it works. Feel free to make comments/questions/suggestions.

*edit for download link:
https://dl.dropboxusercontent.com/u/38606641/AI/AITest-r2.unitypackage

New Ship!

The new ship block-out is the Falcon, inspired a lot by the Star Citizen Scythe and Avenger ships.

One of the things I learned from the last ship is that cockpits have to look awesome, you need to see something happening on the ship from the cockpit seat and that any interesting trinkets or details really help with the feeling of scale.

I tried to address those things in this block-out concept and have a pretty good idea on how to move forward with the shapes to make them ready for functionality and prepped for in-game asset conversion and optimization.

Weapons will be mounted forward on the wings either side, so you'll get a clean view of them while firing and I think it will result in a pretty interesting environment for the pilot and help to ground the players to the ship when playing with the Rift... Nausea is hard to control when you have all these crazy physics inputs to deal with and balance out, so anything static that you can fix your eyes on is helpful.

Let me know what you think!

Development Update

• Added ingame avatar in first person 
• Added IK links to the ship controls 
• Added placeholder UMA generated NPC's 
• Added mockup space station (better than the old one) 
• Added improved 3d GUI for the ship and interactive consoles 
• Removed main character head and gave her zombie arms. (rawrrrrgrrhhahh) 
• Updated Standalone on dropbox to current build

• http://dl.dropboxusercontent.com/u/38606641/Brevis/StandAlone/Brevisgame.zip

Game progress update

It's work... but its feeling more like play now.

Since the last update a couple of weeks ago I've been working on getting the Rift working great in the game. It's had some issues, but its not so bad.

     Multiple Cameras

This is a pretty common issue with FPS games that use a second camera to render the weapon in your view at a different FOV than what you see in front of you. It's not a major issue there because perfect alignment doesn't matter as much, post effects can be different and you have some flexibility between the two cameras.

With the Rift both cameras have to be in perfect alignment or you feel like your eyes are crossed. That means getting post effects identical, doubling the amount of post work being done, and sometimes plugins don't like using multiple cameras at all and you have to address their complaints.. The Rift distortions must be the very last scripts on the camera.

     Shadows, lighting , reflections and culling

Culling for optimizations is common but sometimes there is a breakdown when one camera can see something and the other one can't. The game might use the "main" camera for deciding what to do in certain situations and not consider what the other camera is seeing and thus producing artefacts. Shadows sometimes do not align correctly or might jitter in one eye. I had a rotational script on the camera parent and it was causing some conflicts with the OVR scripts and making only one eye jitter the shadows. This has something to do with the sequencing of scripts being run since the camera rotation was accurate but was being corrected between updates too slow and Sunshine was jittering more frequently, or something.

Reflections/cubemaps might have some issues as well. Still looking into it.

     Rift settings and scale

Aligning all of the settings to yield immersion is probably the hardest part... Building a character setup that fits into your game is tough, there are a bunch of settings to adjust on top of some being changed by the users preferences. Stuff like neck offset makes a big difference when you turn your head and people of different heights will feel the discrepancy between the game's offset and their own offset, character height would be best handled dynamically, injecting the OVR settings into the controller and setting up neck offsets at runtime.

Scale is weird too. It makes a difference how 'big' things are. It's always been important to add details to the world around you so you can get a sense of how big things are but now its like 10x more important. If you're doing something interactive in a semi-real world you won't get the wow-factor unless you have sufficient content and reference points to tell the player how big things are. The OVR scripts for distortion also play a role in how accurate things look and feel.

     Use the Rift as part of your control scheme

This is le importante. It's pretty awesome when you start interacting with the world with your head. Suddenly its not so much about pushing the right buttons and is more about physically doing something to affect the game.

I added look-at target locking to the ship and improved the guided missiles so that now you can just look at an enemy ship and start locking on, a couple of seconds and it will confirm a lock and you can unload a bunch of seeker missiles on it.

It feels pretty awesome, especially with sound feedback - way freaking better than pressing tab to cycle through nearby enemies. I'm going to investigate other ways to use the Rift like this, possibly with gestures.


     Using the mouse kind of sucks now


The Rift is awesome and the mouse is really dragging it down. The problem is that you can turn your character with the mouse and turn the head separately with the Rift. The issue is finding forward again with the Rift. Some demo's have added a dot or something so you can find forward but at some point you'll end up looking off to the side (even a little bit) to walk forward. Some demo's weigh the Rift forward with the Character forward and the mid-point is forward, so its kind of shared and doesn't get as confusing. But either way its very weird and is definitely a breakdown point. I'm looking for ways to fix/improve this.

     Screenspace and GUI

GUI doesn't work at all. You can't do anything in screenspace without custom scripting a solution to mirror it in both cameras perfectly. Which.. is fine.. but zero of the traditional methods and GUI plugins will work out of the box.

Sorry.

The best solutions so far are doing interactive 3D GUI in worldspace (like Brevis will be) or hackup an existing GUI to project its view onto a plane in front of the player's face. Curved surfaces seem to give the best results and flat surfaces feel broken, warped and generally unnatural.

The skies will rain money on whoever builds the first Rift-specific GUI solution.

     Skyboxes

Skyboxes don't work, the way they are processed by the engine disallows them front being distorted properly by the OVR lens scripts.

Bye bye skyboxes.

I'm using a custom skybox which is basically just a huge box spawned at runtime with my skybox textures, an unlit shader on it, a layer that is culled by lens flares and it just follows the position of the player..

It's not as good as the built-in skybox and has some volumetric side effects if you're using any advanced lighting systems like Sunshine it will complicate your problems and change the way things look depending on the scale of the Skybox. Also depending on the scale is the culling. It took me forever to realize that my runtime skybox was cutting off some objects after I moved far enough away (man, I'm stupid huh?) but scaling it up had some side effects for Sunshine..... Balance... Precious balance...

List of recent updates / changelog

• Removed Ship Building Interface (coming back later when GUI improves)
• Reduced ship speed by half
• Added First Person Character control
• Added look-lock system for targeting with the Rift
• Added interactive random ship building interface in the hangar
• Added functional enter/exit scheme to the ship (you can walk in, sit down, fly, get up, then walk back out through the hatch)
• Added Proportional Navigation algorithm to seeker missiles
• Added better explosion, impact, launch and missile trail effects
• Added better sound effects
• Added various optimizations to all current systems
• Added new, more advanced GUI interface in Hull_1
• Added stationary turret enemy system
• Adjusted sound settings to scale better over distance
• Adjusted Sunshine and Lighting systems

Standalone Windows Build Download (~107mb)

like.. whao.. Oculus Rift in spaaaaaaaaaacce.

So I got the Rift in the mail on Monday night.

Space in the Rift is kinda of like... " ..Hnnnngggg... "

Putting the Rift on is like bending time and space itself to do your bidding. You like explosions right? They're pretty cool? Wrong. Those explosions are for pussies. Explosions as you know them are more like 99 cent firecrackers until you put a Rift on. You literally see and feel depth with the rift in a way you can't explain, convey, or visualize on a flat monitor. The sheer awesomeness of all content that ever was or ever will be is multiplied by a factor of ten with the Rift.

Ah, you think I'm exaggerating by now.

Nope.

Nu-uh.

Nein.

Negatory, sir.

This thing melts faces. If it wasn't for this Dev Kits' twinky 1280x800 display I'm pretty sure I would have stapled my eyelids open and played science until the sun came up and negotiated my surrender.

I'm going to do everything I possibly can in Brevis to make people crap their khakis while playing. I hope you like awesome stuff, because in 2014 there will be plenty to go around.

To IndieDB we go

               

I finally got around to putting the project on IndieDB, so you can also track progress there but most of the juicy low-level devblog stuff will remain here while the bulk of the content on IndieDB will be high level 'pretty' updates for gamer types and not so much dev types.

Moar Lightmapping

Today I got very acquainted with lightmapping.

After beating my head against the wall trying to squeeze proper control out of the basic lightmapping options I started looking for tips online and found out that there is an extension. Lightmapping Extended is a very good - and free - addon for Unity that exposes (and comments/explains!) nearly all of the better controls for Beast's lightmapping. If you're familiar with rendering traditionally then you'll feel right at home in its panels.

I also found some good case studies and experiments on this blog which were helpful and would do well to supplement your customization choices and help optimize your bake times. You may find these tips useful as well as he talks about optimizing for mobile and a few other interesting concepts but first and foremost get the plugin if you're looking for more customization in your bakes. It was like night and day for me (no pun intended).

Emissive texture maps have been proving to be a very good part of the lighting setup. In many places they give a significantly more natural and appealing look than regular point lights and while I have a lot of settings to tweak to make them look as good as they could in my scenes I think you'll see the positive aspects of them immediately in this video.

I've done some small scale tests on the lower level and hangar and it's going to look totally killer when I'm done with it and have a clean bake on it but for now I'm laying it down and moving on to finalize the level design here and work on fleshing out the NPC locomotion and building some character clothing overlays for them.

AI under the hood, UMA, Characters and Levels

I've got some basic UMA integration into the project. UMA is Universal Multipurpose Avatar, it has a basemesh for Male and Female characters, some rudimentary clothing accessories and massive capabilities for generating random characters or tweaking every detail of a character's face or body.

So far I've only played with making a custom character in the provided example scene, serializing it, then reloading it later at runtime. It's quite efficient since the base mesh is just fed a bunch of variables and changed per them.

I've got some rockin' level design going now, big improvements to the visuals. The stock kits I've been using have been getting really overhauled, the textures are significantly different now and I'm working on some fresh models and unique applications for them to deviate from the standard look which really helps the game look unique.

Full Image

I've made some progress with AI, but still no significant leaps.

I think I'm going to stick with what I have right now and work on prototyping some combat behaviors and see where that takes me. I can always come back and polish a system since they're all totally segregated and independent from each other.

Heres the latest on the AI:

Inside the design

With the Flight System basically sorted out I've moved to the interiors for the game and brought over the First Person stuff, tweaked it up and started looking at ways to slap the two together as well as working on the playable interior areas, character generator, flying straight from space to ground level of a planet, researching how to do better audio, character speech, design AI and a bunch of other little things.

Working on the level interior has been interesting, I've figured out the basics of lightmapping and batching that will help keep the interior's buttery smooth ingame and realized that making interesting interiors is more of a challenge than I expected.

Also, the Elevator. kthx.

Other than that I've worked on improving the overall atmosphere in the space scenes, put together some basic AI with a physics driven motor that can effectively wander and avoid collisions almost completely, investigated randomly generated characters to be able to store them and inject them into the game later by script, made some minor advancements on the ship GUI and other small features.

Hoorah! It's looking better every day. I'm sure the videos are kind of boring to watch for most of you, but for me the things they show are good, solid improvements and progress. Next video should showcase a pretty significant update, either 1) active characters ingame, 2) entering atmospheres from space with landing on the terrain or 3) AI battles. It's all some distance away and needs a lot of work to make any of them happen but I'm inching closer to them all the time.

Building Blocks

The Oomph Kit is out the door at v1.0 for anybody to use and learn from for free, so far response has been mild so it doesn't look like I need to shovel time into updating it which means I can move along with other things.

So what's next?

The Oomph Kit actually started as a Hovercraft segment of Brevis and spun off a huge pile of learning I had to do with physics, vectors, directions, rotations, transforms, quaternions, mass, torque, force, velocity and accelerations. It was at that point I realized what everyone really meant when they said to start small - there are things you simply do not 'just whip up and figure out' and you have to either sit down and study them, cut them from your plan, or suffice to implement a cheap corner-cutting alternative. In this case, I sat down to figure it out and quit working on Brevis. I can only imagine how blown away I would have been if I had scoped out a more complicated project. The Oomph Kit actually was trimmed down as well, I had originally planned to include several more cool functions but ended up deciding that people would probably just want to butcher the system to cater to their needs, so I just left them out. You'll see those functions in some videos later.

But wow did I learn a lot. I don't know how I got along before, and even at this point of publishing the kit I have to stop myself from rebuilding the whole thing more efficiently (again). I'm really glad I did spend the time to spin off and make a project just for the sake of learning physics in Unity. Now that I've got a better understanding (certainly not complete) of that I think I'm going to move back to working on Brevis.

This week I started getting back to conceptualizing characters and started modeling the protagonist. It felt really good to get back into ZBrush and carve up some shapes, for me its so much more enjoyable than doing hard surface objects in max. At this point I've lined out a basic scope for the first level and I plan to build everything to prototype that level before getting any further into the scope and/or design. I'll also be getting into some areas that I haven't touched yet, like Mecanim, Character Animations import/exporting, Character Rigging (Max), AI design, custscenes and so forth.

Speaking of AI... That is one of my next objectives to nail down! As we'll be in space flying around I need some AI baddies to dogfight with you and they need to be slightly more intelligent than the asteroids you're avoiding. I had some ideas on how to make it work but I really need some input from more knowledgeable people. Doing physics based flight was kinda hard to get feedback on and answers for and AI is way more niche than that and all of the threads I'm able to find online are extremely vague, to the point of frustration.

I've found some good documents online that have got me started.
Steering Behaviors (1), Steering Behaviors (2), F.E.A.R AI Design, Unity Answers Flight AI

That is my primary focus when I'm not doing the character models at this point, and I think it will end up being a pretty hard cookie to tackle for me. Feel free to send me any info or help that might be relevant.

Look for some videos or images coming soon on the character model progress and likely some blog posts on the AI systems being worked on.



Early pics of the protagonist for Brevis...

Released Oomph Kit 1.0 project files

You can download the Oomph Space Kit Project for free, follow the link through one of these forum threads.

Unity Forums
Playmaker Forums

Enjoy!

Post up if you have any comments or troubles using it.

Ammunition, Weights, Names and Sounds

We haz ammunition!

I got a basic ammunition system put in today. Each Hull and Wing has a max capacity for ammo and this is combined to give you a max ammo capacity when you finish building the ship and go to fly it.

Now the trick is setting up good scales for figuring the weight of the parts in conjunction with ammo capacities. I figured out some basic numbers but they need to change, I think.

(Base item weight) + (Ammo capacity) = (total weight of part)...... Or.. (Ammo capacity * 2) as currently the i'm assuming you need more mass/volume to support storing more ammunition and I just made them equal to keep things simple for now.

You can also run out of ammo and make the guns upset at you so they quit firing. Thats no bueno dude.

We haz weight!

It was pretty much just as easy as I had hoped, too. I gave all of the parts a weight float and grab that at the build time for the ship. It takes that total weight, divides it down (*0.05) to a magical number near what I want the mass to be and changes the Mass property of the ship's rigidbody component.

What I haven't done is have it update the ship's Mass every frame so you lose mass when consuming ammunition. That would be kinda neato, eh? Slug on over to the baddies, drag your direction into firing vector, unload gratuitous ordinance and feel the weight of a thousand suns lift from your figurative space shoulders while your top speed suddenly grows to 5x its previous amount.

Or, alternatively while trying to dogfight someone it is continuously screwing up your aim by changing the mass and directly affecting your control responsiveness.. Not so cool in that sense...

Names and other stuff

I laid down the basic variables for naming parts and all of the data I think I'll need to take the hangar GUI to the next level but I'm not sure if I want to do it for the free package since I want to use RageSpline for it and the regular GUI wouldn't improve much. I'll probably just leave it alone for now.

It should be gravy when I get it going though... Just mirror the variables into a hover box when you are building the ship or something. Who knows what it'll end up looking like.

There were a bunch of graphical changes on this build, new rocket models, effects, testing some things to see how they look, adjusting point lights on weapon effects, changing material/texture appearances etc...

Sounds... Oh those evil sounds...

Trying to get sounds to cooperate is not fun. Props to anyone making sound games or making games on a physical scale that is not normal. Anyone with tips/links on getting sound customization under control and making it do what you want with falloff, distance, parenting, etc.. please feel free to message me.

You can check out the WebPlayer Link if you want to see the changes.

Coherent design is melting my brain

It starts pretty basic most of the time, you get an idea, start working on it, fix a few hurdles and adjust some ideas, make some great progress and then hits some evil wall that you never even saw coming and will need to start reworking systems or designing things totally differently.

In my case its these model constraints on the ships. I've been deliberately making the shapes weird to try and identify where I would have problems (I secretly love being angry and frustrated all the time) and go figure I'm running into issues with size and placement of models on the hardpoints when they're mix-matched. For instance making a long hull and putting the mounts for the wings near the back of it, then realizing they clash with the engine if you use the wider, larger engine but everything is peachy on the short hull with the mounts in the middle. Is that a problem with the mount location? The wing length? Hull length? Engine width? Theres so many factors it can get really difficult to choose which one to clamp down on to get good design constraints.

I look back to Black Prophecy (2010 -2011 space action game with a ship customizer much like this) and wonder how any of those guys managed to stay sane while doing this. They had the same diversity in their model combinations but I suppose they just made tighter constraints for sizes of things to keep it all in order. I'm still just amazed that they could have so much ship diversity and fluid design without clashing parts all the time. Too bad it flopped.

I hope I don't have to keep redesigning the ships. It seems that I'll need to sit down and define maximum sizes for a lot of mounted items to prevent overlapping and clashing.

On the up side I did make some new models for Oomph and get them loaded into the webplayer. There are some more functional camera controls in the pipe that will allow you to view the ship better so you can get a good look at the new weapons, hulls and engines. You can also now change your thruster color values thanks to Jean for some cool new HSV Color Actions. I had been messing around with adjusting those colors with GUI sliders last week but it wasn't working out. His actions made it much easier so check out the color slider to change the thruster colors! =)

Oomph goodness

Physics, space, and science.

Oomph spawned from working on a Hover Ship system with the Brevis project, then eventually I realized that firing lots of missiles, blowing things up and flying through space at high speeds was much more fun than throwing boxes around with the force. So I switched gears and moved on to Oomph.

After throwing together the physics side of things for Oomph, testing, testing, re-testing, changing, fixing and testing that ship more and more I started to get pretty tired of looking at it. That silly ship and its pointy, low poly, projecting wings and ... stuff.. whatever those pointy things are. (you'll know if you had kept up with things on the Playmaker forums)

So I manifested a new ship and in doing so began to wonder how the next iteration of the shop was going to work. Currently you could make 3 things, [1]Hull, [2]Engine and [3]Wingset. This worked fine for testing purposes since the ship would grab the engine and wing data and figure out the horsepower that puppy was pushing and what pewpew to make it shoot.

But, this did not appease my inner nerd! Nothing mounted dynamically, everything was based on object prefab pivot points, you couldn't change the weapons from the wingset and it would not allow much diversity long term.

Then came the glorious day I overhauled the shop (like... friday).

Now the menu is way more comprehensive, you can change the left and right wing independently, weapon mounts now exist, you can mount them on any wing, the weapons know if they are supposed to be in firing group A (left click) or group B (right click) based on their mount point, every mount reads its parent object and figures out where it should be, how its rotated, builds the thrusters on the fly, and the best part is that as long as I name the hardpoints correctly in the prefab then I don't have to do anything more than add a GUI button in the shop for any new Hull, Weapon, Wing, or Engine that I create from now on.

BAM, SON.

Needless to say, I thought this was pretty cool and was pretty surprised that the beer I was able to pull it off and get things actually working as intended. I learned a lot about using temporary variables and generalizing state machines for purposes while parent states define the properties for them to execute and now my shop does my bidding. HA!

If anybody has questions about how this works feel free to post up or find the downloadable project with all the assets on the Playmaker forums.

Physics are hard.

There hasn't been a really juicy update lately because I've been stumped on designing a flight system that only uses the physics system to power it. It turns out that its pretty easy to throw down a rapid prototype but it is obscenely difficult to control it and create a feedback loop for it to manage power controls and auto balancing features so that you can actually fly the thing instead of just spiraling out of control when you press the wrong button.

I have learned a lot about PID controllers and it's helped me get some basic principles down but its still quite hard to build a good flight system. There are a ton of floats changing all of the time and math bouncing off all kinds of other variables. Surprisingly this isn't as difficult in code but PlayMaker does not have an equation action to rapidly do an equation and store the result, you have to multiply, subtract, add, divide all as separate actions and floats and that is quite cumbersome when you have a lot of math going on and need a bunch of calcs done on every frame. Notably, this is only the second time i've been disappointed in any way with PlayMaker since I got it in 2011 but it is mortal after all.

But I did seem to be able to keep it pretty modular, almost everything is based off of the mass of the ship and there are a few principle floats that control the bulk of the background calcs related to power control and magnitude of player input so I'm pretty happy about that, I just hope as I continue that I can carry that ease of use into the autobalancing system and other features that will be in the kit.

Eventually, the prototype for the flight system will be posted on the PlayMaker forums for other PM users to delve into and use for themselves.

Overgrown

I finally got around to putting some time into the a little level design. Not so much design, more like just throwing in the assets and seeing how things are looking to get a feel for the tools I've got.

I've definitely got some core things to sort out with textures, differentiating between the cube types, spec and reflection levels, asset variety, doors, more props, making it look good in the dark and in the light... All kinds of stuff I ran into that has to be sorted out. I feel pretty good about the scene though.

I think it's generally going in the right direction and I've got a decent base set of assets to work with that I can build into a more varied group and make what I want with it.

What do you think? How's the style look? Any comments?

More GUI goodness

Looks better now that there are some effects. Finally... Feels a little rewarding to finally see it working, glitch free and with nice holographic glowiness. Going to flesh out the panel buttons and throw it in the game.

Testing 3d GUI and interactivity solutions

Played with some GUI and holo-screen interaction ideas using Ragespline and PlayMaker. I think I'll be doing a lot with these two in the game.