Hi, I am 22 years old, come from Austria (pref. language is German, English) and always dreamed of making this kind of game.

In general I am searching for someone with some gamedevelopment experience, to take care of the General programming and scripting site of the game, who is open for a collaboration with me ?

Unfortunately i have basically no gamedevelopment experience and also dont know how to code.

Although i will take care on modeling all 3D models needed, as well as sound design and everything object related!

The Game:

The Game itself should be a voxelbased, openworld RPG, with a Playerlevelsystem, Craftingsystem and procedual and infinit worldgeneration, although I am always open for minor concept changes, in case its needed on the coding side.

I already started with modeling a bunch of basic objects (as seen in the pictures) and work everyday on expanding the viarety. The style will be very similar to the Game “Cubeworld” ,but with many major deviations in the gameconcept and overal just a much better game in therms of the visuals and animations and also the overal aim of the game :D

I am making the models in MagicaVoxel in case needed.

Everything further can be discussed personaly ?

I hope someone is open for this kind of challange and wants to follow my inspiration and hype on this concept together with me and wants to make this idea into an epic new Game!

I'm currently working on a procedural generated, voxel based game. However, I think it's somewhat different from what you have in mind. I'm using smooth voxel algorithms, and the world is not not infinite. However it is vary larger as I'm supporting entire planets and it has resizable chunking so it supports full space to surface transitions.

It is a true procedural game since it generates terrain and refines it at runtime as a player moves around, instead of generating it and storing it on disk to be used later.

@Gnollrunner
Sounds very ambitious.. So my understanding is that the general worldsize is defined but procedual generated and it only loads in when you come closer to the next chunk am i right?
Its kinda the same concept, but originaly i thought i try to find someone who is interested in helping me and a friend (IT-technist) out, producing the procedual worldgen for our idea.
He already has the random chunkgeneration done in unity, but the problem i see is that we both have basicaly no gamedevelopment experience and dont even know if unity is the best engine for this sort of game.

Also its running smooth till the next chunk loads in then its very laggy and we dont really know how to fix this to support a game with quite a nice viewdistance…

Although i am very interested in what game u are currently working on, the planetconcept sounds very interesting!

Are u using MergingCubes for the worldgen?

Grimmlok said:

@Gnollrunner
Sounds very ambitious.. So my understanding is that the general worldsize is defined but procedual generated and it only loads in when you come closer to the next chunk am i right?

Not exactly. The whole thing is built on an octree, or rather 20 of them one for each face of an icosahedron. I'm actually using prism shaped voxels so that they always point the same direction in relation to the planet's surface and they are reasonably even across the surface. I will also support normal cube voxels later for buildings and stuff.

The whole planet is always in memory but there are bands of progressively larger voxels as you move away from the player (i.e. this is how I do LOD). So if you zoom all they way out you will see the whole planet at lower resolution. A “chunk” is nothing more than a marked node in the octree and everything under it. Chunks have a depth based on their distance from the player. They also combine and split as the player moves around. This is to keep the number of voxels in a a chunk roughly the same. Otherwise a chunk would be so small when zoomed out, that it only contained 1 voxel and you would end up with thousands of chunks.

One chunk can only have 1 level difference from an adjacent chunk and there is a tessellation algorithm for border voxels in a chunk that does a smooth transition. Each chunk generates 2 meshes: a center mesh and a border mesh using a marching algorithm. This is so when a neighboring chunk gets split, merged or changes depth, you only have to recalculate and send down the border mesh to the CPU and not the whole chunk.

For physics I build a separate tree that just generates (and destroys) voxels right around a player. This is done so any possible lag in the visuals doesn't effect the physics.

For pathing I plan to do something similar to the physics tree sever side (i.e. Juist In Time voxels). Even though my voxels are in an octree they still have adjacently information (this was a bit tricky to implement) so this should let me do reasonably fast pathing.

Are u using MergingCubes for the worldgen?

I think you may mean Marching cubes right? … Yes …. sort of, but it's more like marching prisms at this point and there are a lot of extra features in it. Later I should be able to support sharp corners for buildings since I can store normals at voxel edge intersections. Also there are a lot of details I'm leaving out that I had to do in order to make it fast.

Sounds very ambitious..

Yes it's a lot of code to do all this and I haven't really done much shading yet. However most of the work is done on the CPU so I still have all the computing power of the GPU for fancy graphics when I get to that.

@Gnollrunner

Ok wow how long did u already work on the whole thing if I may ask?

So did you do the modeling and designing and all that stuff all by your self or yave u got a team or smthg?

I'm not exactly sure of the time it took because I worked off and on for some years and also I took some code from one of my older projects. Now I'm working pretty solidly on it, at lest half a day each day, but the thing is I'm not using a game engine mainly because everything is in 64 bit coordinates to handle the size, and most of the algorithms and data structures are original. So that makes things harder. There are hacks some people do to handle the large scale using an off the shelf engine, but it makes some things more complex in the long run. Everything down the to actual heap and pointers are custom. I've probably thrown out as much or more code than I've kept.

Of course if I had to do it again I could do it way faster because I know what works and what doesn't. There's a lot of performance things you have to watch out for and there are probably still things I could do to speed it up, but it's pretty good now and I'm working on an older computer and graphics card so I should get some performance boost when I update my machine.

So did you do the modeling and designing and all that stuff all by your self or yave u got a team or smthg?

Team? What's that? :D I can never find anyone crazy enough to work with me on this stuff. I've tried a few times. I'm hoping when I get some impressive graphics going that will change. However one thing I've noticed is that some folks that do world generators can generate cool looking stuff quite quickly, but seem to get bogged down in the physics and pathing later. I remember reading somewhere pathing was an issue for EverQuest Next which got canceled.

Also some systems aren't true procedural generation in my book. Terrain is generated procedurally but then stored on disk and loaded and discarded normally. The issue with this is that is it severely limits the size of your worlds, because there is no way you are going to store that much data on a client. Infinite worlds are of course procedurally generated. Oddly enough it's easier to make something infinite, especially on flat terrain then it is to do a spherical planet. As long as you stay close to the ground you can use fixed size chunks and use normal LOD solutions. Infinite, or near infinite LOD that you need for a planet is a harder problem and if you are using voxels and not height mapped terrain it's an order of magnitude harder.

I try to always keep in mind that I'm working on a game and not just a world generator. So at this point I've been putting more effort into the core routines to make sure everything is possible. For my kind of game the world needs to be more than just a pretty picture.

@Gnollrunner

Ah ok so u kept working on it for several years now..
U think u could extract a early alpha or smthg to show it to me..? I would feel honored to see what u already achieved in the worldgen.
And all in all Your future game reminds me a bit on no mans sky in terms of the planet concept and the refinement of the chunks the closer u come..

But its also kinda similar to what we are onto, because in order to support a great viewdistance we also have to figure out to make the same mechanic. So we dont have to simply blur the landscape farther away with some ugly fog or thmthg.

Grimmlok said:
But its also kinda similar to what we are onto, because in order to support a great viewdistance we also have to figure out to make the same mechanic. So we dont have to simply blur the landscape farther away with some ugly fog or thmthg.

The difference is: He uses a LOD system which reduces geometric detail in the distance. In contrast, games like Minecraft do not use LOD. They get around it by using low res geometry. So up close it's blocky, and at some distance you must just clip it so it does not get too much. Fog is a good way to hide this clipping. Example for a voxel engine with LOD would be Atomontage, example for a pretty high detail voxel engine without it would be Teardown (at least i did not spot any LOD usage here).

You want to think about LOD yes or now early. If you need it, you also need a very good programmer. It is a hard problem to solve, requiring lots of the time to implement, with chances only a fraction of research finally turns out useful for given requirements.
In short: You don't want to need it. Or do you think you really do?

Saying this assuming you target some blocky voxel artstyle also for the world; this is your first game; and you do not want to extend given functionality of U engines so much.

Viel Glueck aus dem Laendle :D

JoeJ said:

… In contrast, games like Minecraft do not use LOD. They get around it by using low res geometry.

What is lower res geometry if not LOD? Regardless of how it's achieved, it's LOD to lower detail in the distance, won't you agree?

@JoeJ

Is LOD not just the short form of Level of Detail? or is it a sort of own technique in programming i really dont know much about that sry.. But in my ears these two ways sound very similar as u discribe LOD as reducing details in distance and the other way simply merging smaller “cubes” into bigger and bigger one the more far away u go.. because the socond one is the way we wana go in our game but we still have to figure stuff out and as the person who dont know how to code in general i am already speaking big words ':D

As u said its our first game in general and other than me in modeling and my friend in programming the worldgen, we have still a far way to go to even make it playable but lucky us there is the internet to research stuff.
Its still very challanging so i hoped to find some people here to help us in the general gamemaking aspekt of the game so we dont have to figure out all on our own.