ODE

After reading a lot of forum posts about it, I understand Tao.Ode is no longer in development. It's only an implementation of 0.6, and presently ODE is at 0.11.1. Luckily, this dude made .NET bindings, so we can still use ODE!

It also took me all morning to figure out the best way to run the step intervals. Timing is so ridiculously imprecise with both Environment.TickCount and DateTime.Now.Ticks. I honestly wouldn't use TickCount at all, and wouldn't use Ticks for anything smaller than seconds. The best way in .NET is to use Stopwatch, which does the best job possible on any hardware. It enabled me to time the game loop and determine just the right times to fire the step intervals, (and also the ODE calls). I have an enum set up for 30hz and 60hz; 30 will be the default, but the user can actually set it to any number of milliseconds they need.

My next goal is to get an example running with ODE in the engine. I want to stress importance of two main things:

1. The physics engine is not necessary in Awe+. Unless the user needs it, it will not be invoked. However, if it is needed, it shouldn't need tons of extra initialization lines, both for ODE itself and for individual physics objects. Still shooting for one-liners here.
2. ODE allows users to turn off objects to keep them from running physics. By default, I would like to disable objects out of a certain range of view of the window, so large scenes won't have speed inhibited by invisible entities.

Maybe I'm worrying too much.

Tao

Dorthu suggested using Lua to allow for engine/game scripting, and it looks badass. Luckily it is also implemented in Tao, as is the Open Dynamics Engine (ODE). I was reading articles about rigid-body physics and trying to interpret open source physics engines, but decided ODE is the most likely option. Dorthu agrees, and hopes this already-stable and decent engine will expand our developer audience. We'll just want to make sure to provide enough tools for the developer who doesn't want to use the physics engine (like for maze games and puzzles and such), because I don't think keyframe interpolation is going to be possible for objects running with physics.

Tao includes wrappers for the following, to allow ones Mono project to remain cross platform: OpenGL, 3D audio with OpenAL, simple window creation with FreeGLUT, collision detection and reaction with ODE, Physics with Lua, SDL for loading images and blitting, Cg for shading, GLFW for input from gamepads and mouse/keyboard, PhysFS for grouping resource files, FreeType for fonts, and FFmpeg for streaming video. Whew! They really cover all the bases. We'll worry about sockets last.

Wtf?

I've been checking out all the other open-source engines out there, and I've decided on a goal for the Awe+ engine. Awe+ will be the simplest game engine to use. As its original purpose was to replace Game Maker as a simple form of game development, I've realized we can't expect user-developers to read through dozens of pages of documentation to see how the engine works. The features should be blatant through decent example games, and should be simple to use through the use of defaults. Game engines should allow for the creative freedom to make any type of game, but much of the process can be reduced by taking a look at the types of games people want to produce quickly. A newbie developer wouldn't use a full-blown 3D engine to write a simple 2D side-scroller that utilizes only the SDL wrappers. And a 3D developer wouldn't likely use MUGEN as a base. So considering the target audience isn't hardcore game dev teams, (as they likely already use the monstrous OSS engines already out there), we focus on the goals of developers who want to do the least to accomplish their game ideas.

I know, doing the least usually involves making some sacrifices, but as always, there's usually a million ways to solve the same problem. And I'm sure that while using this engine, new developers will pick up enough skills along the way that upon finishing a game, they would immediately have a better implementation idea for their next game.

We won't aim to limit the features of this engine, just make it work simply by default. All the details will be editable. This is another reason why I believe it's a good idea to use C#--users won't have to be that knowledgeable about avoiding memory leaks to get a game running smoothly. I want Awe+ to be the best transition from dreaming about making games to actually making it happen, without being ashamed of using the drag-and-drop Game Maker program.

Two Years Later

I obviously lied when I said I would constantly update this blog throughout the entire engine-building process, but I've decided to resume work on both the engine and the blogging. When I started (six posts ago), the idea was to make a fighting game. However, I obsessed about the backend and the engine work became the entire focus. I've never made a full game engine to support more than one game, so some of the original concepts might be used in every engine, or they might be naive and a bad idea altogether. I neither know or care. But, since this project is open-source, I hope it will catch on and prompt suggestions and updates.

In case you haven't heard: I've implemented the Awe+ Engine in Objective-C for the iPhone! It's based on almost everything in the Wiki, and it worked for some simple game demos with animation and collisions. I've tried to get my Obj-C code running in Ubuntu, but it's annoying, so I've started rewriting it in C# with Tao. It is STILL going to be cross-platform (Mono compiler), but it's less stressful and it's garbage collected.

After seeing it in action on the iPhone, I've decided to change some things in C#. I don't know why, but I decided not to give Drawable objects child Drawables. They were all in a single collection inside of each Scene, which is stupid--if they had children collections, Scenes could just inherit that collection-loading/stepping/drawing from Drawable. Also, I'm fairly certain I want to give the option to use polar coordinates. So with polar or Cartesian coord'ed children, relative positioning WRT the parent will be simple.

Stay tuned!

Woah...RRSSE is going to be awesome!

Yo, Skitch thx for the briefing last Thursday- Awesomeness!

So, I wanted to get a jump start on this project so I decided to start with one of the most important tasks... sprite loading... yep after reading an ebook on sdl yeah it seems accomplishible... I typed some code but my computer is having a brain fart and will not compile anything... so...yeah I will keep working on it and continue reading more info... hope to see everyone on this blog soon... also if you have not made your way to the wiki yet go -> Register NOW!

-kthxbye

Lego Code

I'm not sure why, but recently, I keep thinking of this project. So far, there is no code at all, but great ideas keep popping into my head. Here's the latest one:

Aside from RRSSE and GELLATIN, should there be anything else that helps our programmers create games? RRSSE provides the sprite loading, drawing, and overall handling. GELLATIN deals with the timed Step impulses, collision detecting, and Scene handling. What else is left? As I said before in the "Brainstorming" post, we should support common things seen in games, such as meters, counters, etc. But, not every game needs these things! Tetris doesn't need a life bar! The coolest way I can think of to do this is to create snap-on modules. If you need a life bar, include one in your project. Need a timer count-up or count-down? Include that file! The best part, though, will not be the modules themselves, but how they're implemented.

A module can provide a basic look and style, maybe some properties that can allow for changes in size, positioning, and color. But, some games must provide a sort of style and pizazz for everything on the screen, a style that can't be matched by generic widgets. To solve this problem, there will be a base class for each module, that the generic version inherits. This way, if a programmer wants to make a new, fancy Life Bar for a fighting game, it will have the same format as the generic one. These "contracts" for widgets will allow for extreme flexibility for games and modifications. Now, imagine another snap-on widget in a game that waits until a life bar is down to 20%, then displays a text bubble that says "Oh, no!" If that works with the generic life bar, that can work with ANY life bar.

The main goal is to make a bunch of "widgets" work independently of one another, but using RRSSEE. Then, widgets can be built on top of others, or extend them somehow.

One Layer Above RRSSE

While we're at it, why not build a separate layer upon the RRSSE? Or, perhaps, an abstract secondary layer that could be used either on the RRSSE's 2D engine, or some other similar 3D engine...? Ehh, maybe not that second option. But a separate layer would be very helpful! I was thinking about what made Game Maker so helpful, and noticed a big part was collision detecting. However, it gets very ugly in Game Maker: The engine itself checks all around an object to determine if there is a collision, but it only returns a boolean value. The scripter must then determine the direction of the collision. This means the complicated data is simplified to the scripter, who must use the simple result to find the complicated data all over again. Meh, it was good in theory, but perhaps if Game Maker provided a few more functions for collision detecting, it would be better off.

Our "Game Engine Layer Located Above The Initial Nitty-gritty," or GELLATIN if you will, must allow for single-directional collision detecting (of the four), or a combination thereof. For example, a bullet fired in Space Invaders would only require collision detecting in the negative Y direction, but the player's ship would require it for 3 directions (if the aliens touch from the top, left, or right). Game engines should not be performing superfluous collision detecting! The game code needs to have direct access to the engine to control this. Games ported from Game Maker to GELLATIN+RRSSE will be blazing. 8-)