This Post was created -2014 02 02
Last wednesday, we thought we’d try to get some basic stuff to our Project up and running by the Sprint Review/planning on (last) friday.
We initiated the Game states StartState, the first screen containing quit, play and options button, GameState, in which the acctual gameplay is, optionState, change volume and such.
By “initiated” I mean just made the hpp and cpp files with some empty methods. We also made a StateManager to go with that that can change Active states. Why the methods in the states are mostly empty is because we dont exactly know how we will implement the other elements of the game because they don’t excist yet. You could say we made a skeleton for our states.
This job was done by David, the Lead Programmer
We also needed a few managers by last friday:
Input manager,
Game Object manager,
Draw Manager,
Sprite Manager
The Sprite manager also needed a sprite class to manage. This was made by Viktor, tha QA/programmer.
I have looked a little in there and they are initialized. I have not bended my mind over it yet.
The Draw manager and the Game object manager were made by Georgios. They seem to be in working order and finished.
The draw manager will be used to draw sprites and animated sprites and the window.
The game object manager manages the terrain objects, fish objects player and enemy, the light object of the player fish, trap objects and informative objects.
I did the Input manager. All though we use SFML and have a built in bool method of checking if any key is pressed, easy to use to change location of the player or anything else you can imagine you wanting to happen at a keypress event. However, we need to be able to toggle the light ball in front of the avatar to be able to save it’s energy. There will be an energy meter to the light to make the game a little more unnerving and also have a tactical element in the game where you can save energy if you will need it a longer time when it starts to get really dark for example.
What we needed was a function that only registered one keypress even if you would hold the key down from the beginning of the game and still were holding it after the game was shut down again.
SFML Does not have such a function built in.
I decided to do an input manager that Could execute both a keypress that is executed continuously while a key is pressed, like the built in SFML function, and a single key press to toggle light or reverse/forward. (yes fish reverse, http://www.aquaticcommunity.com/se/ciklider/tang.php the particular fish in this link not only reverses it eat other fish and grow 20 times it’s lenght)
To avoid confusion I thought it would be best to use the InputManger for both functions, I don’t Think it would look very nice if we checked both inputmanager’s toggle function and SFML’s key pressed function. Better to check both things with the same manager instead.
So how did I do this then? Well we had made a keyboard and a mouse class with SDL in the previous programming course that matched the criteria we had for input. The functions controling that were called IsDown() and IsDownOnce().
IsDown worked like this:
It checked for Key press events, when a key is pressed. If there was one it would return which key was pressed and that value, which is an integer, would be used to assign its corresponding element in a bool Array to true. This bool Array is a member of keyboard class and is called current, and IsDown is an accessor returning the current bool Array. in short, if a key is pressed an element is assigned true. If the accessor IsDown() is true, something should happen because then that key is pressed.
the event handling looked like this:
else if(event.type == SDL_KEYDOWN) {
int index = event.key.keysym.sym & 0xFF;
m_keyboard.m_current[index] = true;
}
and the accessor IsDown like this:
bool Keyboard::IsDown(int key) const {
return m_current[key];
};
when IsDown is checked whith a specific key(the keys are stored as enums which in turn are integers), and that value is the same value as the event value assigned to index, that key is indeed pressed, and you can start making things happen at specific key presses. This will activate the things associated with this specific key press every time the function is called during the time the key is pressed down which means many many times per second. very useful for movement, but a hell to toggle things with.
IsDownOnce, uses the same event type but the accessor is a little different. To explain this I need to inform you about Another bool Array member of the keyboard class; previous.
both current and previous are initiated in keyboard’s constructor to false. In a function called PostUpdate, previous is assigned the value of current. like this:
void Keyboard::PostUpdate() {¨
for(int i = 0; i < 256; i++) {
m_previous[i] = m_current[i];
};
};
SDL uses 256 different keyboard keys.
The isDownOnce accessor returns current but not previous. Like this:
bool Keyboard::IsDownOnce(int key) const {
return m_current[key] && !m_previous[key];
};
So what does this all mean? It means first the Event type keypress is registered at key press made by human player. It in turn sets the corresponding element of current to true. in a game loop you check key presses by Calling IsDownOnce(key). It returns true if the event has ocurred and does not return previous. A few lines later in the game loop, PostUpdate() assignes previous the same values as current and next time IsDownOnce is called, it does not return previous but tis time it has the same value as current and the keypress event is not repeted.
There was a mouse class as well based on the same principal as keyboard. What I did for the new prooject in SFML was I used the same logic but used the equivalent syntax for SFML and merged the two classes in one class, InputManager.
The event handling for key pressed looks like this :
if (event.type == sf::Event::KeyPressed)
{
int index = event.key.code;
m_Current[index] = true;
}
I thought I’d show you the postUpdate function as well because SFML uses a different number of keys than SDL:
void InputManager::PostUpdateKeyboard()
{
for (int i = 0; i < sf::Keyboard::Key::KeyCount; i++)
{
m_Previous[i] = m_Current[i];
}
}
Mikaela Designed the first stage of the fish, when the fish is cute still and it was awesome! There will be Pictures later.
Frida made The concept art to the enemy fish. also very nice!
Adam Started working on level design and corall walls. This is time consuming work and he is almost finished with it.
I fast paced the last Three members simply because I am tired.
The next week I will begin on a collision manager. I feel this is a big challenge for me because I am not sure how I will be able to do this. We need circle vs circle, circle vs rectangle and rectangle vs rectangle collisions and vectors of colliders to check. That’s all I know right now. I will start with getting the overlaping maths done, then I will try to implement it somehow. One step at a time.
Good Night.
Oscar Eriksson 