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