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

The RRSSE!

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

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

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!