Tools for creating "Multiple World" games such as Damocles

UDK, Unreal Engine 4 and Unity will all allow you to create a solar system with multiple worlds. No problems there.

At least in Unity I did that myself, works like a charm. Basically spheres orbiting each other with some shader wizardry to make them look more like planets and moons. Flying around is as simple as setting up a camera and creating some player control scripts.

Of course, if you want your camera to follow a spaceship, that should act in a "physically correct" way, you might need to setup some physics components also.

You need a rigidbody, no gravity (you could add gravity around the planets if you wanted, and change the rigidbodys gravity on the fly), low drag, and add forces whenever a thruster is fired.

Not rocket science at all. No expierience yet in the Unreal engines, but I guess the same is true there.

Now, if you want to be able to close in to a planet and orbit, or even better, land on it, you are facing a bigger challenge:

Your simple sphere will now need multiple "LOD", basically the closer you get, the higher the polycount of the sphere, the bigger the resolution of the textures. I think you can look up "level of detail" or "LOD" yourself to find out how this is done normally.

When you want to land, you are basically making your simple Scene like 10'000 fold more complex. In the simplest case you create a second, on-surface scene, with a loading screen at the transition between orbit and surface.

There are people that came up with systems to allow a seamless transition of a sphere planet model in space and a planetary surface scene. Most of them involve procedural terrain creation to make sure the surface is different if you land at different spots on the surface.

Some can be bought or downloaded as Engine "plugins". If you go with Unity, search the asset store for such systems and plugins.

If you want to write such a system yourself, you will spend a lot of time on it. Make sure you REALLY need it in your final project before you start to invest the time.

UDK, Unreal Engine 4 and Unity will all allow you to create a solar system with multiple worlds. No problems there...

Hey thanks heaps for this. I understand what you are saying and I think it is the "switch-over" that would be the most complex task to solve. I don't have any intentions of using loads of textures etc - it would be very minimalistic (think early 1990's). As long as I can transition from space to world that would be the ticket.. which I guess would have to be done when the proximity of the sphere is such that it no longer appears to have a rounded surface?

It may be worth me having a look at Unity. Unless I can combine multiple engines, I don't think Unreal/UDK will work for me.. (perhaps I'm wrong) If its possible to quickly load up one of these engines and switch it over via some code of my own then perhaps that could work.. but I there would be lag in doing so.. unless the Unreal level loading can be done via code/script somehow instead of using its 2D level loading tiled map.

Hey thanks heaps for this. I understand what you are saying and I think it is the "switch-over" that would be the most complex task to solve. I don't have any intentions of using loads of textures etc - it would be very minimalistic (think early 1990's). As long as I can transition from space to world that would be the ticket.. which I guess would have to be done when the proximity of the sphere is such that it no longer appears to have a rounded surface?

It may be worth me having a look at Unity. Unless I can combine multiple engines, I don't think Unreal/UDK will work for me.. (perhaps I'm wrong) If its possible to quickly load up one of these engines and switch it over via some code of my own then perhaps that could work.. but I there would be lag in doing so.. unless the Unreal level loading can be done via code/script somehow instead of using its 2D level loading tiled map.

Unity IMO is always worth having a look at, as its free to try and actually build your game with anyway.... I don't exactly get why you rule out UDK/UE4 though?

a) Maybe somebody already wrote similar systems to what might be available in Unity (be aware that I am not 100% how much the systems I have heard of in Unity really apply to your use case)

b) These Engines will offer the same possibilities to come up with your own system if you want to go the DIY route.

Also, UDK is basically legacy, You should have a look at UE4 and their subscription option. In the end, you get a more up to date engine with AFAIK better licensing options.

About your game idea and coming up with complex systems: If there is one thing certain, then it is that in the 1990's, a use case like yours would have involved the player getting close to the planet, choosing to land somehow, followed by a loading screen, and then loading the the onsurface scene.

If you really want to concentrate on the retro look, don't waste your time with a orbit-to-surface transition system. I will only look out of place, and the worst of it is, it might consume more time (at least if you have to do it yourself) than the rest of the game.

It is one of these nice to have things that make a game look really good and all, but you can waste months developing on without it having a tangible impact on gameplay. Like night/day cycles in most games. Yes, its atmospheric, but let me tell you, if you go all the way, its a ridicolous figth with realtime shadow system limitations (ugh, flickering), onesided terrain polygons, and careful tweaking of light color and strength changes over time. I know, I tried it, I got it to work, I wasted months on it. Not much of a game to show after those months, but boy, were the sunsets you could watch while doing nothing gorgeous ;)

Get your game running, work with load screens and multiple scenes, and don't worry about all the next-gen technological fringe stuff. Until you get a third party tool/plugin that does all the work for you, its not worth the waste in time.

Of course, if you MUST have it (you want to have realtime Firstperson view battles in space, in orbit, in the airspace and on the ground and everywhere inbetween (so that a fighter can escape to space with smooth transitions).... yes, it is possible to do. But think long and hard if that part of your game design is worth the technological struggle you might have to gfight to get it working.

EDIT: re-reading your question, you might have asked more WHEN to set the transition between space and surface scene, rather than opting for a smooth transition system.

I don't think the polygons will be your problem. that can be dealt with easy with an LOD system, and a sphere start to look extremly smooth even with a poly count that is rather medium by todays standarts (Several thousand tris/quads should suffice... remember, some next-gen character models are multiple 10'000 polygons, and some HD vehicle models over 100'000 polygons big).

Your bigger problem will be texture resolution. AFAIK the biggest Texture resolution possible on today GPUs is 4096x4096.... which is plenty, if the planet just fills the screen in Full HD.

Go closer to the Planet model, or go UHD, and the texture might get blurry.

So either make the transition just before your ship gets so close that the player can spot the texture getting blurry, model the highest LOD with multiple textures (not very wise, this will use a LOT of VRAM) or use some clever shader to hide the blurriness of the main texture. Look up "detail textures", they are basically doing just that.

Ah, now I start to see that you might have less of a problem with textures as I though, seeing that the game your are referencing uses almost zero textures at all. If you stick to such low poly graphics, you will also get much less struggling with polygon budgets and stuff like that.

You COULD probably get away with dynamic loading of the scene parts needed.....

lets say you have a space scene, compromised of some planets and moons with different stages of LOD... if you graphics is this low tech, you could even get away with billboards, 2 Images of planets, further away.

When you get closer to a planet, a system of your design starts to generate/load a cloud layer that the planet gets covered in, more or less to hide the next stage. bigger terrain features get procedurally generated/loaded when you close in on the cloud layer, and shortly before you land, the bigger terrain features get replaced with the final surface scene.

There are many ways to achieve that. Either fully blown streaming from disk, keeping stuff in memory and activating / setting it visible on approach, or, you could use the already integrated systems in the engine for limiting the draw distance of different objects.

Of course there are important game design decisions to make that can make this system more or less complex: if your player gets "autopiloted" to the surface, and only gets to visit a limited area on the surface, you can manually create all the different stages.

If he should be able to land anywhere, you need procedural content.

I suggest you give it a try, see how far you get and then ask again when you get stuck. Between your humble graphical requirements and all the possibilities of Unity and Unreal, I don't think you should face any technical limitation.

lets say you have a space scene, compromised of some planets and moons with different stages of LOD... if you graphics is this low tech, you could even get away with billboards, 2 Images of planets, further away.

When you get closer to a planet, a system of your design starts to generate/load a cloud layer that the planet gets covered in, more or less to hide the next stage. bigger terrain features get procedurally generated/loaded when you close in on the cloud layer, and shortly before you land, the bigger terrain features get replaced with the final surface scene.

I suggest you give it a try, see how far you get and then ask again when you get stuck. Between your humble graphical requirements and all the possibilities of Unity and Unreal, I don't think you should face any technical limitation.

Thanks again for taking the time to reply to my subject. Having worked through a stack of UDK tutorials, I scrapped that and installed Unity instead. It looks similar so I'll see how far that will take me. Luckily I only need to understand skeleton frameworks of these engines so its not like I need to understand lighting, particles etc to any great depth. I should be able to get an idea of whether Unity will do what I require (or whether I myself figure out how to use Unity as I require) in the not too distant future.

If I do manage to achieve my concept, then I can consider adding clouds and textures :-)

Thanks again for taking the time to reply to my subject. Having worked through a stack of UDK tutorials, I scrapped that and installed Unity instead. It looks similar so I'll see how far that will take me. Luckily I only need to understand skeleton frameworks of these engines so its not like I need to understand lighting, particles etc to any great depth. I should be able to get an idea of whether Unity will do what I require (or whether I myself figure out how to use Unity as I require) in the not too distant future.

If I do manage to achieve my concept, then I can consider adding clouds and textures :-)

Good choice, but really, any engine should do.

Don't give up if you hit a wall with the Editor UI though. The learning curve can be step at the beginning even for simple tasks, but given time everything will start to make sense. And as you already mentioned, most of the high-end stuff you can omit with your humble graphical goals.

As always: divide an conquer.

Cut down your project into small chunks and attack one at a time. Don't try to do too much at once.

Good luck on your journey