The Sphere. Finished?
Just a few days ago CJ and I presented The Sphere to our graphics class. For some reason I wasn’t as nervous as I tend to be when standing in front of a group of peers and strangers and saying words. Perhaps it was the fact that I got little sleep the night before and was in a strange daze, or perhaps the gum I was rapidly chewing actually did help diffuse some of my anxiety.
Our project turned out pretty much how we envisioned it, which is awesome! We were wise with our scope, and, as a result, got a nice simple little platfomer with decent gameplay and good graphics. There were some things that didn’t go so well too, but first, a video.
What went right
CJ and I were able to stay pretty tight throughout the development of The Sphere, and, because of this, we managed to get quite a bit accomplished. CJ designed the levels and did a lot of the supporting programming, while I did a majority of the engine work and messed around with gameplay mechanics.
We had a good idea and stuck with it. We would have never gotten anything done if we would have tried to do something much more complicated.
We used some tools, but we didn’t overdue it. I assert that any good 3D game simply cannot be created without some form of visual tools. CJ and I realized this from the beginning and utilized Blender 2.5 and its flexible scripting engine to allow us to get a level from Blender to Claudius in as short as time as possible. On the other hand, we didn’t overdue it and attempt to create a level builder from the ground up, which would have been too much a timesink for us to actually get something done.
What went wrong
Timecrunch. CJ and I were literally working up until the last minute on TheSphere. This resulted in there being a couple of unexpected bugs when we presented to the class. They weren’t too major, but they were disappointing nonetheless.
Object Batching. Remember this post in which I was working on object batching to improve performance? It was a mistake. I should have been looking into instancing instead (which does exactly the same thing except it is much easier to pull off, is supported directly by the hardware, and executes much faster.) For some reason the fact that Object Batching is virtually the same as instancing totally escaped me, and as a result I spent a lot of time working on custom technology that I shouldn’t have.
The .claud format. Near the end of the project I was working on a custom exporter within Blender that would export the scene into a format Claudius could more easily understand. The format was, in my eyes, superior to .obj and would have been a great asset could I have gotten it working in time. Unfortunately I had to drop it in order to get the main aspects of the game completed for the presentation. If I were to do things over I would have built the .claud format from the get-go.
Lack of different collision types. The Sphere only supports Sphere to Axis Aligned Bounding Box collision detection. That means we could have no collision with rotated boxes or angled surfaces, causing the gameplay to get stale quick. The .claud format would have provided the necessary information to compute arbitrarily rotated box collisions, but, as I never got the format finished, this remained impossible.
The Future
So there we go! The Sphere is a 100% completed project that served its purpose of getting us both an A in graphics class, right? I’m glad to say that no, it isn’t. CJ and I decided that it would be great to convert Claudius over to OpenGL and do a total rewrite of the Sphere so that it is more stable and cross platform. Besides that, it is somewhat necessary to do this conversion if we want to sell the game, else the school could potentially claim ownership due to the fact that it was created specifically for a class. Rewriting it on our own time, however, will guarantee that we fully own the project.
There are some problems we still have to iron out though. On the technical side of things, neither CJ or I have worked much in OpenGL, or spent much time on cross platform projects, so there is going to be a bit of a learning curve for both of us. We also need to get some sort of SVN server set up so we can store our code on a central database we can both access. The biggest issue I see is that CJ doesn’t have access to the internet at his home in Boondock Hills, Ohio, so that could complicate things a bit if he can’t find a way to access our SVN server. That problem aside, I’m excited to get things moving along. I can’t wait to see what this game will look like when fully realized!
Anyway, I’ll make sure to keep this blog updated with our progress, so don’t forget to come around every now and then!
bitwisegames 
Hey, I get to see the blue flames! Cool!
Thanks 🙂 I don’t know why they didn’t show up on the CD version. CJ ran his SVN copy that the CD was based on after class and everything showed up properly.
This is definitely months late for you guys but I’m sure there will be future projects.. to help work around the problem of consistent internet, you could consider using a distributed vcs like git or mercurial.
Hey jLocke 🙂
The Sphere slowed down in production over summer break (i.e. we didn’t do anything), so your suggestion isn’t really late (though my reply is, lol)
Is there any major difference between SVN, Git and Mercurial?
Fair enough, life has a way of slowing projects down. 🙂
SVN is fundamentally different than the other two. It’s based around one central server and everyone connecting to it to update, commit, branch, everything.
Git and mercurial are distributed so they’re based around the idea that there is no one central place that has everything. If I grabbed a copy of your code then worked on it for a week without having internet, then I got internet again and you grabbed the code I had worked on, the vcs would integrate what I had done in that week with what you had done in the week.
And if we happened to have worked on some of the same files, it gives you useful ways to see those differences and choose which changes you’d like to take.
Alright, so they are essentially the same concept as SVN, only distributed? Is it kind of like a peer-to-peer model, where each machine stores the changes local to that user, and they all update with each other when an internet connection is discovered, or does each machine store the entire code base for added fault tolerance?
Each machine does actually have all of the files and all of the history of those files. As a workflow, you COULD sync up the repository each time you have internet, but the vcs certainly doesn’t force that.. you could keep your clone of the project as just yours until you say, have a feature in working condition before pushing it to a web server copy.
That way you can have one copy of the code to point to as your newest working version always (you wouldn’t push code there if it wasn’t working yet). And you can have multiple people working on particular features with their own local copy.
The mercurial page that gives an overview:
http://mercurial.selenic.com/about/
Cool, thanks!