GM here,

I've been busy and promising evidence of my work for some time now. Supposedly I was going to show some video and screenshots for several weeks.

No more waiting I am presenting my procedural terrain engine.

It uses the incredible PolyVox library (http://www.volumesoffun.com) to store voxel information and several types of fractal noise to generate lowlands, highlands, mountains, and caves.

It has been a fun learning experience. I got to experience the frustrating recursive principal of shaders (you have to know how to do shaders before you can learn how to do shaders) I also got to play around with paging and set up a mesh pager in Ogre. I also got to play around with Voxels. They are the hot thing right now and I hope they get more popular.

On that note this project is being shared open source on Google Code.

Check it out at (http://code.google.com/p/senior-project-voxel-terrain-generation/)

Still figuring out the exact license I want to use, but I don't care if people want to use it or make money off of it. Later I might change that but for now dig in and surely you can make it better.

Also on another exciting note. I AM GRADUATING THIS WINTER! WOOT! Just had to get that out. I'm so excited to be done with school. Maybe I'll change my mind after working for a while. We shall see.

Pictures after the jump!

So I came across this game a few months back and thought I ought to share it. It is, in my opinion, a prime example of good design and innovation in a puzzle game. sadly I haven't seen much out there that has impressed me lately, this game being the exception.

Hallo All's!!
I am pleased to announce that we are now looking for an artist. Yah we finally decided we were getting really sick of looking at ugly 'place-holder' graphics. so we are calling out to all artists that may be interested.

The announcement will also go throughout the art department here at school as well. So we expect to receive some applications. We have also found out that we may be able to count this as an internship for the art student that we 'hire.'
I put hire in quotes because we dont actually have money to pay anyone so if money ends up being involved it wont be promised, and it wont be until the game makes money.

If you are someone who would be interested in filling our artist position for this game, go to our website and apply using the contact form. What website you say? well let me tell you...

I have just finished putting the final changes on a legit website for our company. (We are awesome) If you would like to go take a look, please do. it contains a description of our current game project, and a contact form where you can get a hold of us or apply for the art position. or just throw insults at us. whatever floats your boat.

Heres a link: http://www.novaboxgames.com

And last but not least, an actual project update:
We have come to our senses and started developing a serious storyline for this game. It occurred to us that it might behoove us to have an engaging single player campaign on release. (no duh) so we have started story writing and listing the various arts we will need. And heres the really interesting part:

We have set a goal to have the game released by end of Quarter one 2012. To this end, I have been working my butt off the last two weeks to try to get this game playable. At one point I had the networking down and working but it was brought to my attention that the networking architecture I had implemented may not be sufficient for multiplayer over the internet.

When we first started this project we did it with a fun game to play at LAN parties in mind. It has grown quite a bit since then, in many ways. but we still feel it is achievable. Part of that growth was that we wanted to make this game available to a wide audience and as part of that we wanted to allow for an online multiplayer aspect.

So when I found out we needed A different architecture for the networking I let out a sigh and rewrote the thing from scratch. We are now using a design that should allow for smooth networking over the internet. Testing is still underway but progress is being made. I hope to have the game playable by the end of the thanksgiving break. (Unfortunately, Skyrim caused a bit of an...unfocused period...but I seem to have got a handle on that addiction :P)

I will be talking about the process I went through in deciding on a networking structure in the next blog post.

Until then, don't die. just think of all the fun you would miss out on.

You have heard the rumors, You have waited on baited breath, and now, you FINALLY get to see some kind of actual progress. Something more than just words...
Ok im done trying to be dramatic. Anyway here it is.

http://www.novaboxgames.com/temp

This is a prototype for the game that I wrote using javascript. its just an example of the major gameplay feature that we are planning.

Move around with AWSD, target with the mouse, attach modules by pressing E and detach them using Q. Sorry it doesn't have enemies or actually shoot. but it does calculate the speed based upon the total mass of the ship and all attached modules. Modules also store their own angle which will allow them to shoot at whatever angle they are attached. this will allow the player to have guns attached that shoot behind the ship as well as front and sides.

THIS IS NOT A FINISHED GAME. its not even a game. its a proof of concept, view it as such. If you happen to have any suggestions or ideas. feel free to post a comment.

So you might be wondering if you are reading this blog where the videos I promised are.

Well I decided to implement a small seemingly insignificant feature to make the video look better. This ended up breaking the entire code base, and I just barely fixed the problems I created.

It came down to threading issues between Ogre and OpenGL.

It turns out Ogre is not thread safe (should have seen it coming) and OpenGL is even less thread safe. OpenGL is a state based language. It has one state where rendering can take place and another where objects can be created.

When creating a manualObject in Ogre. One must call the end() method to signal the completion of the manualObject. This call makes several rendering calls in order to place the created mesh into the Ogre rendering Pipeline.

Unfortunately this means if you try and make a second thread which creates your manualObjects, then the end() call could be made in the middle of the main thread's OpenGL rendering sequence. As you can't start the same state twice in OpenGL this causes a nasty exception and a crash of the engine.

There are some ways to get around this but it requires some crazy synchronization of GL state sharing. Trust me it gets nasty.

I decided to take the easier way out. I synchronized all rendering operations on the main thread. The second thread creates the manualObjects but does not call end(). It then passes the objects to the main thread which calls end() and loads them into the rendering pipeline. This fixed all my errors with threading and OpenGL. I have some optimization issues I need to address, but that can wait until a later time.

Now I am working on terrain generation and preparing some videos to show my work. I also might walk through some of my code once I clean it up a bit.

In other news Corndog has been hard at work and prepared some prototypes of our asteroids clone. (The title is still being discussed. He should be posting some links to the javascript prototype he created soon.