Programming Project 2 – Part 1

Hello again!

I have now started the next couple of courses, game programming II and An introduction to game development, those two courses work in tandem with us having been split into teams and tasked with creating a game.

The game we are making was designed by another group of students in an earlier course, in the beginning of our current course every team chose between thirteen different concepts and now we will try to create that game.

My role in the team is Lead Programmer, making me the ruling powerhouse of the coding, my first decree was to make the other members of my team declare all member-variables with a m_ in their names.

So, the first thing we did was to set up a SCRUM-document, as a part of the assignment and, more importantly, to learn the development-method, and in this document listing every artifact in the game by breaking down everything into its most basic elements (player->animation->walking->art for example). After finishing this backlog we started our first sprint-planning where every member of the team had to pick something from the backlog and then try to have it finished by the end of the week. I chose player movement, both walking and running, and to make some music play.

This was also where we decided to just write the entire alpha-version of the game-code in the Engine-class and not split it up into different classes until we had a functional game.

The player movement was really simple to do as we are using the SFML-library for C++ which has an innate Keyboard-input event. However, this was where my first coding-problem for this assignment arose, the event for key-down fires once and then, after a delay, starts spamming them. This was explained by the OS handling keyboard input this way, if you try holding down a button it will first write one and then, after a short delay, start spamming that letter. And as we needed smooth movement and not a half-second freeze this needed to be fixed. It was solved by chance when i tried just commenting out the if (event.type == sf::Event::KeyPressed)-code and just using if (sf::Keyboard::isKeyPressed(sf::Keyboard::W)) which returns true every iteration in which the key has not yet been released, fixing my problem with the delayed input.

Then I started to work on sprinting which basically just used another isKeyPressed with LeftShift, and when it returned true it doubled the speed of the player, just as it was intended to.

After this I made the music play which, again, was not that hard as SFML had innate sf::Music, the only thing I had to do was loadFromFile and play to make the music play.

That was my planned tasks for the sprint completed so I decided to fiddle around with the sf::Text and trying to make a stamina-bar that depletes as you run, using sf::RectangleShape as the bar and the text as a label just saying “Stamina”, strangely enough this all worked without any errors, all I had to do was set their positions and draw them out AFTER everything else so they would be visible above the level.
With the success of adding the first HUD-element i checked the SCRUMs backlog to find another task for the sprint planning and then asking the graphical artists to create some placeholder HUD-elements.
I just repeated the steps, only this time I used the sf::Sprite and the loadFromFile-method to get actual images into the game and not just boxes and circles.

I failed to take screenshots of these steps as I thought I had enabled the Dropbox-auto-save for screenshots but apparently I had not.

Well, that was the first week, and on the friday the three programmers (me, Sebastian Rosenblad and Viktor Nilsson) sat down and merged our work, adding from them a level loading from a textfile and shadows behind walls, restricting the players vision, the text file looks like this:

This system, while effective, is not really optimal and quite time-consuming when trying to create a large level so I will look into creating a level-editor to make it easier for our graphical artists to design levels, although that is not a priority right now.

This week we did the second sprint, in which I chose to continue working on the HUD, trying to implement a scrolling world and working on the design document for the game.

The most difficult part (or, the part that gave me the most problems) of creating the HUD was the timer, which needed a 0:00-kind of setup, and the best I could do was make it count with an sf::Clock that automatically ticks every second on its own, although this just made the timer ridiculous as it just kept going with no regards for minutes, making the timer look like 0:0200 after a while. So I made a quick workaround with if-statements:

The reason behind the name of the std::stringstream being ss2 was that there was another stringstream in the method that calls upon this method that apparently caused a clash between them, making the evidence count into the timer and the timer into the evidence counter, although it was kind of hilarious seeing the time as 0:00/3, it needed a quick fix and so i just named it ss2.

Making the world scroll was, again, relatively easy with the existence of sf::View which can you can set to have a specific size and position, and then set it using sf::RenderWindow->setView() I just made it follow the player with m_view.setCenter(m_player->getPosition()), this created a problem though, as the HUD needed to stay in place and not get left behind as the player moved away from the starting-position, fortunately the m_window has a getDefaultView()-method and after adding that to the end, just before drawing the HUD it was working flawlessly.
That is, until I decided that I wanted the view to stop following the player if he was nearing the edge of the playing field, this was actually pretty difficult to get to work right as it had to make several checks if it was near the top, top-left, left sides and so forth and then changing the views coordinates depending on which corner you were at. This was successfully fixed ten minutes before we we’re to show our teacher what we had made so far, the math for that fix was:

And the final result for these two weeks (with shadows activated):

Without shadows:

The player-sprite also rotates to where the cursor is located, which I made by calculating the tangent between the players center and the mouse and then converting it from radians to degrees and finally using the sf::Sprites setRotation()-method.

That is all for this time, thank you for your time and I’ll see you next week!