Wow, looks very interesting. Good luck in getting adequate funds!
A bit more details would have been nice, but I've already seen a bit more than the most.
ou're talking in the 'we'-form at IndieGoGo - are you refering to your multiple personalities or is there someone else (which didn't get mentioned or so)?
I may consider contributing but as a student money is mostly short...
The project sounds interesting, however the descriptions are a little bit too abstract in my opinion. It somehow reminds me of MineCraft, yet I can't really imagine how the gameplay will look or what will be the challenge and goal of the game.
You also want to provide actually everything (unlimited game modes, models, etc.). While it is good to have user-based content and leave much room for creativity, I guess it wouldn't be bad to have a somehow narrower concept in the beginning.
That's just my impression, I'm aware that there are many things to do until the project becomes ready. And I'm looking forward to hearing of more, maybe more concrete, details about FlexWorld!
Well putting out a actual gameplay video would be awesome
I'm sorry... but this sounds WAY too much like minecraft.
I'm sorry... but this sounds WAY too much like minecraft.I agree that from an external perspective (and without seeing screenshots/screencasts or being involved in the development process) it indeed sounds like another clone. But I'm quite happy to tell you it isn't. :)
Dude what the heck is wrong with you?Calm down. ;) I'm thankful for every feedback, comment or question.
Stop spaming around!
The render technique as voxels will be the same the whole gameplay will be completly diffrent, WAY more into the direction of RPG.I don't really like the word "voxels", as it implies that everything will be built of cubes, which is not the case. However FlexWorld uses a fixed grid, that's true.
Calm down. ;) I'm thankful for every feedback, comment or question.
I don't really like the word "voxels", as it implies that everything will be built of cubes, which is not the case. However FlexWorld uses a fixed grid, that's true.Okay grid it is! :D
Looks great! I like how everything is open and scriptable. Something Minecraft is still lacking ;)If I got a penny for every "Minecraft", I'd be rich already. ;)
My only complaint is the shading.There's absolutely nothing in the codebase that does any nice shading yet. The shading you see in the video is a simple fixed OpenGL light to be able to separate between geometry at all.
Also, I hope you don't mind me asking: How are you storing the voxels (on the hard drive)? Do you do any sort of compression?I'm happy to answer any questions! :) No compression yet, as it falls into the field of optimizations which are also on low priority. Of course there are a lot of ideas in that regard, e.g. using well-established compression algorithms like bz2, but nothing has been decided yet.
Do you store each chunk in its own file like ... ahem ... Minecraft (+$0.01)?Yes, as it saves HDD space for non-initialized chunks, which is even more important on the client-side where caches are stored.
Also, how long does it take to generate the chunks? Is there any special optimization you performed in order to get it to generate faster?~1/4 second for the full view cuboid. However the terrain generator is very simple at the moment (simple height map). No optimizations so far, and I think it's even no big problem if it takes a little longer as it only happens once (to recall: FW doesn't have infinite maps).
Maybe I am approaching it incorrectly, or perhaps I just never really noticed how long it takes before since Minecraft (+$0.01) generates them in another thread as you go.Can't comment on that because I don't know how you do it. :) I'm using a separate thread for preparing the geometry for the GPU, which might be the more time-consuming part (hidden-face removal etc.). The terrain is currently pre-generated, therefore I can't measure breaks during runtime. The current terrain however generates in no time. ;)
Is there a specific reason why you're not using a ready-made physics engine for the physics?eXpl0it3r basically explained the reason(s).
Also keep in mind that it is very probable that your self-written physics and graphics engine cannot compete with libraries that have been debugged and optimized over years, maybe even developped by large teams.True. Indeed I'm very sure that the physics which have been recently added to FlexWorld are not as complete as other generalized physics libraries. But the question is: What does the game need?
Even if an external library doesn't directly integrate to your project, you can encapsulate it behind your own interfaces.Yes, and the new component system will always allow to do it in the future, even quite simple. Entities have properties that indirectly define their behaviour, and controllers decide what exactly happens. Whether we use our own controllers or hack in wrappers to other libraries doesn't really matter. I really tend to keep myself the doors open. :)
Of course it may be fun to do things on your own, but especially for a project like FlexWorld that is going to grow continuously, it is wise to have a solid code base that scales with the application size. Or at least to implement physics and graphics in a modular way, so that an other framework could be employed with small effort.I played around with graphics engines in the past years a lot, especially Irrlicht (Ogre 3D always was a pain to build for me, at least in Linux). To be honest I didn't like the code design and the way of doing things. This is pure personal taste, and maybe I haven't digged deep enough to be proven otherwise, but that's what I came up with.
...Amen. This is why everybody who wants to master SFML should read through the source one day :).