Well, the dust from that article and the tigsource devlog magazine update has pretty much settled. It was fun while it lasted

Had a bunch of new downloads and plays, about 500 people. Didn't get a ton of commentary or followers from it so I'm not really sure how to measure the impact of it, but I'm satisfied with the number of newcomers. A couple people braved the editor and put together some pretty sweet rides. Here are some samples, and there are a handful more in the system that I haven't had a chance to screenshot.





Anyway, back to our regularly scheduled programming!

awesome, great pictures! I've saved the big one on my computer, I can see 3 of my ships.
Really great game, and you've not even finished it yet!

Thanks! You say not even finished yet, I feel like I've barely even started

-----
I had a nice surprise to wake up to this morning. Alpha Beta Gamer must have seen this on indiedb and enjoyed it enough to do an article on their site:

http://www.alphabetagamer.com/lift-alpha-download/

I kinda wish the game was in a little better shape before something like that, but people don't seem to mind and quite a lot of people have tried it out. Some are even building some nice planes

Yeah, that's the solution.

This project is going to be so awesome to play with! You are getting me very excited about it!

Thanks Juan


And just a small update - in between building a death star and a tie fighter, I managed to put together an indiedb page for Lift yesterday.



Nothing new and nothing too exciting, but it definitely brought in a good number of new players. I don't know what that ranking means or how that system works, but it managed to get up to 41 at one point today. I probably need to proof read it again and maybe add some more details, but it seems good enough for now.

I am basically advertising this thing with all user generated content so far, so a big thank you to all who have contributed. And I really mean that. Each time I put these planes together for a screenshot, I can't help but be blown away by all the awesome stuff that has been created. Here are a couple images custom made for the indiedb requirements:





This environment I keep using is looking a bit stale. I need to open up environment editing so people can build all that content also

I have an updated build coming soon, hopefully early this next week. Nothing revolutionary, but there are a lot of changes and some new features.

Not a lot of people from indiedb tackled the editor, and those that did didn't produce much. My fears have come true, and the editor definitely needs a major overhaul. After this next update, I think I will make that the #1 priority. I have been thinking about it a lot and I have some cool things I want to try.

Just not enough hours in the day for all of this, especially with "real" work getting in the way.

Why do you need single frame logic?

Because it's awesome

There's nothing specific to the gameplay that requires it, but it is fun to pause the game and step frame by frame to see how the simulation plays out during a crash or whatever. Like in the death star gif, I did that a couple more times and watched sky whale explode frame by frame.

To solve the issue at hand I'll just set timescale to 1 during Update and set a flag so when FixedUpdate runs the next time it can set timescale back to 0 if the flag is set.

I made a death star. It wouldn't be appropriate unless it involved sky whale. I would have used supes but he can't fly anymore.

Just realised this needs death star trench run as map.

Definitely. We're going to need some tie fighters and x-wings though.

edit: Well, I gave it my best shot...

Space physics can come later (or never).

(or never).

Good call.

So I'm working on getting the challenges integrated into the main builds instead of being standalone things. And also setting them up so you can use any plane to do them, instead of a specific one that I choose. Much more fun to try this stuff with all the random stuff that is being built. And when I say challenges I mean challenge, I still only have the one that was released earlier. More to come though.

Anyway, a long time ago I built a glider and strapped it to some type of car like contraption and ran the car into a road block and the glider went flying off into the distance. At the time I thought that might be a cool loophole for some kind of challenge down the road.

glider

As I was testing the challenge with some different planes I happened to choose the pusher plane that I built a few days ago.

pusher

The challenge is set up so that when your plane crosses a certain line, it kills your engines and you have to glide to the finish. In the case of the pusher, I was expecting the same kind of result, except when I crossed that line nothing happened. I then realized it's because the plane has no engines and its forward thrust is generated entirely by the missile that is pushing it. The missile was unaffected and kept going at full power. And just like that, a loophole.

The way the code is set up, there are a couple other loopholes as well. I'm actually quite happy with having loopholes like this. Going forward, do I build challenges with these in mind and try to program them so there are a specific set of loopholes, or do I just build out the challenges and if loopholes exist, so be it? I've never been much of a puzzle game designer, so it might do more harm than good to try to force them in.

You setting the timescale in FixedUpdate or in Update?

Update. FixedUpdate doesn't get called when timeScale is set to 0, and I set it based on key presses so I need to do that in Update. I might have to adjust the way it works because I think Update could be called twice in a row before FixedUpdate gets called and my single frame logic might not work. I haven't run into any problems yet though. Why do you ask?

But yes, this could be epic! One cool thing that just came to my mind would be to predict hen a collision might be imminent and slow down, so you have either more reaction time to avoid it or to watch the mayhem.

Good idea. I'm seeing the missile map currently in the game now and slowing time down as you see a missile flying at you to avoid collision. Things could get a little too crazy so I'll probably leave it as simple time manipulation for now and let it stew for a bit and explore some ideas down the road.

And just for fun, slow motion.



I'm pleased with how easy this time manipulation stuff is going in, in regards to the physics. It is all just manipulation of Time.timeScale in Unity. Setting timeScale to 1 for a single frame and then the next setting it back to 0 seems to allow for accurate single frame stepping. I was afraid it would cause some strange inconsistent behavior, but it is looking good so far.

In the gif above, timeScale is at 0.1 for slow motion until the end when I set it back to 1 for real time.

You could make this a speed run type of game, which would be kind of like playing out a movie action sequence. It would be about maximizing the use of your weapons and skills to complete the levels in the fastest time possible.

For example, the 2nd gif in your last post about dual wielding. If there were guys in each of those rooms in the right spots, the most efficient way to go through there would be to slow time, bust out your dual pistols and spin around and if you timed it right you would hit them all and keep moving. Then pull out the shotgun and blast the next two guys.

Assuming you did it right, it would look like a nicely scripted action movie. Of course there would be a hundred different ways to do it, but I think "high scores" and just the satisfaction of doing it properly and seeing the results (read: blasting dudes up and watching blood fly without getting a scratch) of that would be enough for some nice replay value. You would definitely need to record the round so we could watch a replay of the carnage

I LOVE that gift!!!! I would play an aircraft crash simulator!

Yeah, implementing this pause mechanic and capturing that beautiful moment in time has inspired me to add some additional sandbox features to the todo list. While these features aren't necessarily focused on building a crash simulator, they most certainly can and will be used for that purpose

Thanks for the tips, Juan. I'm not ready to go balls deep in optimizations yet, but I will definitely hit you up when I get to that point and pick your brain a bit. I'm sure by then Heart&Slash will be done and you will know all the tricks

---
And now back to fun progress type stuff... inertia tensors are so boring.

I was fiddling with some pause functionality tonight and just by pure random luck I managed to pause the game at the moment you see below in the gif. I was actually flying a different plane when I paused it and had a nice surprise waiting for me when I switched to this plane.



Game over for that dude. I think he was probably going 200m/s at the moment of impact.

Ok, you want dynamic attachments. Yeah, it's not going to work....

You have to calculate your own total mass, center of mass and inertia tensor (not that difficult) and then assign them to the rigidbody (there should be only one in each hierarchy) after you have modified the hierarchy. Those are automatically calculated by unity when assigning parent transforms, so assign the parents and then run your code to calculate those and assign them to the rigidbody.

Center of mass is trivial. Inertia tensors not that hard...

So you need custom Attach and Detach functions that recalculate those and delete/assign rigidbodies to the parentmost transforms...

Yeah that is essentially how it works now. I ran into some strangeness with Unity not maintaining my manual override of its center of gravity and inertia tensor, so at the moment those are calculated and applied every frame.

One performance issue that I've noticed is when planes with lots of parts get destroyed, creating and initializing the rigid bodies seems to cause a little hiccup in Unity. Not sure if creating a pool of kinematic rigid bodies on the side and grabbing them when needed would work. I have yet to look at any optimizations.

Yeah, my current project involves attaching and detaching things from rigidbodies and this is how I'm doing it. Except I'm fudging calculations for the inertia tensor rather than studying how to do it properly  .

This discussion is going to cause me to look into my inertia tensor math again because I know it can't be 100% correct.

my math is probably not entirely correct with the inertia tensor calculation

I'm fudging calculations for the inertia tensor

inertia tensor (not that difficult)

Inertia tensors not that hard...

So Juan, what are you not sharing with us?

I have a much better understanding of what it is and how it works than I did before, so I think another pass on it will do the trick. However, if you have any good reference material, please share

Just wanted to say how much I love this sandbox idea even just looking at the gifs The love that everyone puts into their creations is great to see Customisation is king!

Thanks for the comment. I am pretty blown away by what has been created already. I like to try to showcase some of the cool stuff as much as possible with the gifs and what not, but ultimately I would like to have systems in place for other people to showcase their own stuff in whatever creative ways they can come up with. And yes, there definitely needs to be more customization. I've already experimented with some simple color selection for parts which would help a lot, and that is just the tip of the iceberg.

I can think of a quick workaround. Use several overlapping colliders to give extra mass to a section. As long as your density differentials are not too crazy, you should be fine (taking into account the heavier/denser parts are definitely going to be fewer than the lighter ones on a plane, thus few parts will have "duplicate" colliders.

Performance wise, since there's space partitioning and colliders of a rigidbody don't collide with themselves (I think) you should be fine.

Very interesting idea. I'll have to do some tests to see just how effective that is.

Off the top of my head I have a feeling it will be quite cumbersome to figure out count, size, and placement of these sub colliders to get the proper mass distribution based on what the user selects for mass and center of gravity location.

(an hour later)

For example, let's say I have a plane and I strap a missile to it. The plane has a mass of 10000 and the missile has a mass of 1000. Separately, they would be two individual rigid bodies with their own mass and center of gravity. Once I attach the missile to the plane, that rigid body goes away and now I just have missiles colliders that get attached to the planes rigid body. Let's say the missile center of gravity was up near the nose. With using sub colliders, I would have to figure out how to not only get enough mass to match what the missile was but also figure out how to get the center of that mass to be in the same spot that it was when they were separate. The closer the center of gravity is to the nose, the less room there is to work with so you would probably end up with a ton of small sub colliders at the nose.

If the plane had a mass of 1000 and the missile had a mass of 1000, the whole thing changes and a completely different set of sub colliders would be needed to solve the problem.

Anyway, I'm still going to test this. I wonder if you set a collider to be a trigger, if that is included in mass calculation or not. That could help a lot.

I think there might be one too many animated GIFs on the first page of this thread--it crashed my phone. Not just the browser on my phone. The entire phone

Cool project, though

Sorry about that

I keep adding random stuff to the first page, maybe I need to start subtracting stuff also. I'm sure those first gifs I made could use some optimizations also.

Anyway, give the game a try, I promise it won't crash

Fuck you, sky whale  

20 tries later I finally latch on.



Such an elegant dismount, 10/10. And in a furious rage I try to take him out of the sky after I dismount, but hes just too fat, and I fail again.

I've uploaded all the attempts here if you want to watch various levels of failure. Good for some plane on plane physics action at the very least: http://www.czkproject.com/files/lift/skywhalefail/

I couldn't resist. I had to put my life on hold and make this happen.



So close...

edit: to clarify, what you are seeing is just a modified sky whale flying at cruising altitude, no balloons

A balloon is generally a round shape.  It produces lift regardless of acceleration, but at the cost of significant drag.  A functioning whale would consist of one large oblong balloon, with flapping wings for flippers and tail.  An alternate design would be the classic dirigible with propellors.  Tint them red for Hydrogen balloons 

Maybe you could even match speeds with it and hook on with your plane... where have I heard that before...

Hooking on to a carrier: http://www.britishpathe.com/video/first-plane-carrying-airship-aka-first-plane-carrr

We've come full circle, and now balloons must be implemented.

Unity should model the mass and moment of inertia of a cylinder correctly; there should be no need to spread the mass along it to get proper behaviour. Unfortunately the documentation for this in unity is terrible.

While this is accurate for the most part, especially the documentation bit, there are some limitations. The first one is described here:

http://answers.unity3d.com/questions/398353/how-do-i-programmatically-combine-inertia-tensors.html

Now, in Unity, I realize you can have multiple colliders as children of a rigidbody and Unity automatically calculates the COG and InertiaTensor for the rigidbody based on all the colliders, but with one major drawback. It assumes that all the colliders have exactly the same density. It spreads all the mass of the rigidbody out evenly across the combined volumes of all the colliders. As a result, something like an empty carbon fiber cockpit would way as much as an engine of the same size, made entirely of metal.

That is a pretty significant limitation. He goes on to propose alternate solutions like having each component be its own rigidbody and attach with joints or something, but that is not good. I think KSP does something like that and they appear to have pretty significant performance problems with a huge number of parts. In Lift, there is a single rigidbody for a plane and the inertia tensor and center of gravity are calculated based on the components and their properties. I'm not an expert on the subject and my math is probably not entirely correct with the inertia tensor calculation, but it is giving the results I want for now. (comparing my calculations with what unity comes up with, the numbers are similar yet different enough to notice a difference)

Having complete control over this is also good for potentially adding other types of gameplay elements, like inertia dampers.


The primary reason for wanting to spread the mass out over the component is to have behavior like what was shown a few posts ago with the falling cylinders. I would like to have multiple points to apply physics over a body in order to have a more accurate simulation.

Even bypassing all of my custom code and using Unity out of the box, doing the falling cylinder tests results in the same behavior as I was seeing with my code and a single simulation point. It just isn't good enough.

Better results can be achieved by a user making a plane out of a ton of smaller components, but I think it would be better to do this automatically with code. I blame this quest on you since you pointed out the problems with the enterprise

Woo! Two editors. Would be good to be able to save/upload individual components (tagging is fun!). The next build sounds like a doozy.

Also. Balloon micro-transactions. Make it happen.

Saving individual components is on my list again as well. I actually have the code in place to handle it to an extent. I ended up just commenting all of that code out because it was a little bit of overkill at the time and it didn't seem all that useful. Given how things are going I think it will be good to look at it again. One of the ideas I had with that was to do daily challenges or something, where a random collection of components would be generated and people would have to build what they could with those parts. I'm sure that was brought up at some point earlier in the thread.

Also FYI, due to recent demands for balloons, development will be on hold for a while so I can go set up a kickstarter campaign specifically to pay for the development of balloons and balloon micro-transactions.