next »

[diegzumillo]

A long time ago I decided to try making a simple flight sim, and I did. Then I lost the project files and forgot about it. But recently I have been having that itch again so I decided to take it a little more seriously this time! This won't be a full game, just a proof of concept, a prototype. But I felt like logging the progress so here it is the devlog.


Pitch:

Flight simulators are great. Even non pilots love to fire one up, load whatever default plane available, take off, do some loops, and crash trying to land. Then most people stop playing because real life is kinda boring. I mean seriously, the world is basically flat! you have 6 degrees of freedom and no obstacles ahead. That's why everyone is drawn to buildings and bridges to fly close or under. So I decided I wanted to make a flight simulator, as convincing as possible, but in another world, where flying is challenging and interesting because cities occupy large 3D volumes you need to fly inside. In this game you play as kind of a truck driver, but a pilot. You fly inside cities, pick up contracts to transport boxes, take them to their destination etc. The money is used to pay for fuel.

it's not one giant city but a large world. And while flying inside cities might be challenging, you need to fly between cities, which is easy. This is when you can save the game. You put up the autopilot to maintain altitude and speed and go to bed to save.

Anticipating the technical challenges of making open world games I made my life simpler with some backstory. This planet is the result of a failed terraforming process and the population is the stubborn remaining of the colonization efforts, who were born and built a life there. THEREFORE the planet is covered in fog  

Isn't fog great? I want different levels of fog. I want the fog to be a variable to take into consideration when planning your routes. So the densest fog is where large flying predators hide. Making the fog somewhat dynamic should provide for nice tension. You start the trip with a trajectory that is close by a large dense fog volume and go to bed hoping you don't accidentally enter it. Maybe you decide to land somewhere to wait in the less dense but still dangerous fog. Maybe that backfires and you find yourself having to cross a section of dangerous fog! Maybe the weight of your current load is too much to fly over it and you decide to flush your cargo out to survive. Yeah, I can see opportunities for juicy gameplay dramas to naturally occur.

So, to sum it up, in this game you: fly a plane, load the ship, manage cargo space, refuel, manage money, make long trips where you sleep to save, avoid monsters in dense fog.

Execution plan
Obviously I'm not going to make a AAA game with realistic graphics. But even so that doesn't limit much the world of possibilities, and whatever's left can still be too much work for single dev prototype.

Idea 1: The immersive sim philosophy. First person view and freedom to move inside the ship. Want to move that crate to the side? go there and move that crate to the side.
I can make the prototype with simple boxy graphics, no problem. But that still leaves some challenges to overcome, like physics scale. The flight dynamics uses the physics system, the FPS view will also be physics driven, but the two scales need to be kept separate... probably. The plane is big and flies fast. To make that smooth it requires scale to be set with small numbers and a system that resets the root of the transform before large numbers start to mess the simulation up. My intuition is screaming to leave the FPS part separate from the plane physics. A player collider with 0.01 units of height will be problematic, the interior of the ship full of tiny boxes inside a plane flying at 200 un/s will definitely not work.
So that's the challenge there. Separating scales.

The scale problem would be present in other aspects of the game if I hadn't made the planet foggy. Because the planet is huge in comparison to any city, a city is huge in comparison to a single block etc. Since it's all foggy I can just have two scales: one planet wide scale that tracks the player's position and the near vicinity is loaded with simple procedural generation. The separation of the plane and the FPS and plane parts won't be solved that easily.

Idea 2: I really love the immersive sim approach but I feel it might be too ambitious. Another possibility is to go in a completely different (and possibly original) path; a top-down isometric view with 2D art. The transition from 3D cockpit view to internal 2D view will be absolutely jarring. I never saw anyone do this, with good reason. But I'll be damned if it doesn't spike my curiosity.

That would be a lot easier to implement and I'll be able to focus on the more abstract aspects of the game.

I'm curious to hear thoughts. Next post will have some gifs.

[diegzumillo]

Here's the flight dynamics in action:



It's a simplistic approach but quite convincing. I'm using unity's animationcurve class to define lift and drag coefficients for each part (4 wings, 2 elevators, 1 rudder, 1 main body). I used Rigidbody to apply forces at their respective locations and I use the velocity at their locations as well. I used some basic plane (think cessna) to model this thing then tweaked until it felt nice to fly.

The city you see uses a pool of cubes and perlin noise to position the cubes as you fly. Super simple but it works. The parameters of the city will eventually be defined by volumes, so I can lay down a city by simply dragging a few objects around, specifying density and other stuff.

[NovaSilisko]

I am curious about your flight model... I've done similar experiments before (in ways that sound quite similar to what you are trying) and am curious what sort of behavior it results in. Can your plane stall, for instance? It's hard to tell from the gif.

[diegzumillo]

I'm no pilot to give you a detailed analysis of how realistic it really is but, to a hobbyist, it looks convincing. It can stall, but the stall behavior itself isn't convincing yet. Stall happens when the angle of attack of any or most parts are beyond a certain number. In my model it just generates zero lift. It makes it hard to regain control. In reality I'm not even sure what happens! But I would guess lift fluctuates in complicated ways, so I might experiment with randomizing lift oscillations.

[diegzumillo]

OK, I got the FPS thing working. Decided to go with an open source FPS system. I usually don't like using 3rd party assets, even in prototypes, because most of the time I get frustrated trying to bend it to do what I need. But this one is simple enough.

I'm trying to ignore my intuition and just going with idea 1 (first post) disregarding the complexities of physics in different scales. In other words, the player is a rigidbody cylinder climbing on a rigidbody plane and crossing my fingers. For piloting the plane it's simple, since I turn the collider and rigidbody off (of the player) but what will happen when walking inside the plane?

I might implement concurrent physics simulations. Apparently that's a thing we can do now (forum post describing the process) This way I can have the interior as a separate simulation and as child of the plane so it moves with it. Hopefully that's how it works.

Anyway, I feel like I need some more temporary art before moving on. It's hard to work on this stuff with tiny cubes representing the plane.

New gif

[diegzumillo]

I was doing this 60 days levelthon of apple and worm (signature). At day 30 I decided to take a quick break and work for a week on something else. Well, this was the project I worked on! My overly ambitious scifi flight sim.

I enjoyed this a lot so I am going to continue working some more. Maybe switching projects every month is a good idea, because I really don't feel like resuming apple and worm yet.

This project is huge and overwhelming, so organization is key. There are two paths in front of me right now: shortcutting to a working prototype or implementing things that make me excited and I want to see in action.

Option one is the most sensible. Don't waste time on something you don't know will work, get the idea working as fast as possible etc. That would mean implementing (using a single coordinate system) an infinite and simple procedural city (done), simple plane interior, flight dynamics (done) with hovering functionality, and two or Three landing pads with stuff to do on foot, like moving crates, and, finally, some interaction scheme that allows you to pick up jobs, deliveries etc. And a super basic guidance system. OK, I think that's all I need for the basic prototype. Because of rounding errors in a single coordinate system, these landing pads/ports cannot be too far apart.

That's a lot. What puts me off working on this is that a lot of this will be hacked together with spit and will have to be reworked eventually, in order to encompass the other elements.

The second path now. I am itching to get started on planet-wide navigation. This requires setting up two coordinate systems. It is in this coordinate system that city limits and zones can be defined. I don't know why I am so drawn to work on this but maybe I should follow my nose.


Here's a gif with my new city generation scheme. The old way was horribly laggy and dumb. An a different approach to fog as well. I tried using volumetric lights, from HDRP and another from the Adam demo. Both worked but are too complex. I need a simpler solution and I found one. This fog is not mine, someone made (link here later), and it basically just replaces the standard unity fog but instead of pixels fading to a specific color, they fade to the current skybox. This opens up some interesting possibilities, like in the second coordinate system, the wider one, I can render some interesting fog based on the surroundings, using rendertocubetexture (or whatever the function is called)




Maybe I should at least sprinkle a few landing pads around and test flying from one to the other. Also, hovering mechanics won't have to be reworked ever so doing that now is also appealing.

[diegzumillo]

I remembered I played with a multi-scale system before. My very own surprising and incredibly simple solution. Here's a gif with 3 levels of scales. Surface, planetary, solar. 20 lines of code.



It is too simple, actually, but in this project I only need two levels. In a space game high speeds are also a concern which might be solved with a more robust multi-scale system, like setting speed to zero in the basic frame and the next frame inherits, or stores, the remaining speed. None of this is of my concern. In fact I can hard code most of the game right now with this. Basic level generates terrain and buildings in a small radius, and also resets the origin when necessary. Second level is around a sphere, it takes position and velocity and applies it in spherical coordinates (horizontal velocity in basic frame is tangential velocity in high frame). Since the world is covered in fog I don't even need to stack cameras, you only see what's near you. But I do want to render a nice cube texture to be used as a skybox, and this is done in the high frame. The high frame defines the world, geography, position of cities and places of interest.

Unless this turns out to be problematic. A planet is still too large to position, say, a landing pad. We'll see.

All right this is my night job now. I am sure there are problems with this I'm not seeing yet.

[diegzumillo]

I wanted to find the simplest solution to a global-scale game world. Ironically I spent the last 3 nights cracking my head over it. Ironically because maybe it would be done already if I just chose a path instead of trying to think 1000 moves ahead for every micro decision. Since writing about my problems tends to help me, here are my thoughts so far.

The absolute simplest possible solution: The world map is a plane with its sides connected. Imagine a square, you reach an edge and come out the other edge, just so you don't hit invisible walls. Unrealistic but easy to implement. I can define the geography of the world in this map, scatter all the things I want there etc. Translating this scale to the actual local scale, where the action happens is trivial. Fun fact, not only this isn't a sphere as its topology is that of a doughnut. The geometry is still euclidean.

I have a couple of problems with this approach. First, I set out to make a realistic flight simulator. It seems the least I can do is make the world round. Second, I am not ready to ditch the possibility to achieve orbit around the planet. Orbital mechanics is awesome, and I would love to have some orbiting bases for the player to dock in. Going the plane route basically scratches that future possibility.

What I do like about it is that it's simple and easy. And I should know better, I really should. The one thing hampering my projects, all of them, is increasing complexity to overwhelming and unmanageable levels. Is orbiting the planet really feasible or that important? It's a flight simulator! planes don't go to space! Besides, coding isolated functionalities is one thing but I do need to prioritize the ones I really want.

So the other approach is to make a round planet. The main scene consists of two sub-scenes; the local scale and the planet scale. The direct input controls the player in the local scene, which passes any displacement and rotation scaled up to its planetary scale counterpart, which in turn feeds the local scene with terrain data and gravity direction. Since the planet is covered in clouds and fog, rendering isn't an issue. I don't need to combine views, although that wouldn't be that much of a problem. The local terrain needs to sample height from the main texture of the planet, combining with some deterministic random bumps for detail.

All of this is feasible, but it would still not be enough to allow orbital motion. When achieving orbit we start dealing with very high velocities, which require special ways of handling. Large numbers and floating point precision do not affect only position, high velocities are also a problem. So that argument above about wanting orbit in the future kind of gets a fart to the face, doesn't it? I mean, maybe it's not that hard either. It's the equivalent to floating origin but with velocity. When the player crosses a specific speed, it zeroes out but the planet-scale counterpart retains that excess speed for safe keeping.

To put some numbers. Player is moving at 300 u/s (units per second). The planet-scale counterpart is scaled in such a way that it moves at a 0.3 u/s. The input flow is always local->large. But when the velocity gets to 301 u/s it resets to 1 u/s, but the planet-scale counterpart is holding 0.301. Which means the input flow is now two-way. The theory is fine, but the implementation seems like it would bring me a new surprise unexpected side effect every day.

All right. End of wall of text. Did I decide anything?

Godammit.  I'll just code whatever.

[NovaSilisko]

For the sake of your own sanity, do not do this.

Take it from me, as someone who has gone nuts with trying to manage this same multi-scale system that you are trying to.

In my case I have several layers. Terrain engine to keep spherical terrain, local planetary coordinates stored in double-precision, a floating origin system to reset the player so they don't move too far from the engine origin, another layer of double precision above that for interplanetary movement (and then another one on top of that for interstellar)

It probably sounds way easier than all the space-warp stuff in Apple but I assure you, it is absolute quicksand. Maybe I'm extra jaded because I've done it three times over, though.

[diegzumillo]

For the sake of your own sanity, do not do this.

Take it from me, as someone who has gone nuts with trying to manage this same multi-scale system that you are trying to.

In my case I have several layers. Terrain engine to keep spherical terrain, local planetary coordinates stored in double-precision, a floating origin system to reset the player so they don't move too far from the engine origin, another layer of double precision above that for interplanetary movement (and then another one on top of that for interstellar)

It probably sounds way easier than all the space-warp stuff in Apple but I assure you, it is absolute quicksand. Maybe I'm extra jaded because I've done it three times over, though.

Oh no, I believe you 100%. This has all the marks of quicksand. I know because I tend to get stuck on these a lot.

However (this is where the drug addict gets a little defensive during his intervention) if I ditch the expectation of eventual orbital stuff I can live with two layers only. With the fog thing I mentioned before there would be no need for fancy resolution changing terrain etc. It's basically just a way to have a spherical world map, really. I actually tried really hard to get a spherical world map in some simpler way but the simplest solution does seem to use two layers in scale. You move around the sphere in one scale and the other scale is just you moving around a small patch of terrain, occluded by fog.

But I'm open to suggestions! If you have an idea on how to do this any other way I am all ears. I considered defining the global map on a plane with a spherical metric, but I'm sure that will come with just as many complications as this method, like the singularities at the poles, or alignment issues because the spherical metric is a little complicated, and without the benefit of having been implemented by others for comparison.

[NovaSilisko]

Some sort of curved terrain and a floating origin system would be a good fit for you, then... sometime I should make a little example project to put up on github just to easily demonstrate how that sort of thing is done.