Team 12 is working on a game called DashBat. The game is going to be a mix between speed runners adm super mario kart, the player is in a flying state. To progress through the level the player needs to avoid multiple objects at a high speed and to reach the end of the level in a short time.
Today I will try to explain one of the artifacts that I have worked on during the past two weeks. and that is Menu State.
Most games need a menu state, to navigate between the available mode or controls for the game. But the artifact that i have worked on is a lot simpler than most menus so lets start analyzing what it is, how was it built and for what reason.
What…
The menu state is consisted of four components each differ in purpose. The first component is a background, the background is static sprite. In the future, it’s going to be an animated one. The second and the third component are the menu buttons, one to start the game and the other to quit. The last component is rather invisible, it’s a small rectangle shape that follows the mouse, the rectangle shape is used to detect if the it inside a specific area to execute an operation.
How…
Switching between states was done by checking if the rectangle shape is inside the start button’s sprite, when the condition is true, the current update function for the current state will return false, forcing the game to switch to the desired state. Since we use an engine, trying to communicate the mouse event through the other states was hard at the start, not only that the mouse positions was out of sync from the. This was easily fixed by getting the mouse position that is relative to the window that why, it return the exact values.
Why…
Other than the reason of to navigate easily through the game, I thought that creating a simple GUI was a good practice. Creating a well designed GUI is hard and it can get a lot harder when new elements are introduced, luckily the game did not need a very complicated GUI. So for that reason, I took that chance to practice a bit.
Beta is next week, so my team and I will focus more on polishing the game, so stay tuned for more !
Marwan
Are these my thoughts ? 
Hello Marwan,
after reading your post it become clear to me how you thought about making the menu screen and what your menu screen consists of. I think breaking down the text into What – How – Why parts helps a lot here. A screen shot is a must for such posts and as I see you have one, which is also very good.
If we turn to the menu itself, I tend to agree it will suffice to just have Play and Quit options in your game menu. The games we’re working on in this project are so simplistic that it wouldn’t make much sense to spend a lot of time on Options when a person will not probably replay such a game more than a few times.
The small rectangle shape you speak of is most probably a collider, so it could be useful to name it using accepted terminology – collider/hitbox/bounding box. What was the collision method used? Was it the usual SAT-based axis-aligned bounding box algorithm?
I would have liked to see the exact code you used to enforce communication between the different states, it is very interesting for programmers. (E. g., I used a rather dirty solution of writing a Transfer class which contains static methods that are as a result accessible from anywhere in the code. However, having statics all over the place is a sign of poor design, that will have to be fixed in the future in our code.) That would have made the post more informative.
In general, the game that you are working on is unique considering it’s a sort of a racing game (and we don’t have other such examples in this course). I am looking forward to the final version.
Good luck with the game development!
Rokas
LikeLike
Hello Rokas! Thanks for your feedback, I’ll try to include more code next time. As for the changing the states, every state has an update function which returns true to keep it running. Whenever a condition is meet like pressing the start button i return false instead forcing the state manager to look at the next state function to check with state should be activated.
bool StateManager::Initialize()
{
AttachState(“StartState”, new StartState);
AttachState(“GameState”, new GameState);
SetActiveState(“StartState”);
return true;
}
You can see here that the default state is start state to switch to game state i need to return false in the Update function inside startstate.
bool StartState::Update(float deltatime)
if (m_actions[ACTION_CHOOSE]&& m_mouse_selecter.intersects(m_start_rect))
{
state = “GameState”;
return false;// when the mouse collider intersects with the m_start_rect i change the state to “GameState and return false.”
}
if (m_actions[ACTION_CHOOSE] && m_mouse_selecter.intersects(m_quit_rect))
{
m_window->close();
}
return true; // here i return true normally if i want the state to continue running
}
std::string StartState::GetNextState()
{
return std::string(state); // the state manager will be looking for this, to check with “state” to switch to
}
I hope that this was helpful.
Marwan
LikeLike