Developing the Cosmic Engine

Google Code Update

2009-12-14T15:06:00.000-08:00

We have updated the code base on Google Code, the update includes the Avatar System Developer Tool that we use internally - starting with our next update we will post fixes to known art asset issues. The tool is used by the artists to verify assets before passing it along for integration, it is possible to load meshes and animations on run time for a smooth work flow.

We have started a documentation effort using the wiki on Google Code, it is possible to post comments on the wiki pages, let us know what you think!

A new forum for the CosmicEngine is up and running at http://groups.google.com/group/cosmicenginegroup

please feel free to post your questions and comments, we monitor this forum regularly.

Work has begun on the Cosmic Object Model! We will document on the wiki as this matures. We hope to use this model to ease the work on "Game Objects", separate the business logic from the reusable components and even make networking easier - stay tuned!

Cosmic Engine is posted!

2009-11-06T17:49:00.000-08:00

I am proud to announce the entire Cosmic Engine code base is now up in SVN on the Google Code Cosmic engine site. The link again is:

cosmic-engine - Project Hosting on Google Code

Of course, it's not exactly user (or even developer friendly) but it's an important milestone. Docs and tutorials as well as regular development updates will now happen there and as open source!

It's been a long time coming. I hope we can grow a great community around this tech stack.

Hoo-ray!

This sprint I promise!

2009-11-03T18:46:00.000-08:00

Delays, delays.

So we didn't make the release by last Friday as planned, but I promise, if I have to hand carry each bit, we'll push it all up during this mini-sprint.

We had an entire office move right ontop of this sprint, literally the move was the same day of the sprint closing and this got cut.

Google Code for hosting

2009-10-26T10:27:00.001-07:00

We have decided to set up our code hosting at Google Code. The link is:

cosmic-engine - Project Hosting on Google Code

There is next to nothing there now, but the first official drop will go up at the end of this week(!), then followed by regular roll outs until it's all up and refactored for public consumption.

Cosmic Engine goes Open Source

2009-10-06T12:28:00.000-07:00

I just wanted to make a quick announcement because I can't wait any longer.

We will be releasing the Cosmic Engine and related technologies as open source within the next few weeks.

To begin we will host it at Google Code and the team will be working out of that repository directly. Additionally, we are committed to making it as easy as possible to build out of the (SVN) box with a NetBeans project that will build and run with little to no configuring and by including all the underlying layers in our stack (JOGL, jMonkeyEngine, MTGame, Avatars and all our secret sauce that we have yet to release to the wild)

We are still in development so this is not an orphaned project, but we have reached the point where enough outside parties need and should have access to the source to grow and refine it's feature and capabilities.

Digging up old videos

2009-09-02T16:01:00.000-07:00

I was going through some of the old snap shots and videos that were taken during the development of the avatar animation system and I found recordings of the experiments done with the ZCam prototype I brought with me from my vacation in Israel last year :). The ZCam is a special camera that captures depth (in addition to the normal color and sound), this is the same\similar technology that is utilized by project Natal (see Microsoft's XBox360).

Here is a video showing a networked prototype:

Here is a video showing avatar movement:

Freezing the Avatars project on the Sun SVN

2009-08-24T08:18:00.000-07:00

As you might already know Wonderland is going through a period of bug fixing in which no new features are added, we evaluated what are the things we would like to touch up before freezing the avatars repository which are used for wonderland integration*. First is a fix to the hair placement issue, each head skeleton has a special joint called "HairAttach", this joint is used to properly transform the hair into position. We made sure that all the head skeletons are set up nice. Another issue we ironed out is color modulation for every clothing item and the skin, the system supported this feature for a very long time now but we made common use of alternative techniques (that often gave better results) such as using texture blending tools (avaiable in the avatars project, but can also be done with common industry tools) to compose a custom texture. The latest commit to the repository changed all the defaut textures that are used by all clothing and skin to black and white, this insures that color modulation will yield the desired results.

In the picture you can see two avatars with white color modulation on the clothes and skin tone color modulation applied on the skin, the shoes, pants, shirt and hair can each be individually color modulated.

* https://avatars.dev.java.net/svn/avatars

Odd and Ends

2009-07-29T19:10:00.000-07:00

We have been meaning to post for a while but just didn't get around to it, we have progress in multiple directions. In the Project Wonderland space we are reaping the benefits of the dedicated time we spent towards refactoring the entire avatar system. We got our internally developed collision solution integrated into our branch for 0.5. We load in our own custom environments and modestly begin designing the GUI\HUD of our implementation. Performance, download and load times are improving. We are in close contact with the team at Sun and we appreciate their plans to perform "feature freeze" and focus on stabilizing the overall system. We have found a need for a quick machine compatibility test application to help in the QA effort, before even considering the use of a certain machine in the studio for QA we make sure that machine passes the test - loading a smiling avatar via web start app.

On another front we have successfully developed a tool for soft body physics editing for 3D models. The output of that tool is exported into an iphone friendly format that is then loaded on the iphone and runs in an app developed by Kyle Roucis - one of our interns. We are experimenting various usages for this tech, it could possibly serve as a solid base for a heavily multi-threaded physics system that is based on verlet integration. I love verlet systems, it's lots of fun!

(This picture is outdated but it shows a verlet structure)

Developing a "Best Fit" view model

2009-07-17T15:16:00.001-07:00

To followup with improvements and fixes to Wonderland0.5, we created an option in the context menu that attempts to position a camera on a cell of interest containing an X11 app; to allow the user the "best view" possible upon interaction.

This context option currently switches the user camera to a First Person Camera (FPS Camera), and based on the transform of the cell of interest, attempts to calculate the best position to place the camera so the user gets the best view of the cell. When the user wishes to go back to the avatar view mode, selecting the "Best Fit" in the context window will return the user to a third person camera. This mode will undoubtedly make interactions and/or viewing X11 apps easier.

Due to current refactoring of the Wonderland0.5 code, the "Best Fit" context mode will be available in about a week. The code has been submitted to the Wonderland Team to be integrated in with the refactoring. Expect more cool things like the Chase Cam and the Best Fit view mode as wonderland evolves and matures.

Chase Camera Model

2009-07-10T17:42:00.000-07:00

Hello All!

As of Wonderland 0.5 revision 2844, a chase camera behavior is available. The default camera behavior in Wonderland needed a bit of love and attention so we integrated a camera model of ours. The behavior is a third person perspective camera that uses springs to smooth out changes in the desired position and desired look at target. The position that the camera seeks to, relative to the avatar, is configurable to allow for zooming, rotation about the avatar, etc. Go get the latest version of the trunk and check it out! In the client, use the "Tools" -> "Use Chase Cam" menu item. I've posted screen shots, but you REALLY need to see it in action to appreciate it.

Default Hard Attach Cam

Chase Cam

API Refactoring now in Wonderland 0.5 trunk!

2009-07-09T19:18:00.000-07:00

Hello again Cosmic Game Engine followers!

As of revision 2833, the refactoring we mentioned in the previous post has been merged and integrated with the Wonderland 0.5 trunk. The major thing that will show up visibly is a better selection of random avatars. Grab the latest revision and check it out!

Ron

Description Update

2009-07-02T08:10:00.000-07:00

So now that we are underway in our new development with Cosmic, I thought I should update the blog description to better reflection the current activities. For posterity's sake I will copy the old description here as it may still give some context to the older posts as well as maintain that small bit of history, may Java3D rest in peace.

The Cosmic game engine is a Java and Java3D based game engine in development at Immediate Mode Interactive. It is named after the game lead character and universe of "Cosmic Birdie", which is the game in production using the Cosmic engine. This is my developer journal of that activity as it closes in on release.

Spring Cleaning

2009-06-30T12:01:00.000-07:00

Hello faithful Cosmic Game Engine followers!

The team recently completed a two-week refactoring party on the avatar system. A lot of the early code needed to be looked at again through the lens of over a year of experience as well as the feedback from early API users. Attention was paid to locking down the API (that is, only exposing the essential pieces), refactoring the classes to fit a more "package as module" design rather than "package as a way to organize source code", throwing exceptions as soon as things go wrong, and removing unused cruftiness.

One part of this effort that we decided to test out was the usage of automation wherever possible in the development process. The stated goals of this effort were:

Host a local Subversion repository (to speed commit / update cycles)
Use static analysis tools (more on this later)
Host a Bugzilla install to track pending issues
Use a continuous integration server to detect problems as early as possible

The first step here was to determine an operating system to use. My initial choice was OpenSolaris, but unfortunately the RAID controller on our server was not supported under OpenSolaris (or several other OSes as we discovered). After a myriad of different OS trials (including FreeBSD, SuSe, and Debian), we had the most success with Ubuntu Server. From this point I set up Apache webserver and Tomcat. Installing bugzilla and subversion turned out to be pretty simple, but getting tomcat to work well with https proved a little more tricky. Once the subversion server was up, we determined that having an html browsing interface for the repositories would be great. There are plenty of commercial products for this, but I decided on ViewVC. ViewVC even has a plugin for Hudson, although I could not get it to work without modifying my install (shame on the plugin writer! Give me a config option to change!). My goal was to have a single htpasswd file that was shared between as many services as possible. This was possible for every tool except bugzilla which has been a bit of a pain to configure. The rationale behind this goal was to pass off administration of this system to anyone. Rather than needing to be a competent *nix administrator, a person wanting to add a new account to the build server / svn / https documents simply needs to run a handful of commands from the shell.

For our continuous integration server, we went with Hudson. Hudson has proven to be an extremely useful tool. Firstly, we were able to set up automated builds that are triggered by subversion commits. Secondly, we were able to easily tie our static analysis tool in with Hudson (through a plugin) and have it run periodically on the code base. Hudson is easily deployed via Tomcat, although again some voodoo is required to make tomcat play well with apache https access. I am particularly pleased with how much configuration and administration is possible in hudson entirely through the web interface. Plugins can be installed and the software can even be updated, all by clicking through a few pages in your browser.

The static analysis tool we settled on was FindBugs. This tool is awesome! FindBugs is a java tool made and maintained by the University of Maryland. It is free software (LGPL) and it can detect all sorts of potential problems that may have otherwise eluded developers. Not only does FindBugs analyze your code, but it can also analyze dependency libraries that you provide. All of the bugs that it finds can in turn be linked back to the source code to immediately point out the problem. We found several problems that made us wonder how the affected areas EVER worked! In addition to finding potential bugs, it also helps to enforce java best practices through its style and convention warnings. Initially, FindBugs found 269 problems. Through the course of the code scrubbing we were able to reduce the number of warnings significantly. It was fun to proudly claim responsibility for a drastic drop in the graph overnight.

So how does all of this affect you? We will be integrating our changes into the svn repository at the Java.net Avatars Project. The current HEAD revision is 1119 on the trunk. Anything beyond this will be the result of merging our changes branch with the trunk. This includes pretty prominent API changes, so if you have code already relying on the existing avatar system, it may need to be changed to cope with revisions after 1119. Following this we will be working to roll these changes into the Project Wonderland 0.5 codebase. Stay tuned for more!

Have a great weekend!

2009-06-26T16:36:00.001-07:00

This week we have been cleaning up code in the Avatar Animation System, all of the "smarts" that enabled our GUI tools to manipulate this fairly complicated system on a high level are now neatly accessible through utility API... we extended the documentation of the system and of course fixed plenty of bugs :)

With this positive note we wish everyone a great weekend!

More Avatar options

2009-06-19T13:24:00.000-07:00

Our Avatars

2009-06-18T19:00:00.000-07:00

2009-06-16T12:10:00.000-07:00

Cosmic Engine 2.0, based on MTGame (multithreaded system derived from jMonkeyEngine 2.0) will be made open source and released over the next few months in modules.

More news coming soon...

Lost in Space

2008-08-01T09:51:00.000-07:00

It was never my intent that once the Cosmic engine had reached the public demo status that this blog and any other public development would stop. But it did. This is just a short note to say that in fact this will start beginning update regularly again that amazing new things will be disclosed and discussed here about coming updates to the Cosmic engine.

Cosmic Engine Demo Release

2006-07-10T18:04:00.000-07:00

Well our beta is finally live. You can give it a whirl at:

www.cosmicbirdie.com

What can it say? Well I'll start with the bad (since that is what most people will notice first) and then get to the good.

Bad:

There's no game. Yeah it's a engine demo, 'nuff said. Check back for more game later.

It's buggy, oh yeah, it's beta. Beta = buggy. Any bug you find, we already know about it :-) Putting this out was an effort in developmental transparency. We wanted to get it out there to the people, it's been in closed rooms for what seems like forever.

Speaking of transparency...

Transparency isn't completely correct yet, most noticeably in the opening sequence when the text panel comes down. Oh well that was a late addition.

There is no networking. WHAT you say?! That's right single player only (if you can even call it that). Again this is because we set a deadline to make it public and that had to be turned off until we can set up a server to connect to. As I wrote before, we are using DarkStar and our object message layer, so the networking is working fine. THE DarkStar Man (Jeff K.) is getting close to allowing us to hijack some Sun server loving, so networking will mark the next major milestone public release (and actually introduction playability as a game feature!)

Performance. There is ONE huge performance issue and here it is. Because the ground is deformable, and I needed to work on adding features vs. this fix, all the geometry is dynamic all the time. That is, it all must be moved across the bus and therefore certain views on certain hardware really hangs. When the world is all static, 60hz is cleared on all target hardware, but as posted it's gonna slow down sometimes. This is the biggest performance killer and it is an issue in how I am using Java3D. The world needs to be set up not using J3DBuffer (NIO) or with a different J3D hint or something. One reason I really wanted to get this out was so I could bother J3D guys about this one issue.

Good:

X3D exports and loader are working famously, thanks much again to Aaron and his RawKee Maya X3D exporter.

Physics and collisions. They work for about 99% of the possible execution paths. That is, you CAN break it if you try. This is the kind of thing that just gets ever refined test after test. If you want to break it, try this. Hold down the key while driving. Maybe jump sometimes. Rise, Repeat.

Particles. They work and are efficient. They need more ark work and all the characters still have the same green feathers. That's just dumb, I'll to get on fixing that one.

Deformable world. Yeah baby, you can deform ANYTHING in the world. And you can break it up bad too, there is no limit. So this can bust collision, screw up physics, all that. By the way, “r” reloads the world, i.e. Undoes your damage if you want to keep testing with out a complete exit/restart.

The glow effect on the ground under the gryos. This is was an important effect because it works basically like (fake) shadows would and shows a decent graphically capability. I don't know of another J3D demo that shows that and its' too bad. BTW you can toggle that with "o" (actually I just changed that, but I'll put it back tomorrow)

Many others too numerous to mention and that nobody cares about so I'm done for now. Of course I'll be posting all kinds of fixes from here on out so you can watch these things slowly melt away in the near future, but in the meantime get over there and blast some space avian tail feathers!

Cosmic Engine Demo Release Date Set

2006-07-05T15:16:00.000-07:00

Quote from: kevglass on Today at 01:34:04 PM

3) Cosmic Birdie Demo - now I've played this, and its fun! Are we going to see the GDC/JavaOne demo release any time soon?
...Kev

Yes.

I guess I can say this now, there will be a semi-public release after this holiday week. So I'll go ahead and commit it to Monday, July 10th.

A couple notes though...

This will be single player only with very little "game". That is, the build will not allow networked play isn't really set into gmae round format. It's "open" play in an arena level. There are many reasons for this, but the main reason is for testing purposes. Most people that will be testing will only need to get in and out and see what's happening with the graphics, physics, collision, motion, UI, and gameplay elements. Also, the connecting and hosting UI is a mess and unusable for all but the internal team. The next major public release will have playable networking.

Particle-Text System Update

2006-06-29T07:27:00.000-07:00

It's been over a week since I posted about our text overlay system in development so I thought I would at least put up a quick update for the rest of the team and others interested out there.

I have more than a simple prototype up and running and testing has moved from our engine viewer to the actual game run-time. There was many interesting and nasty details to work out to get this into a usable "TextPanel" type object structure, and perhaps I will post about them sometime, but I doubt it :-).

Anyway, I have the particle-text in panels that animate out into view and flip up (or could animate just about anyway we like). Check out the sequence of screenshots showing this effect (click it for the full size image). At this point I will be putting this aside now and moving back to finishing of the single player beta that needed this system for training messages, etc.

I hope to put out the playable tech/demo after July 4th week.

The Art and Science of Wheel Invention

2006-06-21T03:38:00.000-07:00

I am getting closer to revisiting my first post but until then here are thoughts on my latest task...
- A word of caution, todays post makes heavy use of italics, “quotes”, gratuitous use of the words invent and wheel, and other devices (like this) to denote tone; this is a very vocal post because there is collision in terms between concrete and abstract throughout. I apologize in advance that I couldn't recite it to you personally.

“Reinventing the wheel is BAD! Bad I tell you!” (it's been pointed out since I first posted this that often someone telling you that is selling something)

Well, I won't tell you, but everyone else will. (neither will this guy)

I think the phrase "You shouldn't reinvent the wheel" (or something similar) is the real issue. To correctly apply the analogy of wheel production, I think what developers actually do is remake a wheel, not reinvent the whole of the concept of a wheel (design patterns are more like inventing wheels, implementing the pattern is more like making wheels)

And remaking a wheel is just fine.

For artists this idea doesn't apply very often. Why is that? Are they naturally less likely to reinvent? No, it's simply because they don't equate making a new character (or “art”) as reinventing characters (or “art”). They have the idea of character in mind already, they just need to make a specific character (or object or world). Rarely does an artist reinvent character, and if they really did that, I can't see that as bad, that seems like a really amazing, interesting achievement.

The problem is our game engine needs a decent glyph font overlay system. We've had overlays in different forms for a long time (items, speedometer, map, etc), but not an honest-to-goodness, any string, print to the screen, glyph-based text (great texture tool for this) display needed for game-to-player messages. This project at the game level has reached an impasse and a text overlay system must be added. (many developers may be thinking, "you didn't have text overlays done yet! why am I reading this guy's crap!" but the fact is the overlay system had done the job for many demos in the past and did the job for the existing game design. It's true however that for a reusable engine this is desirable but then each game often reimplements at least part of this to make it totally customized - barring the small growth of UI middleware, but I digress...)

And then there's that whole inventing of the wheels thing.

So I searched, hunted, downloaded, tested; if you are a developer on the 'net these days you know the drill. Fortunately for me I only spent a good day on this process, having repeated this so many times before for other needed components I've learned to give up quickly (yet another form of reinventing the wheel, the wheel of finding wheels). So you probably guessed it, I went ahead against all that is holy in the world of code and dogma, and...wait for it... REINVENTED the $%#%&@ wheel. (this is not technically correct as per my opening remarks because I know what I wanted/needed, a glyph font overlay system which is the idea of “wheel” - but I just will have to write it - remake A wheel)

As usual in my experience when given enough time to really imagine and think about the problem, I start to mentally construct the wheel using some of what I know I have, extending that, moving things around, and above all imagining the final product. While dreading this diversion from my other seemingly more important development duties, I stumble upon a particular effect (this is in my imagination, mind you) that is so interesting, so compelling, so FUN that it really begins to drive my motivation. And it reveals a solution path that in the end is far better than any other system I managed to examine earlier.

When the player is done reading the glyph font messages, I want them to fall out of the box/bubble/overlay container right onto my character's head. That's it. It's so simple to state and imagine.

Not so simple to code. Hmmmm, unless I use our particle system as the basis for the font system which is an obvious choice when you imagine a bunch of letters falling, which is exactly a particle system.

And that is exactly what I did.

Large image

This series of images shows the text in action. The first frames show the text typing out to the overlay area (which is the whole screen here) in 2D as expected. Then I trigger the conversion to 3D space (each letter is a 3D particle but in screen space to start, so for example, the Z coordinates are 0.0). The particles are unprojected out into 3D space (instantaneously, visually there is no change) which ultimately means they move, scale and start falling, and then interacting with the game. This effect is nearly as I want (the final version will have collision with the character so they can get annoyed but this behavior) and it could be called metagaming, like this.

So I have plenty of work still to do to get it really usable, and then even more to production level. On the way though, my particle system has had a bit of an overall with many improvements and more to come to support the text system. Incidentally, this isn't a all-equal size letter system like most. Because of that nice AngelCode tool that properly packs the letters AND gives you the character data needed to lay them out, the visual quality is quite good.

And I got to learn about kerning, which I'd never heard of and didn't know about, and gained me a bit more respect for people that work with fonts regularly. There is a secret complexity and elegance there hidden away that you experience directly but never really know about – very much like code often has.

And in some since I reinvented the wheel. I mean I really reinvented the wheel. I'm sure there are games that have this text effect, but I was not aware of them. So since I was forced (choose?) to remake the wheel and having not really known the invention well and in going through the process I ended up with something a little different, but what I wanted none-the-less. In fact, trying to get this effect with other systems was not possible.

So, it's true, we should try not to reinvent wheels.

Remaking them is just fine and often yields a better wheel.

And sometimes it really pays to remake a wheel because you just might reinvent it. (your mileage may vary)

More on composite vs. inherited game objects

2006-06-11T07:38:00.000-07:00

Hello again,

I will continue the interview form post I started last time soon. But since then I have been asked a few interesting questions about engine development in the JavaGaming.org forum so I will post an answer (at least part of it) here.

Here is the question that was posted (unedited):

The one that particularly got my attention was ww.gamearchitect.net one with the 3 series on scenegraph objects and such. It seems to me that most, if not all, of his concerns stem from bad design. For example "The Diamond of Death. What do you do if trigger objects are derived from game objects, and dynamic objects are derived from game objects, but you want a dynamic trigger object?"

Why would a trigger be in the same group as a mesh or a skinned character? Technically, they are both "game object"(s); your just costing yourself unnecessary overhead...

In the second GameObjects blog/article, he says "Using a directed acyclic graph instead of a tree, you can share objects and animation state across multiple locations in your world" which only begs the question, what is the difference between a directed acyclic graph and a tree? Conventional trees *are* directed acyclic graphs from what I have understood.

"You'll have the same problem animating control points for higher-order primitives. Height fields, lights, volume fog and shadows are similarly likely to end up being awkward special cases.". Those seem to fit quite elegantly in the scheme of things from what ive read and seen...

Apologies if it seems like ive put his blog/article under a microscope, but Im in the middle of making my own game engine and I thought i had the scenegraph element well and truly finished

PS. the reason I got Java involved in this because he mentions multiple inheritence in a few places

And now my response...

As mentioned in the opening of the forum link I posted, try to get a hold of:

"In the latest GameDeveloper Mag (March 2006), there was an article by Mick West titled "Evolve Your Hierarchy: Refactoring Game Entities With Components"....."

The article was one of the best short pieces on what I am talking about and what can be done.

The component model doesn't really have anything to do with a scene graph (at least not directly) or Java. I use Java3D, which is a scene graph the rendering system, but my game objects are composite "groups"(the whole game object thing kind of gets blurry in the component model which is one reason why developers can be resistant to it). Of course there is some inheritance, you have to have it at least for consistent abstract object handles, but what you think of a "player" is no longer a game object type or even an object and behavior objects. It's a lose collection of components that do small independent parts and often don't even know about each other. Inheritance (and multiple-inheritance are not used and/or needed).

But I think the major different from a programmers perceptive is this; the game object (player, item, whatever) is not a class that is made in code at compile-time, it is a collection of run-time connected components. The compile-time vs. run-time change is felt the most in code since you can no longer go look up your player class and mess with it. You have to think differently about how to make objects and things happen.

The other reason for doing this is not obvious until you have a large enough game with inherited game objects and you start having difficulty deriving new types. With the component model you can "derive" (or in this case combine to form) new types at run-time, or load time, or and here's the real concrete direction for this, with scripts at run-time (or from a GUI tool that makes scripts and/or configuration files). That is the real key because as the inheritance system grows it gets heavier and heavier and slower, like quicksand, to develop with. It's a strange paradox as you have more capabilities in your engine it gets harder to use them (and this is especially true for a game logic programmer working atop this mess).

The component model (when done well) gets back development speed and versatility as well as adding in new run-time capabilities.

How exactly does it get back development speed and versatility? The short answer is it just does. The long answer will have to wait for another day.

Let us begin

2006-06-09T06:38:00.000-07:00

Introduction

Hello,
This is my blog.
More specifically this is my blog about developing the Cosmic Game Engine.
Even more specifically, this is my journal about the process of developing the Java based Cosmic Game Engine as an independent game developer at Immediate Mode Interactive (IMI) while also teaching the course in Engine Development in the Game Developement degree program at Full Sail.

Ok, enough of that…

The reason I am making this blog is that often I go long periods of time without significant news to my associate developers as well as my virtual partners out on the ‘net while digging deep in the development pits. Unfortunately silence does not imply activity, and so often it can seem as though I am off doing nothing (or something else) when in fact I am STILL working on the same project, but probably just more so!

To begin with, I will make this post to bring everyone up to speed on what has been going on recently. I will not give a complete history (perhaps someday) here, but just cover basically what has been happening since GDC of this year as that was the last major time most everyone involved or interested got caught up on this project.

As a general warning, this blog will probably get fairly technical from time to time, but for the most part it should be digestible by most of the people with which I am in regular contact. It may at times also get “personal”, that is, I may need to explain some personal life activities/events since I am using some of that time developing this engine and sometimes THAT time will win out, for example weekends…

For this first post, instead of just blabbing about what’s going on which for me tends to run on and on, and divert to tangents often confusingly, I have decided to try a different style. I am going to write this in an interview format, that is, as if someone was interviewing me about the project. Since I AM that someone interviewing me, the questions will be contrived, “loaded” and probably leading, but then that’s how I converse much of the time (a skill I developed from being a Full Sail teacher for 8 years). One reason to do this is so that you can skip areas that aren’t of as much interest to you just by reading the question for that section. Another reason is, it just seemed easier to write it that way today since I have so much to tell and it needs to be very organized to get it all out clearly and as concisely as possible.

Ok with all that said let’s begin
So what have you been working on since the GDC demo this year?

Several different components needed to finalize the Cosmic engine for the Cosmic Birdie racing combat game as well as a bit of the game code itself in an effort to complete a full release in time for the IGF in September.

Can you expand on which components you’ve been working on?

In particular the networking has been my major effort since GDC although, there has been physics and collision work (mostly bug fixes and optimizations) as well as weapons fixes and allot of general refactoring hacky game objects into a better framework.

Ok then, what exactly is going on with the networking?

At GDC we showed our Cosmic Birdie demo running on the Sun Game Server (DarkStar). At that point it really was hacked into our game in no real scalable and/or extensible way. I basically got it working and that’s it. Since then I have completely replaced any networking code from that demo with a more (...i..n..h..a..l..e...) production ready object based network messaging layer built on top of DarkStar. Additionally, the core of this messaging system is local (not networked) and object based and is now used throughout the Cosmic engine code base. This was part of a larger effort of converting the original hierarchical game object system to a more component based system like so many other game engines have done. That was also done since GDC. That was the most entertaining part of this work because, basically when you make that kind of conversion it breaks everything for awhile, and it did (laughs).

Additionally, getting the networking working means several things. There are run-time game object communications (which get the focus allot of the time) but there is also the managing of the connections and player-game and entity creation. DarkStar does some amazing server side stuff for you, almost none of which Cosmic Birdie (being a more player to player style game in this incarnation) takes advantage of now. In fact in the latest build, CB runs against the public DarkStar release (using the MatchMaker, more on that later) with NO SERVER SIDE code added. In the GDC build, we had a small server-side class handing out some IDs for the game but it was just hacked in that way. After the refactoring and some development, I got the clients to operate as true P2P style clients, they just need the connection. In the end, I’m sure we will be using some of the server-side stuff because we would really like to do some of the game object simulations there, and move towards a more persistent level sometime. For this release though, we are not planning on that. The game is meant to be as simple and fun as possible, with as little “jump-in cost” as possible, whether that be in learning curve, time to play etc, the typical constraints of a causal game. I should say that althought this game is meant to be causal, the engine is being developed with the intent of much more complex and larger scale games. The engine is the major effort because it will be the core technology that IMI will use for all future game development.

Alright, then what is the current state of development?

Well, a complete report will be to long here and will have to come in pieces across several bogs. Focusing on the networking part, within the last 24hrs I got the example MatchMaker code provided by the DarkStar group integrated and working with CB. This was a major milestone and another reason I stopped to do this blog now. We have a development environment where we have a running and dedicated server that we can test on or off the ‘net as well as a network of test machines for the clients. For me, as a non-funded indie developer, that was a major accomplishment and this means several things that I will jot down in a bulleted form:

For the server:

We have the latest DarkStar configured and running on the server.
We have a working build environment for server development as well as having had great support from the DarkStar team.

For the clients:

We have our client working on the dedicated client machines.
We have a working build environment for client development.

The collection of Java APIs alone can be a real headache here sometimes (this is one of the reasons we decided to dump JOODE long ago), but the major ones, such as Java3D and DarkStar, are in good working order and stable.
Our in-house APIs have stabilized quite a bit, and for the scope of this game look to be nearing feature completeness with the exception of the animation system and sound f/x. It seems as though the animation system will never be done to my liking :-) and there is bascially no sound work done at this point, code or assests.

We have the MatchMaker client code hooked into the CB client. I say hooked in because it will need allot of work to get it to production but it does work properly as far as I have been able to test. After a little be more testing and such (I am hoping within a week) I should be able to set up a new release on the IMILabs.com web site for beta testing among friends. This will be the first really serious beta test of the project as a whole. I imagine it will be pretty ugly, but I am still very much looking forward to it!

OK, well this has gone on long enough for now...

Yes, I agree, this was a good start but there is much more to tell, let’s continue this interview in our next post!

L8r