Upgrading the Disaster Quiz (Week 3)

JUNE 20 – JUNE 27

We decided to set our sprints from Wednesdays to Wednesdays, so on the 20th we held our first proper sprint meeting. We reviewed the previous week, made major game design decisions together, and planned the next sprint.

The Disaster Quiz

For this sprint we decided to focus on the Worldmap and the disaster quiz, rather than the disaster levels (see last week).
During the sprint meeting, we decided to change what questions and answers the quiz would give. Initially, we wanted to present the player with three different indications of a disaster happening, and from that they would have to decide what disaster was coming. There were three answer options, three different disasters symbolised through an icon each.

We decided that this was not interesting or challenging, as they player would have effectively select the same answer for three different questions. Instead we decided on a format of three different types of Questions.
The first question was the remains of the previous quiz version: A Character tells you of their recent, worrying observation of the environment, and the player will guess between three options, which kind of disaster might be a symptom of.
The second question was a fact question, something like a “fun fact” about the type of disaster the player was about to encounter.
The third Question would be helpful for the disaster level, in our example case, the question was “where should you go in case of a flood?”, with the correct answer being “A High Building”. This high building, and the icon you click on to answer in the quiz reappear in the final level of the disaster event, so that’s how we connected the theoretical learning with a practical approach.

Stocking up the Backlog

Because we hadn’t made a lot of design decisions for me to implement yet, I asked for a lot more tasks than I knew I could handle, explaining that I would like to have things to do once I’m done with what’s necessary. So while my main task was to implement the changes we made to the quiz, I also spent time on the disaster level, again just the core things like turn-based logic and such.

Implementing the Disaster Quiz

First of all I added text to the answer Buttons in the Quiz, previously they were only images. I also added localization, written directly into the csv file that’s loading in the text.

quizData 06 27
Quizdata for the first quiz, from June 27th (smushed here to fit on one screen)

In the csv you can see from left to right: Name / ID of question, imagename (loaded in dynamically) of the character, displayed name in English, and German, imagename for a specific image that was supposed to be displayed, correlating to the question, which answer is correct, question Text in english, and german, and finally the answer Texts in english and german and the iconsname for answers one, two and three.

I also made another datatable containing information around the quiz itself:

quizQuestions 06 27
Quizquestions for the first quiz, from June 27th

From left to right: Name / id of the quiz (referred to from disastermarkers), names of questions one, two and three, name of the map / scene that should be loaded when quiz is completed, and a text in english and german that would show up when the quiz is completed.

quiz 06 27
Quiz Ingame, first question, and third question (Placeholder, programmer art)

And in action:


This is what it looked like in-game. Except for the placeholder art assets, that’s still what it looked like in the final version. You can see the data from the spreadsheets showing up here.

Disaster Level Prototype

As I said, the disaster level prototype wasn’t really in scope of the planned sprint, but I had downtime while waiting for design to finish (as I had expected) and I filled it with progress on the level.

disasterlevel prototype 06 27
Swipe movement, turn logic, and simple behaviour enemies.

Although not quite visible here because of the lack of delay, there is a turn logic here. The enemies move only after you move.

Source control

During this sprint and the next, other team members started using source control, so I had to do a lot of troubleshooting, which actually continued throughout the entire project phase.
I arranged with Tatjana that she would implement all art assets into the engine, and left the folder structure to her, except for the blueprints and datatable folders. Tatjana had experience with Source control, however on her PC, she couldn’t get Sourcetree to work and had to resort to gitkraken, which kept giving her and me headaches.
After committing some spreadsheets once, Andreas decided it was easier to give me the files through Discord, and let me implement them instead, so we didn’t need to troubleshoot together.
When Dmitry started working on the project the following week we had some initial challenges too, but he generally didn’t have any troubles using source control.

I had initially wanted all group members to use source control and have the project on their PCs, but unfortunately it didn’t end up happening.

Leave a Reply

Your email address will not be published.