What a long strange trip it has been! After 7 years, two rewrites, and more hours and bug fixes than I would like to count… Spoxel is now release on Steam. I made Spoxel in part because games like Terraria didn’t cut it for me. I wanted a game where I could design spells or make custom gear and that didn’t exist at the time. In that time I’ve gotten married, changed jobs, moved cities, and had two amazing kids. As I’ve grown so too has Spoxel. I don’t think I can point to a single part of it that hasn’t been rewritten or revamped since I started this project.
I wanted to make a big thank you to the jME community. Without this engine Spoxel wouldn’t have happened. I continue to learn a bunch from all the hard work you’ve all contributed and i’m looking forward to having some free time again so I can give back to the community!
Yeah… they have 10 devs and 8 years of development on me haha. I have a little niche that I hopefully can carve out. I don’t have really high expectations with how the market is… even with the good press we’ve gotten.
In the early years of Mythruna, I got a ton of traffic on my servers from folks who saw a post somewhere about “How this was going to beat Minecraft…” etc… posted by one of the early (and very young) users, I guess.
Granted, a large portion of that traffic was griefers and haters, etc… but there were also folks who stayed.
I’m not saying someone should do that on purpose for “marketing”. I mean, I am saying that as a joke… or at least that was the joke. But for those who maybe have a smaller conscience, it can be an effective marketing strategy.
I’m currently using a copy of master from back in November with a handful of customization’s I’ve made. I use LWJGL3 at the moment although it has given me a ton of headaches on osx. Spoxel has come together over the last 7 years so a bunch of the libraries didn’t really exist when I started. The custom modifications i’ve made to jME include:
Extended the advanced profiler to basically use a varadic string input. This combined with some code changes for when app states are updated allows me to see which app states are causing lag as well as setup additional control points.
There is some weirdness with intel graphics cards on osx with high dpi displays and returning bad data. I’ve added some dirty code to allow me to scale the mouse input and nifty gui size to account for that.
I modified nifty gui to remove the memory leak problem I had found. I don’t use the functionality I disabled so it works for me and drastically reduced time spent when updating nifty components.
I’ve also made extensive use of spidermonkey and written a “Steam” server based on the spidermonkey code. The steam code is one of the Spoxel components I want to break off into a stand alone lib that people can use with jme.
Nifty was the only gui library that existed when I first started working on Spoxel so that’s what i’ve stuck with. The batching has been huge for rendering speed… especially on lower end systems. One of the project’s i’m toying around with is rewriting parts of nifty but i’m not sure if I want to invest that kind of time or start working with lemur since that has better engine support.
During one of my rewrites I moved to use an entity system that was in part based on concepts from zay-es but I wrote it before zay-es was really released. My version allowed by bi-directional modification along with the ability to access all components from sets. In retrospect… the bi-directional modifications was a bad idea but the component access has been nice even though it breaks some of the rules. I would probably use zay-es if I was making that decision today. I went a little crazy breaking things into components.
I also use a custom particle system based on the early code tonegod released. I’ve added code to allow for particle beams as well as the ability to allow gradients for certain particle attributes for better animation control.
The profiler enhancement is one of those that I plan on making a pull request for.
The nifty memory leak is caused because every time you create any elements in nifty it registers the name of their styles in a map along with the element and never free’s them. Then whenever you add any items it ends up iterating through those lists. So you add any sort of complicated gui elements and it gets worse and worse. I had a lot of reports about the game becoming unplayable after an hour or so and it was caused by that memory leak. That map is used to basically notify any elements that a style has changed if you update a style during runtime. That feature isn’t used at all by nifty but theoretically someone that uses nifty could make use of it so it can’t just be removed outright. I just removed that from my copy of nifty for Spoxel since it was also a cpu hog.
The practical experience has been great. I’ve learned a lot. I mean MOST of the time i’ve spent on Spoxel was probably learning what NOT to do haha. Now though I have a much better idea of what needs improvement in jME that would have helped me in development that I could give back to the community.