Board Game Analysis – Carcassonne

As our second board game to analyze we chose Carcassonne and I am happy we did. It is a great easily accessible game with a simple and refined core mechanic.

The name of the game accually comes from a french medieval town, famed for its city walls. It was designed in 2000 by a german board game creator, Klaus-Jürgen Wrede.

The game is a competitive multiplayer game for two to five players. In short the players build a landscape together using tiles and try to gather points while doing it. What works in Carcassonne, what doesn’t? This is my analysis of it.

Core game system

In Carcassonne the board build system is the core game system. It governs the possibilities of how the board will look and also the possibilities presented to each player on their turn. The tiles must be placed so that they are legal according to the game rules. Every player has seven markers, commonly known as “meeple’s”. When a player’s turn starts he or she draws a location tile and places it were ever he or she wants. After having placed it, the player can place a meeple on the tile in a number of ways to score points. Some ways are short term and easy to complete, other ways are long term and doesn’t complete until the end of the game. When a meeple scores meaning it’s task is complete, the player gains points and the meeple returns to the player.

Here are the different types of meeple placement:

• On roads: Robbers. They are complete when the road ends in both directions.
• In cities: Knights. They are complete when the city is complete.
• In monastaries: Priest. They are complete when all tiles around the monastary tile are placed.
• On the grass (lying down): Farmers. They are not complete until the end of the game. Special scoring rules apply.

You need to manage your meeple’s so that you don’t run out of them, unless you want to do that. There is an advantage to having at least one unused meeple for scoring additional points. This and the differences in the types of scoring types build a foundation for strategy.

The tiles look very different but are easily connected through their simple system. A border of a tile must match all other borders around it where it is placed. There are only three different border types: road-border, grass-border and city-border. Using this simple system it often is easy to fill an empty spot of land where you desire.

There is a rule that says that you cannot place a meeple in an area where there already is one placed. However, you could place a meeple in an adjacent tile, pretty close to the one you want to add your meeple to and then try to connect them later in the game. There are a couple of risks involved though. If you want to add your meeple to let’s say a city and you place it close to another not complete city, the possibility exists that another player blocks you out by walling in the city right by you or by completing your city directly, which gives you less points. Another possibility is that they add another meeple to the city by doing the exact thing you are trying to do, adding a meeple to a tile close by. A player with more meeples than any other player in a city when it completes get all the points while the others get nothing. The same goes for farmers but not robbers (roads).

Meeples placed but not completed are scored in the end of the game using a slightly different score system. Some jobs, like robbers (roads) are scored in the exact same way, earning just as much points as if they where completed within the gameplay phase. Other jobs, like the knights (cities) earn less points when scored after the game, making them a better investment if the city is completed during the gameplay phase.

We played the game several times with and without the river expansion. The river expansion makes the game a little lengthier but without affecting much of the core mechanic. When using this expansion, the players will draw tiles only consistent of river tiles to begin with and then moving on with using the standard tiles. The river tiles have specific start and an end tiles. I would say that the game does not differ much when using the expansion or not but it adds to the gametime and the total game field which is a bonus.

Most interesting system

The player strategy and diplomacy system is very interesting to me. You can invest in several different types of potential point gathering types, making other players help you get the points is very interesting. The players that you convince need to get something out of it, owe you or you can offer them something in the future. This is where the diplomacy comes in to play, working together with other players and convincing them that you are not the biggest threat. If you are considered the biggest threat or the player most likely to win, that makes it harder to get players to help you and your ambitions.
Some point gathering systems are more long-term but often offer something else in return. Each type of point gathering system has it’s own risk, reward and dynamics. One thing corresponding well with strategy is how easy or hard it is to spot the potential points of a certain marker. Potential points from farmers for example can be difficult to keep track of during the game, while robbers along roads are easy to track. The possibility exists to make use of this when playing a strategy as well.

Another thing that connects well with player strategy is the dynamics of getting players to want to help each other. Many of the types of scoring connect with each other in ways that endorse team play. In our play throughs a good deed to another player does not nessecarily mean a lengthy team work between the players.

Best part

This game is genious in it’s design. The players get to architect a landscape and there is no way to predict how it all will look from the start of the game. This is a good part of the game, the creative freedom, but it is not the best one in my opinion.

The player strategic choice is the best part i think. There is actually a way to counter every type of point scoring and when I say strategic choice I don’t only mean mechanics wise, I also mean by diplomacy. I could for instance help another player if I think that will help my progress in the future. People may join forces to prevent them both using too many meeples while battling each other for superiority in a city or farmland.

Playing a certain strategy might not be the best way to think of it though since you need to adapt to the tiles you draw. You need to see possibilities in how to gather points in the most efficient way when drawing. Also, you need to show the drawn tile to the other players and that almost always means hearing many suggestions on how you should place it.

The worst part

I have a problem identifying bad parts of carcassonne since I believe it to be one of the best board games out there. I don’t wish to complain about anything in this game but objectivly I would say that the randomness is the worst part about it. There is the possibility that one draws mostly road pieces, which is arguably the worst type of piece, for several turns rendering one unable to progress in any other way than farmers or robbers.

Compared to other board games I would say that the randomness in this game is medium. There is a factor of randomness but there is also a big factor of choice, strategy and diplomacy. Also, taking away the randomness of this game would in fact destroy it in my opinion. Still, players want choice and randomness is not choice.
Making this the worst part of Carcassonne actually says something about the game, it is very well made.

Target audience

The target audience is extremely wide. It’s a game that anyone can play, even players not accustomed to board games, and therefore Carcassonne can be seen as a gateway game into the board game scene. This is the that does this best among all board games I’ve seen.
It can be played with friends, a family can play it and all it’s members could join in unless they are under the age of 8 as is recommended on the box.

Player types who should enjoy this game are point gatherers and creative players. Logic is always a factor, but I would say that this game works well for the logical player and the artistic player. The logic part of the game is the strategy and the artistic part is the creativity in creating a good looking landscape.

Summary

It’s simple, refined and polished core mechanic makes Carcassonne my favorite board game that I’ve encountered. There is suspense and all players are part of the game until the very end.

The system is built up so that people are encouraged to work together in the game making it a competitive yet in some ways cooperative game. This, and it’s appeal to both logical thinkers and artistic people, is what makes the game so accessible. It has components that stimulates many different types of players at the same time and is therefore a great gateway game into the board game scene.

I strongly recommend this game to anyone, gamer, board gamer or no-gamer.

Board Game Analysis – Pandemic

Me and a group of fellow students have played a board game called Pandemic and this is my analysis of it.

Pandemic is meant to be played by two to four players. The game board consists of a world map of earth with capital cities used as locations. Each location/city on the game board has a color. There are four different city colors, the same amount of colors as there are diseases in the game.

The goal of the game is to work together to find the cures to all four diseases before any of the loose conditions happen.

Before I list the loose conditions I will familiarize you with the core game system and its components.

Core game system

The core game system revolves around components called disease cubes. These cubes are essentially tokens colored in their respective disease color.

When the game begins, disease cubes are spread across the game board randomly by drawing infection cards. The infection cards only have one property, which is the city that it is supposed to interact with. At the end of each player’s turn, he or she draws two types of cards, player cards and infection cards. Infection cards result in the placement of disease cubes in the cities that are displayed on the cards. Player cards can be used in several ways, one of which being to collect five of a certain color in order to cure a disease.

There are two major tasks any player can focus on, the first one being removing disease cubes from locations/cities and second one being finding cures for diseases. If more than three disease cubes are placed on any one city, an outbreak is triggered and disease cubes are placed on adjacent cities instead of the targeted city and an outbreak counter is heightened. This outbreak can cause a chain reaction, causing more outbreaks if any of the adjacent cities also have three disease cubes on them.

The loose conditions of the game are:

• Emptying the supply of unused disease cubes of any color.
• Emptying the draw pile of player cards.
• The outbreak counter reaching a number of eight.

A typical turn

A typical turn starts with the player figuring out what to spend his or her actions on. A player can choose to do up to four actions in one turn and in any order. This is the most interesting system in the game in my opinion and I will go through it in greater depth later in this analysis. The system creates strategy and promotes discussion among the players.

When the player has spent the actions he or she will draw two player cards. The player cards consist of city cards, special event cards and epidemic cards. City cards can be used in many different ways of which I will explain later, but one I have already mentioned. They can be used to cure a disease if a player owns five cards of the same color. Another type of player card, the special event card has a unique action attached to it that allow the player who holds it to perform this action. The action is instant and costs no player actions to use. It can also be played on any other players turn. The effect of these special event cards differ greatly. An example of a special event card is the “forecast”-card which lets the players choose what upcoming cities will be hit by disease cubes by choosing the order of the top infection cards draw pile. The last type of player card, the epidemic card, sets off an epidemic which greatly spreads the disease cubes on the game board. Using any of the player cards in almost any manner discards the card and it is removed from the game.

After the drawing of player cards, a number of infection cards are drawn to continuously increase the number of disease cubes across the game board. The number of infection cards that are drawn is based off a counter which is heightened whenever an epidemic cards is drawn (the epidemic card is a type of player card, as mentioned above). For each card drawn a disease cube is added to that city in the city’s color.

When the infection cards have been drawn and the disease cubes are placed on the game board the turn is over and the next players turn begin.

The most interesting system

In my opinion the most interesting system in the game is the player action system. During a player’s turn he or she can choose to do up to four actions of any allowed type and in any order. The player has the freedom to choose what to do with each action, but that is not all. Players need to work together in order to succeed in the game which promotes discussions on what to spend the player actions on. This freedom and the strategy, discussion and team work that this creates is why I think that this system is the most interesting in this game.

In short a player has a choice of moving, removing disease cubes, researching cures and trading cards with other players.

In more detail the different player actions are:

1. Move – Standard: Move the player pawn to any adjacent city.
2. Move – Fly to: This action moves the player directly to a certain city. The player must own the player card of that city and it is discarded when performing this action.
3. Move – Fly from: This action moves the player from a certain city to any city on the map. The player must own the player card on which he or she is standing and it is discarded when performing this action.
4. Remove disease cube: Remove one cube from the city at which the player pawn is located.
5. Build research facility: Place a research facility on the city in which the player pawn is located. The player must own the player card for this city and it is discarded when performing this action.
6. Treat disease: If a player owns five cards of a certain color, he or she can treat or cure the disease of that color.
7. Trade cards: Trade a card with another player located at the same city.

Regarding the strategy connected to the player actions, there are five different player classes. Each class does one type of the available player action especially good. Since the player count is between two and four, there is always at least one player class not present in a play through. This adds some depth to the game, since each play through there will probably be some variance to the player classes existent in it.

Target audience

Pandemic should appeals to strategists who like discussion. The box recommends a player age of ten or higher. This is a very social game and I would recommend good friends to play this for fun or players that want to get to know each other better to play this game since there will be consistent dialog between the players.

Pandemic is a cooperative game which should make it appealing to non-competitive players. Victory or defeat is shared among the players, which probably makes the game more fun for players who does not enjoy playing competitively.

The game is based around strategy, which should appeal to intellectual players that want a logical challenge.

The best

The best side of the game in my opinion is the balance. We played a total of five times and in more than half of the play throughs the win and loose conditions were one or two player turns apart from each other.

I would consider us mediocre or slightly above mediocre players in skill and we lost our first two play throughs. Each time we lost, we were very close to winning the game as well. We then proceeded to win our last three play throughs after gaining deeper knowledge of the dynamics of the game.

To balance this game to a degree such as what they have done is impressive. It has probably seen its fair share of game testing and who doesn’t like a polished game? This is the best thing about Pandemic.

The worst

The worst side of the game is in my opinion is one of the player classes. Each player class has an improved action type. The player class I am referring to is the class called “The Dispatcher”. This class is specialized in the movement player action. His abilities make him able to move any other player pawn as if they were his own and additionally he is able to move a player pawn to any other player pawns location on the game board. You can easily see that with his abilities the choices you will have are increased tremendously.

Since this game is to a large portion focused on strategy and promotes players to think many steps ahead, having the dispatcher in the team makes it extremely hard to choose what to do since the options are nearly endless.

I am aware that this problem only exists when this particular player class is in play and that it gets worse with more players participating in the game but this was the only big thing that really made the game less enjoyable in my opinion.

You could argue that this player class adds depth and is a good thing but I would argue that it is bad, simply from experience with it. Sometimes having restrictions in games is good and this is one of those times.

Summary

To draw parallels to what a pandemic of this scale would look like in real life, this game makes the players think strategically much like you would in such a situation. Having good communication would also be key and that is one of the main features of Pandemic. Also sending in specialists to travel across the world to defeat the diseases is really the core theme of the game and I think they nail it really well.

The heavy focus on strategy in this game is one of the major key features of it and when playing it for the first time it actually isn’t that difficult to get a grasp of the rules and how to play the game. Having a semi deep core of strategy dynamics and still making the players feel like they know what they are doing is something I like about this game. As with any strategy game, or perhaps any game at all, when having played it for a while you get a greater understanding of the dynamics and therefor are better at manipulating the game to your favor. Us losing two games and then winning three made this a joyful experience, we got a feeling of knowledge and skill progression. A thing that made the game a challenge was noticing the most imminent loosing condition and to try and prevent it. These conditions can be relatively hidden and it is satisfying to find them in time to do something about them.

We played a few games with four players and then a few with two. After doing that my reflection on the balance is that it is very well balanced in this department as well. Having fewer players in the game means that you have less special abilities to make use of, but the ones you have come more often. This is balanced I think. Then you have the aspect of how many players the player cards are distributed amongst. Having fewer players in the game means that the chance of one player finding more cards of the same type is higher since the cards are distributed among fewer players. This is an advantage. The coverage of the game board, however, is worse with fewer players which mean a disadvantage. To balance this must have been hard but in my opinion it is balanced and they did a good job with it.

There is also an option in the manual to play the game at different difficulties which could potentially make the longevity of the game better. Personally I was getting bored of the game after our five play throughs and even with this difficulty option I would rather not play any more of this game right now. Perhaps I’m not part of the target audience or the game isn’t meant to be played five times in one week.

All in all I think Pandemic is a great game and I’m impressed with the polish and balance of it.

Game dev, Suit’em up – The final game, S.W.A.G.

The game development course is over and I’m happy to give you a link to our final game.

I hope you enjoy it:
S.W.A.G.
Silk, Wool And Grublings
https://docs.google.com/file/d/0BwHHN89IE1YzSUo3SHljYm5XNWs

Game dev, Suit’em up – Ingame cinematics

Me and Jonas have worked hard on player feedback this week since it is the one thing that is missing from our game. He worked with boss healthbar and feedback when getting hit.

Malin has worked with particle effects for even more feedback. We need to implement them next week.

I made two really crude in-game cinematics to enhance the player feedback when the avatar is killed and when teleporting. I havn’t made cinematics with C++ before and I didn’t bother making classes for it. I took the easy route and only used float timers for checking the progression of the cinematics.

So the principle goes something like this:
When the timer is above 2.0 seconds, update one thing.
Then when the timer is above 1.5 seconds, update another thing.
And so on until the timer reaches zero.

When the cinematic mode is turned on the avatar stops updating and the player loses all control over it.

Teleport to start cinematic.
If the player stands on a warppoint a certain time (currently five seconds) the teleport cinematic is started. While standing on the warppoint, tweezers comes down from the “sky” towards the warppoint. It picks up the avatar and places it at the vicinity of the first checkpoint, right below the starting room.

Here are the different parts of the teleportation cinematic.

The graphics for the tweezers is made by me, it’s a placeholder until we perhaps will get a real one from our graphic artists. They have much to do and the final week is approaching so it might not get changed.

Avatar death cinematic
Previously the avatar was instantly teleported to it’s checkpoint and play testers have given us feedback on it. There needed to be a short death scene and we have planned to have one since the start. Player feedback was a big deal that we hadn’t really thought enough about when designing the game. This part is starting to shape up now towards the end of the project!

When reaching zero life through getting hit by an enemy or their projectiles the avatar is now blown up. The head, body and weapon sprites are sent away in a random upward direction and the legs are left, just standing where the avatar died. The tweezers then makes it’s appearance again and sets a “new” avatar down at the current activated checkpoint. We plan to have a Malin’s particle effect with screws and cogwheels when the avatar dies.

We are also planning to make the legs work as a tombstone, to be left where the avatar died. Also the legs animation is frozen when dying because the player isn’t updated anymore. The plan is to keep the sprite in the frozen state and give it to a tombstone. The avatar then gets a new pair of legs.

Pieces of the avatar fly in upward random directions when dying.

We were planning on another round of play testing with friends and family but it is too late now since we will not be able to implement any suggestions in this final week that we have left. Instead we will release the final version of the game when the course is ended. I will probably put a link to it here on the blog next Friday.

Game dev, Suit’em up – New polish features

We have recently had our second playtesting session, the pre-beta one. We got a lot of great feedback to work with. The one thing I think we need to add desperately at this point is player feedback. Another thing that needed to be added, which came up during the playtesting was that playtesters thought that it was boring running long distances across the world.

I’ve been working hard on the second point, the “boring long distances” these past few days and I’m happy with the result. We have added two features to prevent this, destructible objects and checkpoints.

Destructibles ingame (the flies follow the avatar):

Checkpoints ingame:

The graphics for all new things above (you should see the animations!) are made by our excellent graphic student Måns Löf, a talented man in everything he does. He is working on graphics and audio for the game.

The destructible objects are a two-part feature, there are the actual objects, the eggs and there are also flies that come out of the eggs. The eggs are stored in a std::vector as base class Object*:s. Their locations are loaded from a text file and they are “destroyed” with one hit from a player projectile. When they are “destroyed” the egg breaking animation is played and flies are spawned. If the egg is outside the screen for 10 seconds they are renewed.

The flies are a type of EnemyObject alongside all other current enemies. They have no attack damage and a custom AI called “Chase”. When they are inside of the player aggro-radius they are calm and if they have had a direction they travel around the avatar in semi-random directions with a low speed. If the player tries runs away from the flies their movement speed is increased and they run kind of toward the player. What i mean with “kind of” is that they move towards the player with a random offset so that they seem more like flies in a flock. There is no flocking behavior implemented and it’s not needed for our feature, this behavior is actually really nice as it is if I may say so myself. If you get a chance to try our game i suggest that you gather a fly army. Try not to kill them all, they think of you as their mother. That’s why they follow you around. :(

Onward, to the next feature! The checkpoints. They were made really simple, as stationary objects placed on certain locations in the world. Then the avatar collides with them, the avatar spawn location is moved to the checkpoint and the checkpoint plays an activation animation.

I also made “speech” bubbles of two types. Timed ones and area-based ones. They are attached to other objects with an offset and follows their parent object around until they are removed. When approaching the first hidden rooms, one of these bubbles appear over the avatar. That’s an area-based one. When exiting the area, it is removed.

Timed bubbles appear over certain enemies heads when they are aggroed. There exists graphics for the bubbles but I only use placeholders right now.

The speech bubbles look like this ingame:

That’s it for today. Thanks for reading!

Game dev, Suit’em up – Animations in different directions

We have released a friends & family beta test and gotten some statistics of the current status of our game.

You are welcome to participate, here is the link to the feedback: feedback-form

And here is a link to the game, please fill in feedback if you play!: -here was once a link- (I will get you a fresh one as soon as we release another playtest)

I have made animations work in different directions for enemies and the player. This is not implemented in the version I linked above but I will explain what is different now.

The enemies now have animations in four directions. When they move in a direction, all moving objects have a direction vector. It is a normalized vector, meaning it can only be between 1.0 and -1.0. And since this game is in 2D and we use SFML we have an sf::Vector2f with two different dimensions, x and y. Each one of these are normalized and the calculation for moving an object goes something like this:

pos.x += deltatime * direction.x * movespeed;

pos.y += deltatime * direction.y * movespeed;

This picture might make it more clear:

So when setting animations on enemies I want to check what way they are going. I then use the enemies direction to decide which animation to change to. So check this out, between the red lines is where I want to change the animations.

The direction/animation check is run each update but there is a check if the current animation already is correct. I only _change_ the animation if the animation isn’t correct.

I’m not certain that my code is optimal for this, but here is what it looks like:

We are thinking about making this so that the up/down animations only trigger within 0.3 direction up/down instead of 0.5, which makes the right/left within 0.7 left/right which makes it kind of like this:

We will try it out and see if it looks okay.

I have also split up Barney’s sprites even more. Previously there were four different sprites: the body, weapon, legs and shadow. The head was part of the body sprite. That is the one I’ve split off. The body is still only changed in two directions but the head in four. The head sprite follows the same logic as with the enemies direction animation but it checks the direction between Barney and the mouse.

This change makes Barney look more responsive and robot-y.

I have also changed the positions from which the direction of Barney -> the mouse is calculated. It now it exactly at the throat. I need to polish up the weapon sprite angle calculation because it points in the wrong way when holding the mouse close to Barney. The problem with this is that the sprite origin needs to be set right where the arm is connected to the body and the angle-calculation needs to be made from different points depending on the direction.

I will continue to polish this some time soon, but for now it looks okay.

Thanks for reading!

Game dev, Suit’em up – Customization menu and textile (pickups) manager

We are preparing for a play testing with friends and family. Some things need to be added before that and one of them is the customization menu.

I have worked hard on revising the menu. To explain what it does: In our game there are four different textile pickups that are scattered throughout the world. These can be equipped into four slots in the customization menu.

Previously, the menu looked like this:

In this old menu, you had to press one of the four slots FIRST (they are the buttons connected to yellow lines). After selecting one (without getting any graphical feedback) you needed to press one of the textiles, the buttons to the right, to place them in the selected slot.

Everyone who has play-tested and all members of our development team thought that it should be the other way around, that you should press the textile FIRST and then the slot.

The old code was messy. Here are two pictures of it:

If you study the code a bit, you will probably see that it is very inefficient. There are possibilities for loops all over the place.

Also, our TextileManager had a lot of crappy getters and getters (get-/set-methods). It looked like this previously:

Enough about what was wrong with it. I did a lot to improve it!

I started with polishing up the TextileManager and even added another count, the equipped textiles count. I created an enum for the different types of textiles and the code looks like this now:

So clean!

I then started with the customization menu state. The first thing I did was removing all the old code since it was poorly written. By me I might add. This time I added support for looping the buttons and I did so every chance I got. I’m really happy with the result.

The code is now efficient and it does it’s job even better than the old one. It is now easy to read and edit as well.

Here are a couple of pictures the new code:

It’s so shiny!

The customize menu state previously had 480 lines of code and now it has 349 lines.

The TextileManager previously had 243 lines of code and now it has 193 lines.

Here are a couple of pictures of the new menu:

If you noticed from the second picture, there is now a glow on some buttons. This glow happens when selecting a textile, for visual feedback. We will probably change the sprites some time in the near future, but I believe that these will work well as placeholders.

The bonus text isn’t there right now, but it will be added shortly.

Another thing I changed is that we are now using a spritesheet instead of 8 different sprites. The spritesheet looks like this:

That is in short what I did these past six hours. I’m happy with the amount of time it took and the result as well.

A couple of more things need to be added tomorrow before the game is ready for “friends and family”-playtesting.

Game dev, Suit’em up – SpriteManager with animated sprites

We created an early SpriteManager in the start of the project but it couldn’t load animated sprites or load sprites from a part in a spritesheet. I have now added this functionality.

I started with creating a wrapper around sf::Sprite and I have created the AnimatedSprite class. I’m not really that proud of the wrapper since I put a lot of virtual functions in there that are only used by AnimatedSprite.

After adding the sprite types I added methods in the SpriteManager for loading animated sprites using .txt-files, just as we have learned to do in our first programming course. Here is an example of such a file:

And here is the code for loading it:

There is another function for adding more frames, it’s a bit shorter and looks like this:

Much of the code in these to methods (LoadAnimation() and AddAnimation()) are written twice and I should put this together. I will probably do this in the future but right now there are more pressing matters to attend to in the project.

A frame is a struct within the AnimatedSprite class. It holds these variables: x position, y position, width, height, timer.

The timer counts down when the sprites Update(float p_fDeltaTime) method is called and when it reaches zero the animated sprite changes frame. The timer is reduced with deltatime, like so: timer -= deltatime.

The SpriteManager is pretty robust right now. It saves Sprite pointers in a std::map and the same goes for sf::Texture pointers. When loading any type of sprite, the sf::Texture map re-uses the same file if it exists in the std::map, otherwise it attempts to load it from file.

Loading sprites now takes parameters for location in the spritesheet (texture) and width/height. To set or change this location and width/height the Sprite->setTextureRect(sf::Intrect) function is used. It looks like this:

Sprite->setTextureRect(sf::IntRect(p_iPosX, p_iPosY, p_iWidth, p_iHeight))

Next up is setting and changing the animations of a gameobject sprite. This is done by calling the SetAnimation(const std::string &p_sIdentifier) method. So for example, the player avatar “Barney” is supposed to have different sprites making up all parts his body. His legs is one of these parts. When loading the sprite it first uses LoadAnimated() and then a couple of AddAnimation() for each animation type (i.e. Idle_right, Running_left).

When the player makes Barney run to the right a check is done, then the animation is changed using the SetAnimation(“running_right”) method. The same principle is used for all times when changing animation, be it the avatar, enemies or what ever.

Game dev, Suit’em up – Game states

I created three types of game states using Jonas Lundgrens GameStateManager. These are: PlayState, PauseState and CustomizeState. The PlayState holds the actual playable game, the pause state exists as a first state that is entered when pausing the game. The CustomizeState exists for the player to be able to customize stats using pickups collected in the game.

The GameObjectManager

I described how this manager works in my last post, but I will do so again. It stacks states on top of each other in a std::vector array and updates them from last to first. Later added states has the possibility to freeze logics of earlier added states. These states that freeze others are called exclusive states.

PlayState

First up is the PlayState, this is where the game happens. Right now it handles the entire game using the different managers we have. It takes all managers as parameters in the constructor and saves them as members of the state.

When first creating this state all parts of the game was written straight into it. Now we have broken up most of the code into managers. For example, at first we had the sf::RenderWindow and the viewport (sf::View) as members of the Engine. Now these exists within a DrawManager. This manager also holds all Buttons and Texts in the game. This could prove to be a problem because there should be a way of separating texts in the PlayStates and pause states. This needs to be discussed among our team, one solution is to create and have different GUIManagers for each state.

PauseState

This state is created when pressing the escape key on the keyboard when in the PlayState. The PauseState gets pushed into the GameStateManager vector. It is an exclusive state, so the update() function within PlayState doesn’t run anymore. The PauseState has buttons that are basically objects with box-colliders that can be interacted with using the mouse. When the mouse position is within the box of a button and the left mouse button is pressed, actions happen. This is checked with a type of collision, BoxVsPoint. It is handled in the CollisionManager and the code is very simple. When pressing some of these buttons, the “Customization” one for example, the PauseState will use the GameObjectManagers SwapStates() function and swap the PauseState with a new CustomizeState.

CustomizeState

This state is also exclusive, so the PlayState is still “frozen” when this is active. The CustomizeState handles customization using pickups in our game. I can write in length about how I made this state operational, but for the purpose of this blogpost I will not go into detail. This state contains the same buttons as the PauseState and additional buttons used for affecting our TextileManager (handles upgrades). When re-entering the PlayState, it is unfrozen and the avatar stats are updated using the TextileManager. All states that go from being frozen run a function called Revealed(), thanks to the GameStateManager, that is where the avatar stats are updated.

Summary: Freezing and Unfreezing PlayState

As a summary to how the states work, when entering the PauseState (pressing the escape key) all states below it are frozen because the PauseState is exclusive. There is only one state below it in the vector array, the PlayState. From the Pause state there is the option to enter the CustomizeState, which is also an exclusive state. When pressing the “Resume” button in either one of the PauseState or CustomizeState, that state is pop:ed from the vector array and that makes the GameStateManager unfreeze the PlayState. Pop:ing is used when removing the last element of an array. Follow the green arrow.

Game dev, Suit’em up – Programming – Rooms, collisions, pause state, textiles and prioritizing work

Intro

Much has been done with the project, I will describe the different parts that I was a part of. Each part is described in detail in each section.

• I made a RoomManager which holds and handles, you guessed it, rooms.
• I worked with Malin Lundqvist with collisions between room walls and the avatar, line vs circle collision.
• I created a pause state which uses Jonas Lundgrens StateManager, which “freezes” the PlayState logic while still drawing it.
• I added textiles that are objects able to be “picked up” and a TextileManager.
• We discussed how to prioritize some parts of our work and divided the workload among us.

Rooms

First of all, in our game we have objects called Rooms. There are 28 of these that make up the entire world of the game. Here is our current level design, made by one of my team mates Andreas Calmius:

I made a manager that holds all these rooms, in the Initialize() function they are all created. It can handle rooms, like CreateRoom(), DrawRooms(), CheckCollisions(). This is the layout:

class RoomManager
{
public:
RoomManager(){};

void Initialize(SpriteManager* p_xSpriteManager, std::string p_sRoomFilePath);
void CreateRoom(SpriteManager* p_xSpriteManager, std::string p_sName, sf::Vector2f p_xPos);
void Cleanup();
void DrawRooms(DrawManager* p_xDrawManager);
bool CheckCollisions(CollisionManager* p_xCollisionManager, Collider* p_xCollider);

private:
std::string m_sRoomFilePath;
std::vector<RoomObject*> m_xRooms;
};

In the future, the plan is to only update rooms close to the avatar and make it so that enemies are part of each room. The idea is that with many enemies, updating them all across the map is not optimal.

Avatar vs wall collision

Me and Malin Lundqvist implemented her collision code to all the rooms, it took a few more hours than we planned in our weekly SCRUM. We had planned for 5 hours and it took about 6-7 hours.

The collision she wrote is a line vs CircleCollider code. Each room reads from a text file with points in vectors. Each vector element corresponds with a part of the room that the player cannot cross. In this example room, one vector element (points that create lines) in this map is the top wall, another is the bottom wall. The text file contains position data with breakpoints between vector elements.

The room is 2560 x 1440.

Here are the current collision points in this room (breakpoint is 9001):

2558 876
2112 806
1744 708
1728 592
1996 342
1948 226
1504 156
882 210
382 510
164 766
2 826
9001
2556 1314
2126 1308
1882 1260
1190 1292
956 1100
1088 854
1352 548
1064 542
800 788
340 1224
50 1356
2 1346

The game took a step closer to being enjoyable to play with the addition of avatar vs wall collision.

Pause state

I added a pause state to the game. Jonas Lundgren built the StateManager and it works very well. It works a bit different from the one we learned about in the lectures. This has levels of states. The later added states can be set as Exclusive, which means that the earlier added ones aren’t updated anymore until the exclusive one is removed. To explain this further, here is a picture to describe it.

The pause state is an exclusive one, so it “freezes” the PlayState below it. It still draws stuff so it look kind of nice. Here is a screenshot from ingame with the pausestate activated and the game logic “frozen”.

Textile Manager

I added textiles (the chests on the picture above) and a manager for them. The textiles are collected when the avatar collides with them. What actually happens when colliding is that the textile is erased from the vector and the AddOneX() function is called, X being the type of textile collected. The manager holds the current amount of textiles of each type collected and equipped. This is it’s layout of the manager and it’s functions:

class TextileManager
{
public:
TextileManager();

void Initialize(SpriteManager* p_xSpriteManager);
void CleanUp();

void CreateTextile(SpriteManager* p_xSpriteManager, std::string p_sName, std::string p_sType, sf::Vector2f p_xPos);

int GetWoolCount();
int GetCottonCount();
int GetSilkCount();
int GetLeatherCount();

void AddOneWool();
void AddOneCotton();
void AddOneSilk();
void AddOneLeather();

void UpdateTextiles(float p_fDeltaTime);
void DrawTextiles(DrawManager* p_xDrawManager);
void CheckCollisions(CollisionManager* p_xCollisionManager, Collider* p_xPlayerCollider);

private:
int m_iWoolCount;
int m_iCottonCount;
int m_iSilkCount;
int m_iLeatherCount;

int m_iWoolEquipped;
int m_iCottonEquipped;
int m_iSilkEquipped;
int m_iLeatherEquipped;

std::vector<TypeObject*> m_xTextiles;
};

It isn’t done, but I will probably finish it tomorrow.

Prioritizing work

We talked about adding pathfinding today after todays lecture on it. The pro’s are that we learn about doing it and it will probably be valuable knowledge since that is a common part of games. The con’s are a higher programmer workload. We discussed the matter and divided the different parts of programming among us. Malin was most eager to do pathfinding, so she starts doing this now. I will make an AI statemanager, based on the one I made for my earlier game “Boberman”. Jonas will keep working on GUI and since we arn’t sure that he will get it working until the alpha, I will program an alternate GUI for buttons in the customization menu.

Here is a list of our priorities right now:

ALPHA
1. Collisions
line vs circle
circle vs circle
2. Rooms (working)
3. AI & Waypoints
3.1 Bugger (early working)
3.2 Mothgomery (early working)
3.3 PATHFINDING (early working)
4. Audio (early)

BETA
1. Textiles & Customization menu
2. Animation
3. AI
3.1 PATHFINDING (final)
3.2 Bugger (final)
3.3 Grubling (final)
3.4 Mothgomery (final)
3.5 Ben bugger, kite fight (final)
3.6 Grubby McGrub, Whack-a-mole (final)
4. Pause map
5. Audio (final)

FINAL
1. Menu’s
1.1 Main menu
1.2 Pause options
2. Rooms (final, quadtree-ish)
3. Polish EVERYTHING