Arianas Travels

by Ladbon

Since the 19th me and five others have been working parallel to another Game Programming II course is a course named Introduction to Game Development.
From now on I will be blogging about how my position as lead designer have taken it’s toll and what have been going to my mind during the choices we’ve taken.

The development went through picking a finished game design document, had a brainstorm about what the group was able to do and specifically me had to make sure the scope set will be able to be finished before the deadlines.

Assessing the skills of each member had be made sure before the group could get the highest grade it’s able to get.  I guess the hardest part to think about was how to cut stuff out of the scope. Our programming skills wasn’t great but our artists will be able to create tons of different art so the group could have massive amount of art with very little code to show for it. I therefore had to change the main ways we play the game. The initial scope became a static hp bar that enemies wants to destroy it while you move around the hp bar shooting them down.

The group started with a blitz, I started making a power point presentation about this game using the formal design document we got from our teacher. The days that followed our producer Oscar started writing a document encompassing everything we’ve talked about and what I’ve written. Oscar starts writing down everything, schedule, scope, rules and even started with the MDA before the first week has finished.

So to recap the scope was made before we even started, the positions had already been taken, the schedule, game design and a power point presentation with a flowchart of how the program will be designed has been 90% finished. It has become clear that documentation wont be our problem but problems aren’t few.

The library the group will be using is SFML, a easy manageable set of commands that will make the programmers lives easier.

The difficulties the programmers in the group are faced with is how to create a foundation of code that can be build upon if the group ever reach the scope before the deadline(oh how naive I was). We decided starting with creating the states, engine and being able to navigate between them with key presses. I had the duty to create an input manager class suitable for our game while our lead programmer started writing the game in the SDL library so we know what we are getting ourselves into.

The difficulties we had with states was our inexperience with the code cause neither of us had the duty of writing it the last project. The programmer in duty of this is Laban. While I was implementing the code for the InputManager I noticed the problems almost immediately. SFML already has a way of getting real time input but not KeyDownOnce though it’s library could easily understand Mouse input in a way we want it. The reason I wanted an InputManager was because its worth the training and it helps all programmers understand a way of implementing an input class in a way that suits the game, not the inability of the library. I didn’t really invent something new here though, the last project had already made methods able to register input for probably any 2d game out there so we were in luck(!).
The issues I noticed was the inefficient way the states were written so I had to change the HandleEvent() and Update() method while I implemented a UpdateDeltatime()  method for the Engine. I even changed the way you run a window in the Run() method in the Engine with a bool instead of having Window.IsOpen(){} and but that method into HandleEvent in the InputManager. Problem was that the Inputs wasn’t going anywhere, in no way could we get any input to pass through the InputManager->HandleEvent(). After getting help from our brilliant classmate(Thomas Småland) we understood that having both m_running bool AND Window.IsOpen() into the loop in InputManager->HandleEvent() we changed it to:

sf::Event event;
while(window->pollEvent(event))
{
if(event.type == sf::Event::Closed)
{
running = false;
}

This effectively solved the whole issue and we finally could get the Input working and we were on track on creating the Sprite Class, SpriteManager class and the difficulties on creating a DrawManager(OH HOW NAIVE).

Again, being a lead designer I’ve become the guy that makes the tough calls. Constant calls of upgrading the game both from teachers and group members have made me think about what our future will be if we actually fill the scope. Before I finish this post let me show you a teaser of what I will write about next week:

*The programming roles we have and what difficulties and ease we’ve had with the development
*The more tough calls
*The directions of art the group are taking compared to the first design document

Now for a picture!

OK I have to give recognition to the people that helped us make this possible

*Laban Programmer(our group)*Tomas Småland(not our group)
*Viktor Lead Programmer(our group)

Thanks for reading, cheers and Much love.