[b]Terrain System[/b]

The terrain system is the manager of the tile/object layers on the map. It loads their attributes, allows you to manipulate them, renders the layers, and now animates them. Tile/Object animation sequences can be constructed by stringing together a series of tiles/objects to switch between at given intervals. The functionality is implemented in the engine, but is not yet supported by the editor. We need to make sure to bitch at Marcel long and hard enough to rectify that problem. ;)

[b]Camera System[/b]

The camera system actually took a bit of time to complete. With the previous builds of the engine, the Camera was a fairly static, clunky system. In ESGamma, the camera can be "attached" to any entity. This will enable us to change our focus during cutscenes, battles, or other events. Once attached to an entity, the camera can still zoom/rotate independently. We think the quasi-3D camera will offer cool shit for both battles and cutscene effects.

For scenarios where the camera needs to be free roaming, you can detach it from an entity and "move" it to specific map/screen locations. This will be powerful in Lua. (For example: Walk into a cave then the camera pans across the area with fancy text "CAVE OF DESOLATION"). 

[b]Sprite System and Component[/b]

This is a component with corresponding system that we have always been seeking to implement correctly. I'm finally extremely satisfied with our end product here. A "sprite" component may be attached to any entity to give it a texture. If this texture is actually a sprite sheet, you can define a series of animation "sequences" containing a set of frames (and intervals) to iterate through when playing an animation.

We believe that this will play a key role in helping you artists make truly kickass art and animation. We want to give you guys full power to define frames, position offsets, scaling/rotation, and other values for a given animation sequence. This functionality is complete in the engine, and once Marcel gets a chance to implement it into the editor, we will have the most powerful 2D animation engine that I have ever seen. I want a full GUI within the toolkit that has the sheet on one panel, the current sequence in another, then clicking on each frame allows you to their variables. We also want a play button that lets you demo your animations while you develop them.

Lets have a look at how this functionality is implemented in the engine:

The toolkit will allow the artist to create a series of "sequences" associated with a sprite sheet. A sequence is composed of "frames" that have attributes such as UV coords, offset position, time before next frame, scale, and a few more. The editor then serializes this information and saves it out to the entity file as part of the Sprite component. The engine then deserializes this data and reads it in to build a table with the different sequences.

For example, pushing the arrows on the keyboard causes the walking sequence to begin:

switch(dir) { 	case gyro::Vector2::UP: 		spriteComp->PlayAnimation("WalkUp"); 		break; 	case gyro::Vector2::DOWN: 		spriteComp->PlayAnimation("WalkDown"); 		break; 	case gyro::Vector2::LEFT: 		spriteComp->PlayAnimation("WalkLeft"); 		break; 	case gyro::Vector2::RIGHT: 		spriteComp->PlayAnimation("WalkRight"); 		break; 	default: 		break; } 

In this same manner, artists will be able to call their animation sequences from Lua. You can define anything from "Death" to "High Five" and call them in-game or during cutscenes. It's going to be fucking sweet.

[b]Timer System[/b]

Big deal, right? Believe it or not, movement, collision, and calculation in ES has always been frame-based. It was originally developed for the Dreamcast, so there wasn't really any room for varying performance on thousands of different types of computers. Now the game should run at the same speed on any type of machine. If your computer REALLY REALLY sucks ass (sub Dreamcast/PSP), you can disable the time-based movement and drop the framerate.

Anyway, the Timer subsystem will also reveal the deltatime and offer convenient time-based functions to Lua scripts.

[b]Party System[/b]

I wasn't originally going to overhaul the Party System.... but I did anyway. I wanted more versatility.

The "party" consists of "characters." Playable Characters may be changed by the push of a button (swapping Party leader/Active Party members), but then nonplayable characters such as friendly NPCs, enemies, or random helper characters may join your party and aide in battle without being playable.

The number of "active" party members is dynamic. The number of NPC party members is also dynamic. We hope that this will add to the awesomeness of battle in the game. Maybe super ultimate badass bosses or the last boss will allow you to use all 6 party members rather than three. Maybe saving some monsters from evil asshole monsters will make them temporarily join your party in an area and fight alongside you. Lots of kickass possibilities. 

[b]Multiplatformness and LibGyro[/b]

The engine is at a state of multiplatform-as-SHIT-edness. I spend half of my day working with XCode on a Macbook Pro. My home, leisure computer is Visual Studio on Windows 7. Our server is Kubuntu. Elysian Shadows runs absolutely identically on Windows and Mac--and for the first time EVER, we finally have a Linux build that is identical and ready to go. BIG thanks to MDK for that. He took what I had of the libGyro Makefile and absolutely pimped the living shit out of it. I will never have to write another makefile for DC, PSP, or Linux as long as I live...

The Dreamcast and PSP builds have grown ever-so-slightly out-of-date due to some minor changes that I have made to the libGyro API when I was screwing with the new CameraSystem. I'm going to quickly fix this within the next few days and have everything running identically on all 5 platforms.

[b]Engine/Toolkit AssetIO Joint Framework[/b]

There's so much shit that has gone on here that I can't even explain it. All of the time and effort that it would take to present it here would be better utilized going towards presenting the info in the Adventures in Game Development 17. You'll see it in the video. ;)

[b]Immediate Goals[/b]

All of our immediate goals revolve around reuniting the team and working together. We want you guys to be working with the engine and editor first hand. We finally have "invoke engine" in the editor, so that you can literally walk through your levels as you make them.

The very first thing you will notice is that tile collision has not been implemented. This is like my absolute highest priority. We at least wanted to get animation and the graphics-y things done for you guys so that you could already be working on areas while I do collision and the like.

[b]Repositories[/b]

Make sure that you have all of the repositories. They are going to be the key to our success. If you are interested in compiling the engine, it should compile 100% perfectly with X-Code, Visual Studio, or GNU Make. If you are interested in compiling the editor, it should compile perfectly on either of the three with QT Creator.

Make sure to check out the Project repository. That is where all stable, working builds will be placed, and where all in-game assets (like levels, characters, etc) will wind up. There should be a Windows, Mac, Linux, and even x64 Linux build sitting in there completely good to go. Marcel needs to get off his ass and put a stable build of his editor in there (for all three platforms) ASAP. Don't worry, I'll be bitching at him for it.