Awe+ Engine

ODE

2010-01-05T15:33:00.002-05:00

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:

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

2009-12-30T12:06:00.002-05:00

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?

2009-12-09T11:52:00.002-05:00

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

2009-11-24T16:38:00.002-05:00

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!

2007-12-26T20:13:00.000-05:00

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

2007-12-02T20:16:00.000-05:00

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

2007-12-01T23:04:00.000-05:00

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

The RRSSE!

2007-11-02T22:15:00.000-04:00

I just had an idea for a great way to start off this engine. First thing will be creating a "Really Really Simple Sprite Engine," that simply allows us to load up sprites and masks, draw them as one, and... that's mostly it. It will accept VERY few parameters other than the image's filename, and give you the bare essentials. We will definitely want to make this portable.
This will also allow us to do some other simple and fun projects without creating a completely new framework. And best of all, it will be our own. We can say, "I made this little game in a weekend. Nope--no Game Maker, that's written from scratch in portable C++." So not only will it be like 10% of the size of a Game Maker file, but it will compile on GCC for Windows AND Linux. You'll be surprised how a simple set of classes can make the process so much quicker.

Here's the basic stuff I think RRSSE should have:

IDrawable

Load, Draw, Step

Sprite class

Load - reads in the image and mask
Draw - outputs the mask + sprite to the backbuffer
Step - change the image depending on the image speed, according to the time interval
Other functions that allow you to specify the files, change the output location, frame speed (for GIFs), and ALSO, some functions for scaling and flipping the image.
Later, if we can figure them out, we could add functionality for screwing with the colors, inverting, making silhouettes, and possibly colorifying.

Brainstorming

2007-10-30T14:27:00.000-04:00

Before starting to make any of the classes, I'll try to list some of the things our engine must support. We of course need classes representing characters, and I'm assuming it would be a good idea to represent each attack with an object too. We also need some classes to do things that we see in other fighting games, like ways to represent text or images that are overlays, like countdowns, countups, "Finish Him"s, etc. Life bars, death counters, and timers in their own class, perhaps..? These kinds of "meters" are overlays that represent a changing value. Numbers and stuff that need to be displayed instantaneously might be a different kind of class.
All of this crap is going to go into a big list of things to be "Drawn()" and "Step()ped" in a particular order. Just like in Game Maker, these things will have an Order, which is like our Z-buffer. Backgrounds will be drawn first, then characters, then life bars, for example (but there can be unlimited layers). The temporary things that are displayed only for a few frames will be removed from the collection and delete themselves from memory.
We also need to think about the levels and menus. I guess they will both be derived from the same sort of "Scene" class like before, and we can make a more specific Menu base, and provide tools for making awesome animated "swoosh"ing menus.
Hmm... that's another thing I'm not too sure about: the pause menu. We'll need a feature of our collections to stop EVERYTHING, and allow another collection to proceed. And when a game ends, we'll need the collection to dump everything and clean up memory. So, maybe a Pause(), Resume(), Destroy() are in order?
Please list any other features and things you'd like to see, too. Thanks.

Introduction

2007-10-29T19:38:00.000-04:00

Welcome to the new blog, folks! I know the other game isn't finished, but working on two projects will let me work on one when the other frustrates me too much. I also want to take a different approach with this one. Every addition to the game will be detailed in a blog. I won't just post updates when some big new feature is added. Instead, I'm going to be posting dozens of times a week with every little update and plan, to keep everyone in the loop. If you don't understand a concept in the code, you can just look it up in the blog somewhere. We'll also need to make use of the keyword feature to make this system easier. I hope this means I won't be monopolizing the project, as long as every contributor blogs just as frequently!

Well, now I suppose I should describe the project. A 2D fighting game engine, upon which we can build many different fighters pretty easily. We can do this by keeping everything modular, in separate files that all work together to create a very simple, badass set of tools for games. I can actually use some classes I wrote for the 220 project, so I'll detail those in another post. In the meantime, everyone post their best ideas on how to make this the best fighter ever!