Thanks to everyone who commented last week. Between comments and poll results, I had a lot to think about.
Some people think I've lost my way on this project. I have to admit, rereading the entire series of parts last week, that portability and performance were a very long detour. And I have added some new goals. A big risk for me is that I just won't be able to finish anything, making this all a waste. By adding goals like cleaning up my multi-platform framework, and my "cube-world game framework" (Crafty) I'm cutting that risk. Now, without too much more work on my part, there are three ways the project can succeed, not just one.
The multi-platform support was arguably a mistake, since it has taken a lot of time and caused me a lot of frustration. I got into that because people made the argument that with OpenGL, I could support multiple platforms "almost for free". The argument was also made that Linux users were more open to testing demos and playing with source code. That seems to be true. Linux browsers are 12% of my readers, but more like 30% of downloaders. That's not counting the number who pull the source from GitHub and recompile the demos.
In any case, the Linux port has actually been more or less trouble free. The Mac port has been the hardest. I've continued with the Mac because I want to do something with the iPad. And I want to do that because tablets are clearly the trend these days. Even my very techie brother-in-law has no desktop computers, only laptops. I'm reading more and more people saying "oh, I just use a tablet to read the net and play casual games." I could definitely see the average user giving up on laptops, due to ease of use. And there's no doubt the iPad is a nice piece of hardware and can do a lot of useful stuff. So it's not impossible that the future is whatever will run in a handheld device.
I haven't changed the ultimate goal of the project. I still want to do an MMO with real development tools in world. I want to create an environment that can be extended radically by the users. Frankly, I don't see any other way for an indie MMO to survive. I don't have the art skills or the time it takes to keep providing new material for a community. Either it grows by itself or it dies for lack of interest.
A lot of you are looking for game ideas and talk about game development. Inevitably, we'll get to that. For now, I'm more concerned with building a base and providing tools. That comes from the overall goals of the project. If the tools aren't good enough, it won't grow by itself.
However, I can't complain about lack of downloads of the demo when I neglect to produce any kind of playable demo. So I'm going to try and get both Crafty and SeaOfMemes playable in some basic form, then add framework and features. It's going to be challenge, since my inclination is just to put off game features until there's a solid infrastructure for implementing them.
I'm also redesigning the site a bit. I want the home page to emphasize the demos and encourage people to download them. If I keep this purely technical, I think I'm going to see a continued slide in readership. The whole point of doing this blog was to get feedback, so keeping the number of readers stable is important to me.
Please look at these and give me a quick opinion.
Cube World Horizon
I also did an experiment this week. In SeaOfMemes, the world will be polygonal and only buildings will be made from cubes. In Crafty, the whole world is cubes. Looking at the demo I have now, I wondered what it would look like if I added the landscape code. I would generate nearby terrain as cubes, and distant terrain as polygons. It looks like Figure 1.
This version of the demo basically works, but it takes my code a long time to generate a chunk of scenery as cubes. In the video below, you can see cracks appear in the scenery. This is because I'm moving very fast, which creates a lot of new chunks to be rebuilt. Building the 32 by 32 by 32 blocks of cubes takes longer than the polygonal landscape I generated in Part 28.
I also don't have water working correctly. The edges between blocks are all set opaque and there's a lot of z-fighting as a result. In the video, water is turned off.
I also tried making the entire landscape out of cubes. At a distance, I would just use larger cubes, the way I currently use coarser sampling of the procedural landscape. The result is Figure 2:
I would show you a video of this, but the cube version is unusable. It's very obvious when you approach a region and it is subdivided and the resolution doubles. Plus, the code currently must delete an old region then and rebuild it at higher resolution. While it is doing that, the polygonal landscape is shown (I have to show something, or there would be a black hole.) So in that version of the demo, the scenery is constantly flickering between cubes and polygons and different resolutions. Not usable yet!
There's no demo this week, since this code is not stable. I'll keep playing with it.
Finally, I've fixed a long-standing problem with the framework. I had been relying on the user to set the graphics platform used by the demo. In the options, you had to specify "OpenGL3.3" or "OpenGL2.1". This results in confusion and demos that don't run when users don't have the latest drivers. For a long time, I've wanted the framework to test and see what's available, then use it.
You would think this would be trivial, but it wasn't. The framework initialization was a bit tangled by trying to support multiple platforms. It fired up the base level of OpenGL or DirectX, then had to start the application to get options like window position, then created the window, then continued with trying to initialize a drawing context in OpenGL. Only when you create a drawing context can you find out if, for example, a hardware accelerated version of OpenGL 3.3 is really available.
So trying one initialization after another would have meant killing the failed graphics context, tearing down the window, closing the app, and then restarting everything again. Ick.
I've managed to get it all cleaned up, although there's still a bit of missing code. In the demos, you won't notice that. The platform can now be left blank and it will find the right one.
On the Mac, it should find OpenGL 3.2 if you are running Lion and your machine is supported (has one of the graphics chips listed on this page.) If you are one of those rare people, the next demo should look slightly better on your machine than the OpenGL 2.1 demos.
blog comments powered by Disqus