Voxel game project: Rituals of the old

I don’t know about blender, but in jme you can set a min- and magfilter on textures to prevent these sort of artefacts.

Also, those jeans need some seams, pockets and creases in the texture. Looks very plain atm.

1 Like

All right, thanks!

And yeah, you’re right. The clothes are not finished yet. It’s missing all decorations.

1 Like

Remember when I was talking about open sourcing our voxel engine, Terra, last summer?

Development has been going forward steadily ever since and we’re getting closer to a point where it might make sense releasing it.

I was talking with our lead coder today about the subject. We are probably going to do more than just release Terra as open source. It’s possible that we might open source everything which is of sufficient general nature and potentially beneficial to the community.

What we wish to do is essentially:

  • Retain rights to everything that deals specifically with the game we’re making (graphical assets, models, sounds, game logic, AI, etc.)
  • Retain rights to everything which might bite us in the ass if we release it (hackers, assholes, other game studios making subtle changes and repackaging, etc).
  • Release everything generic enough to be useful to others while not being harmful to our goals.

At the moment this would include at least the networking code and the voxel engine. I don’t know about the rest - we’ll get back to it once we cross that bridge.

AFAIK there aren’t that many good open source Java voxel engines out there. Games, sure, but engines as libraries? Not so much. So I assume there might be some interest in this.

But just a quick update. We probably need some months more before we’re ready to release anything.

I’ll get back to you.

7 Likes

Let me know when you do this. :slight_smile:

I would really like to see how your voxel engine works.

Sure thing, we will.

We are currently working on implementing networking (UDP). It seems like it will still take a while but we’ve made progress. Some of the problematic server side stuff is done and we’re now fiddling with client side stuff.

After that is wrapped up and done we can implement a quick world generator and begin testing and optimizing the voxel engine. Among other things we will still need to implement greedy meshing. That should ramp up the performance a notch.

At it’s current stage with all the optimizations missing Terra, our voxel engine, is not yet quite good enough for proper use.

Maybe this could save you a bunch of time:

Robust UDP networking library, ready to go.

Demo app: (without ES integration)

Demo app: (with ES integration)

3 Likes

Very interesting. I’ll be sure to forward that to our lead coder. Thanks, Paul.

I wrote it for Mythruna and then open sourced it… so it’s even got a similar target game originally in mind.

Someone else is using it for their space game and handles thousands of users. So I guess it’s pretty robust already.

My game is based on that ES based examples and it saved my months I would say. And it just works including a chat example. Very nice really.

1 Like

I prefer to use java.NIO.2 and tcp :slight_smile:
https://github.com/JavaSaBr/RLib/blob/master/src/test/java/com/ss/rlib/test/network/NetworkTests.java

Lineage 2 and Tera Online use tcp protocol :wink:

TCP is not really an option for us. But it certainly would save a lot of trouble.

I think what we’re going to do is go forward with the Netty implementation and take some influences and tips from pspeed’s library which seems very well designed.

Are you going to share each frame between client and server?

TCP is a stream-based protocol. If something takes a bit longer to be transmitted, everything sent after it is delayed. This would be observed by players as mobs and players stopping and after a few seconds, teleporting to new positions at once.

SimEthereal implements a reliable UDP protocol… so it’s kind of the best of both worlds. And you don’t have to worry so much about the “how”. You set it up, give it positions on the server, your clients will see those positions… and it can pack a LOT of object data into one 1500 byte UDP message. It’s already optimized to try to fit a single message into a standard MTU to avoid splitting, etc…

You can hand-roll your own, of course… and learn all of the same lessons it took me 20+ years to learn. :slight_smile:

1 Like

That’s the great thing about humanity that we’re never alone. We have the collective wisdom of all those who came before us within our grasp. Building on the shoulders of giants and all that. As single human being most of us don’t amount to much, but together our ingenuity is simply amazing.

We’re not trying to reinvent the wheel. But Spidermonkey was not a very good fit for us. We tried it and and weren’t really happy with it. But there was a lot of great stuff in SimEthereal. We’re going to do a Netty implementation using the best practices and I’m sure the tips and tricks from SimEthereal will be a great help with that.

:+1:

Yep, the key word is LATENCY and UDP is much faster for its just PUSH vs, did it get there with the proper checksum.

I can see TCP in a SMALL environ but @pspeed is spot on with the UDP side and the metrics, good homework!

1 Like

it’s still too much, for example in Tera-Online we have event-based tcp network, without sending all frames and it takes a little bit network traffic.

LOL, the protocol garbage of TCP guarantees you are at least sending three times the data SimEthereal does… but whatever.

Some games can get away with a 2 second pause every now and then and that’s fine to use TCP in that case. I guess your game is probably not server-authoritative-real-time in any way. So TCP may make sense in that case.

1 Like

I don’t talk about my game, I talk about some MMO games like this: