Thursday, June 29, 2006

Particle-Text System Update

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.

Wednesday, June 21, 2006

The Art and Science of Wheel Invention

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)

Sunday, June 11, 2006

More on composite vs. inherited game objects

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 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 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 Smiley

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.

Friday, June 09, 2006

Let us begin


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 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!