31 March, 2007

Unstdio

Progress has been continuing, although a little slow the past few weeks. I've had a bit of "coder's block" and instead decided to start taking care of odds and ends: naming the engine, get web hosting, and the mundane task of creating documentation.

The name of the engine is now Unstdio. I've registered www.unstdio.com. I must say, Netfirms and Google Apps are nice and simple, and I was able to put together a few pages quickly enough. I highly recommend that combo for anyone that isn't super web savvy (like myself), but still has content they want to put online.

There's still nothing up for downloading, but I hope to start getting things up in the next couple weeks or so. Hopefully I can learn enough PHP so that I'm not copy/pasting HTML code all over the internet. I've never been one for web pages. :-)

And to give a few updates on new features and changes...

The resource system is just about in place. It's much better now, and resources can now be referenced by name instead of by filename. I've been putting that off for quite a while now for and it's nice to almost be done with it.

I've been slowly wrapping the Newton Game Dynamics library so games can have 2D physics built-in. It will probably be a while before this is completely implemented, but I'm hoping to make it dirt simple to wrap a physics body around a sprite actor and have simple callbacks for collisions and transform updates.

There should now be a decent number of comments in each of the top-level game object classes. I figure it will be a while before I get real documentation, so I'm trying to make this as good as possible for others. For example, here's an excerpt from the GameScene object class:
A GameScene is the heart of gameflow and logic. Examples of simple scenes for a Tetris game might be the main menu, basic playing, and the high score. When the game is told to enter a scene, the #exit method is called on the current scene and then the #enter: method is called for the new scene, with the old scene as an argument. Note: this won't actually happen until the end of the current frame during the handshake.

Each frame, the #advance: method is called (with the delta time - in seconds - since the last frame) as well as the #logic method. The #advance: method is only called when the engine is not paused, and is typically where the scene will advance actor's that are in the scene. However, #logic is called ever frame, regardless of the engine state, and is typically where user input is processed (quit, un/pause, etc). After advancing the frame and processing logic, #render is called by the engine allowing the scene to perform any necessary rendering. Like #logic, this is called regardless of the current engine state.

Once the entire frame has been advanced, processed, and rendered, before any scene changes happen, #handshake is called. This is a catch-all, post-frame method, where the scene can update anything that wasn't taken care of during the frame. For example, if actors were killed, and need to be removed from a list, this would be when that happens. While this isn't a true handshake, the term is being reserved for future use when (and if) the engine is ever multi-threaded, allowing the rendering to happen simultaneously with the simulation.

I'm slowly putting together an idea for a package documentation generator, that will generate HTML documentation for a package and all the classes in it. If something like that already exists, though, I'd be much appreciative if someone can point me to it.

4 comments:

Flatlander said...

Congratulations for getting this far with it! I'm certainly looking forward to the release.
It also looks like Dolphin is soon going to be on my shopping list...

tejón said...

Ditto, flatlander! I finally got some upgrading done, and my video card should be able to handle the engine now! (A little sad when you're saying that about a 2D engine...) So Dolphin is on my short list for pending purchases.

I'll probably wind up checking out pfisk's Vista Smalltalk, too... IIRC he was quoting $29 for a compiler version once it's ready. I'm not sure whether it's going to wind up being a tool I'll want to use, but at that price it's disposable. Worth it for comparison, at the very least.

Just out of curiosity... is that "Unstandard I/O," or something more obscure? :)

Jeffrey Massung said...

I'm glad my efforts are perking people up to using Smalltalk - especially for games! Thanks for always posting kind words.

As for the name, yes, I chose it to read as a play-on-words, where different people would read different things: "unstandard I/O", "not-C". and perhaps even the "un-studio".

But, I also chose it to say that just because something is the standard way of doing things (read: using C/C++ for games), that doesn't make it the best.

RickTaylor said...

Hello. Just giving an excuse for mentioning yet another language, erlang does garbage collection, but it's optimized for real time systems with lots of concurrent parts, so the garbage collection is done continually, not in spurts.

--Rick Taylor