Board Game Analysis - Game 2: Carcassonne

Introduction

The first assignment in the course was to play three different board games and make an analysis of them. Get an understanding of their components, core systems, properties and player behaviours. The goal with the assignment was to get a basic idea of game analysis overall. But most importantly, to get an understanding of game systems in order to prevent us in the future from designing the same game systems multiple times by mistake.

Game Description

Carcassonne takes place in a medieval setting, where lords are building and shaping cities and agriculture under their rule, constantly contesting for the best lands and investments.

Components

The game consists mostly of small cube shaped cards. These are tiles, depicting small pieces of a map consisting of roads, towns, cloisters and grasslands. There is no game board, instead the players slowly puts the game space into shape in the form of a map by placing one tile each round. All tiles have drawn pictures that are essentially compatible to each other. No matter how you angle the tile, it always seems to fit with the tile you’re placing it next to.

The game progress is measured in points, so the game also comes with a meter in shape of a very basic game board with up to 50 spaces to help keep track of the players’ individual points. Every gained point moves the player’s pawn on the board the respective amount of spaces.

The players gain points by placing out pawns on the game space, each player getting eight in total. One pawn is used on the meter while the others are placed on the tiles.

Game Rules and Progression

Before the game begins, a start tile is placed which has a part of a city, road and grassland depicted on it. This is the first tile, which the players can begin placing tiles adjacent to.

The players draws the tiles face down from a pile and has to show the other players before placing it.

The players gain points by placing their pawns as mayors, farmers, robbers or clergies. A pawn can only be placed on the tile the player has recently placed on her round. Mayors are placed on city tiles, farmers are placed on grassland, robbers on roads and clergies on cloisters.

The player only receives points when the certain terrain type the pawn stands on has been completed. For example: If a player places one of his pawns on a city tile, she only receives points from that pawn when the city looks completed with walls surrounding the buildings. As she receives the points, she also recovers the pawn that gave the points for further use.

The example described how mayors work. As for the rest:

• The robber gives points when the road he’s placed on is connected between a city, cloister or crossroads.
• The clergy gives points when the cloister he’s placed on is surrounded adjacently and diagonally by other tiles.
• The farmer gives points at the end of the game depending on how many completed cities the grasslands he’s placed on are connected to, with roads and rivers separating the grasslands.

The player cannot place a pawn on areas other players have already claimed, or place multiple pawns on her own areas. However, if she places a pawn on for example a city tile that’s separated but later connected to another player’s city area, she shares the points with the other player when the city is completed. Same applies to robbers and their roads.
However, farmers work differently. The players share the points earned from grassland areas if they have equal amount of farmers on them. But if one player has more farmers on the area than the other players, only she receives the points from those grasslands.

The game’s end phase starts when all tiles have been placed. Players receive points from pawns on unfinished areas but considerably lower amounts than from completed areas. Points from farmers on grasslands are calculated and given out. The player with the most amounts of points wins the game.

The version of the game used for this analysis also contained an expansion pack, which adds river tiles that are placed before the game starts as an alternative to the regular start tile. As the players places the river tiles, they can also choose to place their pawns on them as they also depict roads, a town, a cloister and grasslands.

Analysis

The game space growing and shaping after the players’ own choices is the core system. The players always place their tiles drawn from the pile to best suit their own agenda. However, it’s almost guaranteed that the other players will get involved and make use of the areas and tiles you placed for your own gain. Like chess, this game requires major strategic thinking. Trying to think several moves ahead and predict how the other players will act and react.

The luck of the draw however, can ruin and drastically change your plans. This makes the game a little bit friendlier for players that aren't so good with strategy.

Overall game process

Like with any new board game, the first two rounds were spent to learn and get used to the game. How the cities with mayors and roads with robbers worked was simple enough, but it wasn’t until the third game we all fully grasped how the farmers worked. Unlike the other pawns, the farmers are long term investments. You either have to think very far ahead or just hope that the farmers you place will have completed cities in their grasslands, the grasslands aren’t separated by too many roads and rivers and the other players won’t have more farmers than you placed on the areas.

Usually the players’ pawns would be spread evenly and connecting your cities with others’ was an often used strategy. The fact that the player has to show the others the tile before placing it ensures that the others will try to comment and affect her decision. During late game, a lot of discussion and debate happens on where the placement of the tiles and pawns would benefit which players the most. One strategy was to slowly build your tiles away from the other players’ influence; this however would also mean that the other players wouldn’t be able to place tiles that would be to your benefit as well. A lot of times, you either directly or indirectly help the other players with your placement of tiles. You can also sabotage for the other players by blocking off their unfinished areas or leave a tile two placements from the unfinished areas that are hard to fit.

Players would sometimes enter pacts to build cities together or work towards common goals, but ultimately they would try to lead the effort for their own benefit.

There were times when the players would sacrifice benefit for visual pleasure: Fixing a city that looked weird, building roads that actually connected to something, matching environments etc. The drawn art on the tiles compels the player to be creative and build a living and vibrant world with each placed tile, while benefiting the player as much as possible.

Targeted Audience

The game has a very mild nature and is easy to learn the basics of, although multiple games are required to get the hang of. Therefore, children in their early teens are most likely a good minimum. Almost all ages from there on and groups will enjoy this game. The game’s cover and concept however will sound a bit complicated at first and experienced gamers will associate it with city management games like Sim City, Settlers, Civilization, Populous and others.

Summary

Carcassonne is a unique game, considering that the game space is continuously built by the players each round. It gives a new level of strategy, as your actions can either limit your opponents’ actions or give them new possibilities and more room for their own plans. The game feels both competitive and cooperative, as you try to put a kingdom into shape while profiting as much as possible. It gives a positive feeling even if you lose, as you watch the results of you and your competitors’ efforts.

The art on the card tiles are visually pleasing and give out vibes of the old city management games from the late 80s and early 90s.

The game is a part of a franchise and has a pretty large following in Europe and the US, winning two awards. With up to nine full expansions and 20 mini expansions, the game can last up to one hour without expansions to several hours with expansions: Adding new mechanics, options, terrain, buildings, pawn occupations and in depth strategic elements.
The game has been adapted to consoles, PC and portable appsa and has inspired several new games and spin-offs.

The game can be very addicting. An experienced player we talked to even went as far as nicknaming the game “Knarkasonne” (“Knark-” being the Swedish word for drugs). With the random nature of draws from the pile, it’s always interesting to see what the game world might end up looking like after each game, which makes it hard for the game to get boring. It makes you wonder just how much of the experience is changed when adding all the available expansions for the game.

The game is recommended for any game board fan or casual player. Being a great blend of creative and strategic gameplay. It is best experienced with the maximum amount of four players, adding even more strategy and hectic exchanges in words between players.

Board Game Analysis - Game 1: Pandemic

Introduction

The first assignment in the course was to play three different board games and make an analysis of them. Get an understanding of their components, core systems, properties and player behaviours. The goal with the assignment was to get a basic idea of game analysis overall. But most importantly, to get an understanding of game systems in order to prevent us in the future from designing the same game systems multiple times by mistake.

Game Description

Pandemic takes place in a near future where four deadly epidemic diseases have broken out simultaneously throughout the world. You play as two to four members, each an expert in his or her own field to fight against the diseases. You travel across the world keeping each disease in check, preventing them from spreading out of control while researching for a cure against each disease.

Pandemic is unique in the fact that it has cooperative play. Instead of competing against each other to reach the goal or first rank like in most board games, the players are essentially competing against the game itself. All the players either win or lose depending on how well they cooperate and coordinate with each other.

Components

The game board is a map of the world where cities of high population density serve as the game space where player tokens can be placed. The player tokens can only move to other cities that are connected by lines to the city the player token currently stands on, unless using any of the other means of travel (later described).

Each player is given a certain role in shape of one of five cards that lists the roles’ special attributes.
The game relies on two categories of cards: Disease- and player cards. They represent outbreaks of the diseases, epidemics, research and resources for the players. The player cards have all the cities drawn on them. They can be used as either research or means of travel. The player can only keep a total of five player cards. If it exceeds that amount, the player has to discard one or two cards. There are also epidemic- and special event cards hidden among the player cards. The Disease cards also all have one of the cities drawn on them and represent the spread of the four diseases.
The four diseases themselves are represented by small wooden cubes in four colours, placed on the cities.

Six small house shaped blocks can be placed on the cities as research centers.
There are two meters on the board, the outbreak- and infection rate meter, each with a marker.

There are four markers placed on four spots on the game board whenever a cure has been found for each respective disease. On the other side of the markers is a small picture of a sunrise, flipped over when respective disease has been eradicated.

Setup and first round

As mentioned earlier, two to four players picks one of five roles: The Medic, the Researcher, the Scientist, the Dispatcher and the Operations Expert.
Both the disease- and player cards are divided in two piles, the draw- and discard pile. Nine cards from the disease draw pile are drawn to place the first disease cubes on the game board. Three cities gets three cubes, three cites gets two cubes and three gets one cube. The disease pile gets re-shuffled. The players all start at the city of Atlanta along with one research centre.

Game Progression

 At his/her turn, the player gets four action points which he spend on a set of actions:

·        Movement (either by moving to adjacent cities or using player cards).
·       Sharing player cards.
·       Treating a disease (removing disease cubes).
·       Placing a research lab.
·       Finding a cure, using five player cards of the same colour while standing on a city with a research centre.

Each of these actions can be done through different means depending on the player’s role. For example: The Dispatcher can move other players tokens as if they were his own and can move one token to any city with another token.
These five roles essentially specialize on one of the five actions. The Dispatcher on movement, the Researcher on sharing cards, the Medic on treating diseases, the Operations Expert on placing research labs and the Scientist on finding cures.

At the end of a players turn, the player draws two player cards and disease cards are drawn to place more disease cubes. The amount of disease cards that are drawn after each round depends on where the infection rate meter is placed which goes from two to four cards.

If a city that has three cubes received any more cubes, an outbreak is triggered and disease cubes are instead placed on all cities adjacent and the marker on the outbreak meter is moved one level.

If a player draws and epidemic card from the player cards, an epidemic is triggered. A disease card from the bottom of the draw pile is drawn and the city on it receives three disease cubes. All cards in the disease discard pile is shuffled and placed back on top of the draw pile. The marker on the infection rate meter is moved one level.

Five different special event cards in the player pile contain actions that the player can use any time during the game without using an action point. For example: “Government Grant” gives a free research centre that can be placed on any city on the board.

When a cure has been found for a disease, the players can remove all cubes for that disease from a city using only one action point (which the medic can do either way). If all cubes of that disease are removed from the board, the disease is eradicated and cards with that disease does not add any more cubes on the board.

There are three lose conditions in this game:

• If the amount of outbreaks reaches eight.
• If all cubes of one disease are placed on the board.
• If the player card draw pile runs out.

The players can only win when a cure has been found for every disease.

Analysis

Overall game process

The first round went as with any first try on a new game. Even if we studied the game manual thoroughly, we learned most of the rules during the actual gameplay. As such, there was a lot of fumbling, uncertainty, mistakes and misunderstandings.
The black disease in the Middle East started with most cubes and danger zones (three cubes). Therefore, three of the players remained in its vicinity and focused on keeping it in check. With a few unlucky draws from the disease pile and epidemic cards, two of the other diseases started to grow out of hand. The amount of outbreaks eventually reached eight and the round was lost to the game.

The second round when we pretty much had gotten used to how the game works, we tried to even out our zones of control. We kept the diseases under constant check but failed to use our player cards correctly. Instead of using them for research, they were used for travel and eventually the round was lost due to the player card draw pile running out.

It wasn’t until the third round that we started to notice just how useful the Dispatcher role can be. The role essentially made regular movement actions useless and a waste of action points. With his help, the players could always keep the diseases in check whenever it was absolutely necessary, without having to patrol back and forth using their own action points.
We started to pay more attention not just to our own roles, but everyone else’s. Instead of just using our turns out of our own initiative, we started to discuss every turn and action thoroughly. In other words, we started to play more as a team and used each other’s roles to benefit the team effort against the diseases. In doing so, we gained our first victory against the game. This is the game’s strongest point, when you’ve learned how to perfectly cooperate with your fellow players and conquered the game’s stressful patterns.

The fourth and fifth round became more or less a routine. Every player’s action was always discussed and the situation on the game board was constantly analysed. We started to notice that with our new strategy, we had essentially eliminated the individual player from the game. Every player token had merged into one single unit, to efficiently kill off any danger zones and focusing on gathering player cards for research. Since we technically didn’t have a human opponent, it became easy to predict any potential threats the game might throw at us and where to put our focus on.
In other words, the game became too easy, which is the game’s weakest point. Unlike in most board games which are competitive in nature, you don’t feel the exhilaration of victory and the satisfaction of outsmarting or outwitting your opponent. The game starts to feel empty, like there’s no point in playing it any further. It gives off a feeling that you’re cleaning a mess rather than playing a game.

One system that never seems to be put to use is the eradication option. Only once in five rounds did we ever manage to fully eradicate a disease. As this option seems to be only available in a later stage in the game, it’s never really considered. This stage is when we focused on gathering cards to find cures for the rest of the diseases, sometimes even neglecting to remove disease cubes.

Targeted Audience

Most likely, the game is targeted to youths twenty and up, but older teenagers could also fit in with its requirements. There’s a lot of strategic thinking involved with this game and you’re required to be able to coordinate with others. It helps to find interest for this game if you’re experienced with cooperative games and if you’ve heard or read about real life epidemic diseases.

Summary

The game is one of the most interesting and unique board I’ve played. What it mostly gets out of the players is coordinative talking, even though it gives an impression of a chess-esque strategy game. Most of the game process consists of long discussions between all the players on how to proceed. For example: How to spend action points most efficiently, how to make the best use of roles’ attributes (especially in combination with everyone else’s), when to focus on clearing disease cubes, where to place research centres etc.

This isn’t necessarily a bad thing, as it is a cooperative game. But slowly it diminishes your individual effort and all the player objects like the tokens and cards become the cogs for one single machine.  

The game feels chaotic at first as the diseases seem like untameable beasts. But slowly, a pattern starts to take shape which lowers the game’s difficulty considerably.

The eradication option feels almost unnecessary. Even if it makes things slightly more comfortable by not having to worry about a disease or two, it requires further use of action points to move to cities with disease cubes and more points to remove them. This option came late in the game rounds when we instead tended to move towards each other to exchange player cards and gather at research centres to find cures.

Since only up to four players can participate, there’s always at least one role that is left out of the game along with its attributes. We would always shift in which class would be left out, which made different combinations in attributes and a variety of strategies. This helps to make the game less stale. Other than that along with the shuffling of cards, there isn’t much else in terms of variety each round.

Indirectly, the game has a time limit or rather a turn limit. The players always has to pick two cards from the player draw pile at the end of the turns and when the pile runs out, the game is over. This helps in giving the players a sense of stress.

Overall, the game is a fun opportunity to get a sense of coordination and communication between you and your friends. But it’s recommended to play it once in a while between intervals. When playing several rounds consecutively like we did, the game becomes predictable and easy.

Escape - Group 4 - Week 9 - Level Editing - Part 2

3rd week working on the level design. With two weeks left on the project, I was supposed to spend the rest of the time to finish the last, largest and most complex level in the game. Instead, I spent most of the week to fix a mistake I missed last week.

When using the level editor, I sett the walls and outside boundaries by them dividing it into rectangles. I sett these rectangles by choosing coordinates for the upper left corner and the lower right corner. It is imperative when setting the rectangles, that I choose the upper left corner first.
Here is where I made a mistake. At one point, I did the opposite and chose the lower right corner first instead.

The reason why the walls are set like this, is because of the lighting- and collision system in our game. They works best and is most bug free when the objects are square shaped. So when I sett the rectangles, they're divided into a number of squares side by side with each other. The level editor is programmed to calculate the distance in width and height between the upper left and lower right corner and fill the space in between with equally sized squares.
So when I chose the lower right corner first, the level editor started to calculate infinitely in vain to find the upper left corner. This resulted in a oversized (366 MB) and corrupted TXT-file.

I didn't realise this mishap until the week after and so I had to start work on the walls in the earlier level all over again. Luckily, I had saved the TXT's in intervals and I didn't have to start everything from scratch.

As mentioned earlier, I'm now working on the last level of the game. The earlier levels took one week each to finish, but in comparison the last level has double if not triple amount of objects and triggers to place. In order to finish the last level as well as have enough time for the reports, I will have to work more intensively than I've ever done in the university line so far.

For 3 weeks have I focused on the level design and not so much on programming per say. It's what I get for volunteering to do this monotonous job. I just hope it doesn't effect my results as a programming student when it's time to write the reports.

Escape - Group 4 - Week 8 - Apparent Issues

Still working with the level editor, since we underestimated just how time consuming the process could be.
Another problem became apparent at the play-testing session last Monday. There was no way to test the actual levels. The lead programmer wasn't able to generate the levels via the TXT's until a few hours before the session. And so, testers would see weirdly placed furniture, empty rooms and run into invisible walls. Another problem was that if an object would be set so that the light wouldn't affect it, it would turn invisible.

The misplaced objects was an easy fix, but testers also complained about lacking level design. Saying that the levels were too void and that they entered the game not feeling motivated enough. The goal wasn't obvious and the NPC's weren't threatening enough.

It's true that there really isn't much that motivates the player to hide from the NPC's and get to the exit safely. After testing the game personally, I noticed that it was too easy to outsmart(-run) the NPC's. This might encourage players to just rush through the levels, rather than staying hidden.

How do we fix these other problems?
One suggestion might be the use of a time limit. The player has a certain amount time to complete the objective and find the exit. This might motivate the player a little more to reach the game's goal. This however might not motivate them to make use of stealth, but rather give even more reason to rush through the level.
The NPC's needs to pose more of a threat. In order for the guards to shoot, the player needs to stay within the guards line of sight (flashlight) for a certain amount of time. This is usually enough time for the player to escape and get out of their line of sight. If succeeded, the guard will simply spin around and later continue with his usual patrol pattern.
A suggestion to fix this, is to apply a permanent consequence for being spotted. This was suggested early in the development. The guard will report to the others on the level and every other guard will start to look for and chase the player.
The problem with this solution, is that the stealth gameplay would come to an abrupt stop. There would be no room for mistakes and the difficulty would be raised immensely.
If the player was able to hide from the guards and there would be a cooldown for the alarm raised, it would be less of an issue. However considering the difficulties of programming AI and the amount time left on the project, it's not likely this will make it into the final version of the game.

There's a lot of problems, many not even mentioned that needs to be fixed. Many of these problems weren't even noticed by us, until the play-testing session. Which proves even further the importance of proper outside play-testing.

Escape - Group 4 - Week 7 - Level Editing

After a few delays, the lead programmer gave the "ok" to start using his level editor for the project. As per the SCRUM-meeting for the week, I took on the task of using the editor to build all planned levels. Little did I know what lied in wait for me.

Using the editor and building the levels (or "sectors", as we call them for this project), goes like this:

1. A mockup of the level done by the graphics designers is loaded as a template.
2. Walls and outside boundaries are placed by setting coordinates for upper left and lower right corners of rectangles.
3. Props like furniture and other environmental objects are placed by setting middle point coordinates, angle in degrees and setting full, half or no light transparency for the games lighting engine.
4. Setting up the guards (NPC's) spawn points and waypoint patrol patterns.
5. Placing key-items.
6. Setting player spawn point and level exit.

After almost a week, I'm still working on one level and I'm still on the second phase. There's no undo-, move- or delete-function for the objects placed in the editor. The saved data is in shape of TXT-files, so every misstep has to be fixed manually by editing the TXT's.

In order to get the most accurate coordinates, I open the mockup pictures in Photoshop. I place the the objects as layers, read the coordinates and angle degrees. Then I switch back to the level editor and place the objects using the data from Photoshop.
The level sizes varies from 7000x7000 to 10'000x10'000. Following the mockups close to pixel-perfect is a very time consuming process and it became obvious that I wouldn't be able to finish this task by myself. Therefore, one of the graphics designers was appointed to help editing the other levels.

There are two reasons why we chose to build our levels like this:

• We wanted to avoid using a tile-system. We didn't want the levels to have a readable and blocky pattern, but to have a more irregular and interesting feel and design.
• In order to make our lighting engine work as well as possible, the walls and boundaries needed to be set into side by side squares. When setting the corner coordinates for the walls, the editor divides the set rectangles into a number of differently sized squares.

It's monotone and very time consuming work. But in order to give the player an experience as good as possible, I'm willing to put up with it.

Escape - Group 4 - Week 6 - Audio Options & Credits

Progress on the main menu is going surprisingly smoothly. Not only did I finish visual functionality in one day, but practical functionality is almost finished as well.
Both music and sound can now be muted and the slider for lowering sound works like a charm. This however has been tested with only one sound file. There's still a lot of work to make this work for every sound file in the game.
Music and sound has to be dealt with individually, since they work differently. Sound-files are loaded into game process and can be played and affected directly in-game. Music however, are streamed separately from the game and aren't loaded. Because of this, coding a function that affects all music is a bit tricky. Thanks to the sound manager, sound-files can be collected into one single variable. In order to make the sliders work for music, there needs to be code that makes reference for each music-file instead.
Muting the sounds is done directly in the sound manager. If a certain boolean variable isn't set to "true", the sound files can't be played. The music unfortunately has to be coded individually to be lowered down to volume 0. This is a pain, considering that the music will still be running in the background taking up memory space.
Nowhere close to setting up gamma in the options yet, right now I'm focusing on the audio and credits.

The hardest part this week was to get the credits-tab to work, strangely enough. The problem was that apparently, deltatime hadn't been implemented in the template my fellow programmer had given me the first week. So instead, I tried to work around this by using SFML's timer-system instead. It's much harder than it sounds, over a hundred lines of code went into making a decently working credits-tab.

The finished work so far:

In fact, it isn't that surprising how I managed to get this much work done so quickly. Since I had a lot of help, too much help in fact. During all this time, I was pretty much coached by the other two experienced programmers on the team. It seems that I just transcribed most of the code right from their mouths. At times, they were the ones writing it down for me.

This gives me a bad conscience. It feels like I can't take any sort of credit for the work done during the past week. Although I did learn a lot thanks to their help, so far it feels as if I'm just in the way of their work.

Escape - Group 4 - Week 5 - Sound Manager

In an earlier meeting with the advising 3rd year student, it was suggested that I shift my focus off the main menu and start working on something with higher priority. "Sound manager" was on the list in the backlog and as lead sound designer, I chose to start work on it.

To make my job easier, I searched the internet for existing open source sound managers. There were only two existing managers, strange considering you'd find many open source managers for example: sprite-, object-, level- and so on.
The one I chose was apparently for an earlier version of SFML and I was having issues converting it to the current version. I posted a thread in SFML's official forums, later that evening I received my first answer:
"The functionality that you want to implement is already provided by SFML..."

His argument was that SFML was already designed in such a way that it wasn't necessary to have a sound manager. The day after, I solved the issues myself and got the manager to work. Was he right though? It took about a week to get manager to work, was it worth it?

Granted, now that the sound manager is in place, it's quicker to load sound files and requires less code. But it saves about 2 minutes of time comparing to loading sound files the usual way in SFML. In the long run, I may have wasted more time than saving it for the project. I could've focused on other elements or finished work on the main menu.

However, this may have allowed us to save disc memory when launching the game. Instead of having to load sound files in every separate state of the game, every same sound file can now be accessed in every state from the same source. This also makes our game's file size smaller. It may have helped  optimize the game.

It may have been a slight waste of time, but it also may have been worth it to make our game more functional and stable. What do you think?


Work on the main menu has been resumed and hopefully the options tab will be fully functional within the next week. So far, I've only worked on the visual functionality (such as working sliders to control sound-, music- and gamma-levels). Also need to consider to add a fullscreen option after seeing a certain "psychotic" person, react to the lack of that option in earlier projects...

Here's a demonstration of what I've accomplished so far (including sound manager):

Escape - Group 4 - Week 4 - Start Menu State

This past week, I've been working on the main menu. The first state that the player runs into when the game starts. First and foremost, I've been working on the menu's visual function. Doing this first will make it easier for me to program the practical functions.

I decided to work on programming the main menu, because of my little experience with C++ and programming overall. Graphics was done by Henrik Forsman. The design is inspired by 1950s commercial light signs and film noir.

So far, I've managed to load:

• Background image
• Main Buttons
  - Lighting up when hovering mouse over them

          - Lit up permanently when selected (clicked on), until any other button is selected

• Selection Arrows
  - Appearing left of the buttons when hovering mouse over them

          - Lit up and placed permanently when button is selected, until any other button is selected

• Title logo
  - Randomly turns on and off every half second

  

Background Image

Drawn by Henrik Forsman. It's a picture of the room the player starts in the first level of the game.

Main Buttons & Selection Arrows

I think it's unnecessary that we need buttons that turns on and off as well as selection arrows. For selected buttons, it would be just fine if they were permanently lit up. The arrows are unnecessary in my opinion, I'm following Theodors and Henriks direction however.

Title Logo

It took a while to make its on and off cycle balanced. It easily got too sporadic or inactive. I've tried to implement a buzzing sound that plays while it's lit.

The idea behind the menu's design is that anyone who's watched 50s or noir films or anything inspired by them will immediately recognize the style and be put in the game's atmosphere, even before playing.

Comments

I'm starting work on the options tab and the sound manager. I'm not really happy with the amount of content I've managed to implement so far. My lack of experience is no excuse.
The rest of the team worked on the first playable version of the game, while my work isn't even one the main priorities of the project.

The sound manager will probably be easy to program considering how simple SFML is to work with. After I'm done with that and the main menu, it's uncertain what I'll work on when it comes to programming. Since I'm given the roles of level- and sound designer, it might be time I start acting them.

The start and lack of Progress

Ever since we received our assignment in programming, it's been a mess. My lack of concentration, experience and patience has left a big blank in my work.
All throughout the holiday weeks, I haven't been able to make much progress. Not only because I forgot my earlier work and files, but because of uncertainty. I had no idea where or how to start. The Engine? Sprite manager? Particle effects?
Mostly graphics and sound-work were among the things I could contribute, even though it's programming what I'm supposed to contribute with. My group member ended up doing the majority of all the work.

Now that I'm back in Visby with my old files, things are starting to pick up. I managed to implement a sound manager and further worked on the graphics. The sound manager is mostly based on what assistant Jerry showed during a presentation.

Still, I'm almost as uncertain as earlier. I obviously need to refresh and repeat on earlier learnings. I feel as if I haven't fully grasped how SDL works. Not quite the time for this realization, since we only have about two weeks left on our assignment. Nevertheless, I will make the most of my efforts.