The next incremental version of Worldbuilder is now out. No huge changes to planet generation itself, but the user interface has received some significant improvements in terms of usability. Some of this stuff is really standard, and sort of feel bad that it wasn’t already in early versions, so I apologize that it took this long to become available. But the program continues to get polished up, a little here, a little there, so I hope your experience will keep getting better.
As always, a demo is available for download, and the full product can be purchased from the store page. (Once purchased, you’ll continue to have free access to future updates.) If you have already purchased Worldbuilder, the downloads can be found here. (more…)
A user alerted me of a bug with the tectonic plate visualization layer, in which ugly black stripes were showing up. Upon inspection, it turns out that it was due to some angle values becoming excessively large, but only on some maps and not others. Clamping them to a maximum reasonable value got rid of the black stripes.
The fix has been uploaded and is available in version 0.2.1, available now.
So I had a few errors in my initial v0.2.0 packages. I have corrected these and uploaded the new files. Sorry for any inconvenience!
The first problem was that I embarrassingly left in some debug code that was trying to save image files to a hard-coded path on my local system. Oops.
The second was that I thought I had included all the necessary files for the new Visual Studio 2015 runtime library. Apparently not, and apparently it’s best to just use the redistributable installer from Microsoft. But until I get a proper installer created for Worldbuilder, it’s more convenient for users to not have to go through that process. So I returned to Visual Studio 2013 for this release.
Today brings a new version of Worldbuilder! The primary focus has been on the presentation of the planets. Much work has gone into getting away from being limited by a low-resolution triangle mesh during rendering, and instead doing far more on a per-pixel level. It has also made it significantly easier to add lighting and to handle a wider variety of map projections.
A demo is available for download, and the full product can be purchased from the store page. (Once purchased, you’ll continue to have free access to future updates.) If you have already purchased Worldbuilder, the downloads can be found here. (more…)
In an attempt to make the OpenGL support more robust, I offer you Worldbuilder Version 0.1.2. In particular, prior versions implicitly required OpenGL 4.1 or higher, and if that version was not available, would mysteriously fail to to run, render, or in the worst case crash. Worldbuilder now only requires OpenGL 3.0, and it ought to fail more gracefully and with improved error reporting when that or other miscellaneous requirements are not met.
Pixel format requirements have also been loosened so that the program should still work even in the absence of certain nice-to-have features such as multisampling, or can work with color/depth/stencil buffer combinations of a few different bit sizes, instead of requiring exactly 32, 24, and 8 bits for each.
As a small bonus, saving a view to an image file will now attempt to use multisampling if available, reducing the need to save to a larger image and then downsample manually in order to get antialiasing.
If you already own Worldbuilder, you can head over to the product page now to download the new version. If not, you may download the demo to get a feel for the program’s current capabilities (and validate that it functions well on your system). Then head over to the store if you would like to pick it up at the early support discount price.
Improved OpenGL initialization to be more robust and flexible.
Enhanced OpenGL-related error detection and reporting.
Required OpenGL version reduced from 4.1 to 3.0, and is now explicitly checked instead of resulting in a crash.
Save to Image will now use multisampling if that option is available.
Lua module suites updated to no longer use UInt32 instances as loop counters, as that turned out to be useless and in rare cases unstable.
The first follow-up version of Worldbuilder is released, Version 0.1.1! This is admittedly a minor version, but comes with some very nice usability improvements, a few new features, and better error detection and messaging, as well as some miscellaneous bug fixes. (Click here to purchase. There is also a demo available. If you have already purchased it, you may proceed to the download page.) (more…)
Today I back-ported some of my flat map code from Worldbuilder to the planet generator prototype that I made last year. So for anyone who has been wanting to view a flat map rendition of those really cool planets, but isn’t ready to spend $4 on my Worldbuilder early supporter discount offer, you can give the new version of the old prototype a spin. No procedural generation code was altered, so seeds from the original version will work in this one, generating the same planets as before.
I apologize for being quiet for so long. I’ve been working hard on my Worldbuilder random planet generator, as well as preparing my website for Worldbuilder’s eventual release. Today that release has finally arrived, and Worldbuilder is now available for purchase from the Experilous Store!
It’s a long ways off from what I envision it could become, but it’s already got a lot of potential value. If you are an author of speculative fiction, a map enthusiast, or a programmer interested in procedural generation, read on to find out what Worldbuilder is already capable of, and where I hope to go with it in the future. Or grab the free demo here and try it out yourself. (more…)
It took me three weeks of design, redesign, more redesign, lots of implementing scattered within, and three intense days of debugging a giant mass of previously untested code, but I finally have a basic modular system in place for running all procedural generation from Lua. This will enable me (and eventually anyone else) to quickly experiment with various algorithms for every stage of planet creation and presentation.
Unfortunately, I have a lot of optimizing investigations to do, because it seems to be running about 100 times slower than the prior C++ code. But at least it generates the exact same planet (give or take a few subtle discrepancies due to slightly different math here and there). Based on some of my earlier experiments at the beginning of the month, I’m pretty sure I can bring that up to within at least 10% of the speed of my C++ implementation, and quite possibly within 50% of its speed. Just need to profile and figure out the bottlenecks. (Edit: A day’s worth of investigation has gotten me up to around 13%, or 7.5 times slower than the C++ implementation. That should be acceptable for the moment.)
A cool thing about the architecture I ended up with is that not only will it naturally support a rich modularity of hooking up algorithms at different stages to each other, but that the way this modularity is exposed will also automatically enable a significant degree of concurrent execution on multiple cores with little to no effort on the part of the script writer. Right now I have only implemented a single threaded execution model, but I should be able to change these details under the hood when I get to that stage in the project, and the Lua scripts won’t know the difference. If you’re curious, allow me to provide an overview of how I’ve designed this modularity and concurrency. (more…)
Our Ludum Dare 31 entry is finally complete! For some loose definition of complete, anyway. It’s submitted and can poked and prodded, at the very least. Changes since the prior version were minor; I handled the game over state, added a little bit of variation to the pitch to visually indicate if it’s likely to be a ball or strike, included more animations for the runners to take them from 2nd to 3rd to home, and did some minor bug fixing. Haven’t yet discovered what rockets the ball into the sky every once in a while after hitting the back wall. Oh well, someone might find it amusing.
Two more iterations today. Number seven added runners that actually run one base at a time, as well as foul balls and textual announcements of pertinent events. Number eight added regions to the play field that determine the type of play depending upon where the ball comes to rest.
I also have an amazing bug where the ball occasionally flies off into the stratosphere whenever it bounces off of the back wall, or otherwise magically teleports to a different spot on the field. I don’t think my code or my math could survive another day of game jamming. Good thing it’s over soon!
For my sixth iteration, I have added a short wind up animation for the invisible pitcher, to give the player a small heads up that the pitch is happening. I’ve also thrown in some occasionally buggy code to cause the ball to actually bounce off of the back wall, which happens to be infinitely high, despite appearances to the contrary. Sorry, no home runs.
Something is starting to come together, although that “something” is yet to be a game exactly. My fifth published iteration now has score keeping, bouncing balls, a pitching/swinging mechanic, and a wall at the end of the outfield (which magically doesn’t stop balls). It works again on mobile too, though the touch event lag that most browsers introduce causes a serious amount of annoyance when batting.
Beginning to get some mechanics in, though I don’t like the feel of them yet. The third prototype introduced new base runner sprites from Jeremy, a “Bat” button, and a non-functional ability to specify which area of the field you wish to target for batting. The fourth prototype made the batting target functional, and added some priority options for batting: chance to hit the ball at all, the power of the hit, and the precision with which it is hit. In the background, strikes, balls, outs, and innings are being tracked, but not the score. And I seem to have broken the mobile touch interface; it will come back in a future version. (more…)
Out of control elliptical base runners. Who needs rules?
Last night’s brainstorm resulted in very little that was inspiring. “Entire game on one screen” wasn’t exactly a creatively compelling theme. But Jeremy and I chose to go with a baseball-esque theme, with no scrolling of the ball field or extra panels for information. I was hoping I’d be able to come up with some abstraction and modification of baseball mechanics that still retained a core element of fun, but my design efforts didn’t result in many promising thoughts. Before I went to bed, however, I insisted I throw together a tech demo of the ball/shadow graphics that Jeremy recommended. You can view that in my first prototype (just click, touch, or press spacebar to launch baseballs with random trajectories).
In order to give Jeremy something solid to work with for creating some sprites for the players, I added a diamond and some blue elliptical base runners, and subtly improved the size and shadowing of the balls. You can see that in the second prototype.
Now it’s time to actually add some legitimate game mechanics, while Jeremy works on sprites.
Only three hours remaining until the theme for Ludum Dare 31 is announced. I’m gonna have a go at it again, preferably with far more success than Ludum Dare 30. I’ve been in a rather good mental state this past week, and am well rested, so I’m optimistic. And the possibility that the Unicode Snowman will be the chosen theme doesn’t scare me. Not that I have any idea for what I’d make for that theme or any other. I’m fully in the just-wing-it mode of thinking for this one. We’ll see how that goes.
I’m assisted this time by Jeremy Breau of Antithesis Design. The media assets he’ll be creating will no doubt be far better than any weak vector art I would throw together, and having a partner with whom to share the design efforts is always rad.
Meanwhile, the very encouraging interest from Hacker News and reddit this past week, along with a very insightful business suggestion from a friend, has me reconsidering my plans regarding my planet generator. (more…)