State of things

Yesterday I added a Font Engine to our code that I wrote for MUPPETS this summer. It can create any font in any style using GDI, but renders it as sprites on the screen, which is fast.

I also added a Menu State and successful transitions between Game State and Menu State. We had a little issue with input and single key strokes, but Ada fixed that up quick and all works well.

I created a skeleton class for the Battle State, so next I'm going to start work on that. It's going to involve a lot of planning on the IO side, we need a file format for the notes that are going to be played (IE keys that need to be pressed), their timings, and any sound files that need to be played / faded, etc. So I'm going to start working on the basic pieces of this, and then hopefully this weekend we'll get some music going and go from there.

We're thinking of a more traditional side-scroller on-rails shooter type game for the "exploration" mode. So if someone else wants to start thinking about how that's going to work, and start thinking about collion detection for the bullets and stuff, that'd be cool. Some questions: How are we going to aim? (whammy bar?) How precise will the aiming be? Will it be timing based? What's going to happen when they play a note? if music is played, how is it going to sync? Will there be music in the background?

In other news, word on the street is that we may have lost our art guy, so that's going to be trouble.

But things are moving along. I don't have any word on the XNA port yet, but I'd rather keep working on the actual GAME part of things rather than rebuilding another engine. If there's no fun game, whats the point of 2 identical boring engines?

-p3000

State Switching Implemented

So, I spaced out in some class today to think about the State Switching implementation, and ran home to code it.

It's simple. Essentially there's a GameState Interface, which all States conform to. This interface contains methods like Draw, Update, OnReset, etc. Then we have a GameStateManager, which implements the GameState interface, and also contains a method for switching the current state. So when we want to switch from BATTLE mode to MENU mode, it's a simple method call, and the GameStateManager automatically forwards the calls appropriately.

It's all committed to SVN, so Ada, you can maybe help out Baker with the XNA port for now.

-p3000

Sound Timing

I implemented a sound timing class tonight, and tested it out by creating a simple speaker looking object in GIMP and having it pulse at 120 beats per minute. I wrote a Speaker class that extends Sprite to take care of the graphical side of things. The sound timing class should be pretty robust and should help us with things from graphical pulsing to note timing detection.

I'm hoping this leads us in the right direction to start implementing gameplay. I asked Ada to work on a state pattern so we can have different states like the menu, rails mode, battle mode, etc. So maybe I'll start working on the battle mode stuff next now that I have a better idea of timing.

-p3000

DirectInput Stuff Committed

I've finally committed my DirectInput implementation into svn. The controls are now F1 and F2 for moving, and 'h' for displaying the configuration UI. If you are running on your home machines you will be able to change and save configuration changes.

I will start making my own configuration UI just in case we can't get access to the required folder, and also looking at the input implementation for XNA.

Btw, I'm getting an error window pop-up when I minimize the game window and then restoring it. It's the same error that Ed had last on Wednesday night I think. Pete: don't know if you can fix it. On that note, I think we should have a topic on the forum that's on bugs that we found.

Player / Camera Path Design

I further thought through my position path issue, and I decided that a 3 point bezier curve would work best for the situation. The equation is simple, and we can get it to do exactly what we want. So now the question is implementation.



Here's a quick diagram I drew up after thinking about it a bit. I decided that it would be best to split the points into segments. Each segment would either contain 2 points if it was a linear path or 3 points if it was a bezier curve. A segment can return a specific point within it between 0 and 100% of the segment. A path is an ordered collection of segments. The player object will be able to query the Path for it's current segment, and then ask the segment its current location.

I think this will work out nicely, I have the header files laid out, I just need to write the implementation. One issue that may crop up is that the player and camera are going to have to communicate so the player can basically billboard so he's always facing the camera. Friending classes will probably work okay.

Lollerskivvies and I laid out a basic world design on the whiteboard today, I may visio-ify it later in the week. Basically, it got us really excited for the world design phase.. which should be coming up very soon!

Camera and Player Movement and Orientation

Last night "lollerskivvies" and I discussed player and camera movement and orientation in our world. We drew a little diagram on the whiteboard which I later replicated in Visio shown here:


Our tool, which lollerskivvies is developing, will be able to define points which will construct the player's path, along with points to construct the camera's path. At this time, we decided that it would be best if these points were 1:1, as to not screw up any timing issues.

I figured I would use quaternions for the smooth camera orientation interpolation, I have done this before and it works great. The problem I'm facing now is how to get a nice curve for the position interpolation. If I just LERP betweeen points, the character in the above diagram could cut straight through a wall. I briefly looked into spline generation, but most algorithms involve defining more than two points. I could possibly just use the circumference of a circle as the path. Eh, it's something to think about.

In other news, lollerskivvies and I got his particle system running at a framerate independent speed last night, so now fire looks as sweet on my laptop as on the alienwares in the lab.

Forum

There is now a forum dedicated to our project at http://ohnoes.repins.net/

Go ahead and post any issues or concerns or things that you want to discuss with the team there... and check it often!

Milestone 1 + Source Control

Milestone 1 is now under SVN source control, so everyone can start contributing their individual research code at this time. The address is svn://repins.net/svn/ and a password has been mailed to your rit account. Once we get back we'll have some major integration and things will hopefully start falling together smoothly.

I also did some profiling on our Milestone 1 code and tried to find some bottlenecks, but everything seems ok. I think the fact that we're using huge 512x512 32 bit textures as test samples is part of the reason why the framerate isn't as high as we'd like it to be. We'll talk more about this later, but now we have some decent profiling code that I wrote for future issues.