Post GGC-thoughts

So GGC is now finally over. Despite technical issues and that the demo ghost was present for me during GGC, I was still able to show of what I made during this course.

Feedback on my game
I couple of people came over and tried my game at the Gotland Game Conference. One thing that many people said was that the game needed more polish and that the player should have gotten more feedback, but it is a good base to keep developing the game further with. And If I'm going to be honest, that's all fair feedback, these are certainly things that could improve with my game.

Beyond that, this GGC proved to me once again that you cannot satisfy everyone all the time, some people liked the game more then others. But overall, I get the feeling that the game is something that could be developed further.

Future plans
Because of what I got to hear about the game at GGC, I'm going to keep developing the game. I can't currently give an exact timeframe for all of this, but here are a couple of things that will happen with the game in the future.

• More feedback to the players. This was the thing that I got to hear the most of at GGC, and as a result this is something that will have high priority going forward with this project.
• Add the missing mechanics. The GGC prototype does not contain all mechanics that i want to have in my game and I will keep developing 
• More units to the game. As of right now, you only have one unit that deals randomized damage values. This will change in the future, more units will be added to the game as time goes on.
• Improvements to the back-end code. Towards the end of this project, more and more of the code was done in a way that only enabled it to work at GGC, while not providing the possibility to expand the game later on. With new code, I will hopefully be able to add...
• ...Network Support. It's not an RTS game if you can't play it against another human player. I will work on adding network support to the game in order to make this happen. I will write another blog post later about my plans on this front are.

Final sprint for GGC

Next weeks is GGC, and I'm now on the last sprint for the prototype that will be shown at the GGC show floor.

And how far have I come with the prototype? Well, I'm basically done with it. All the systems are now functional and almost everything graphics related is implemented. The thing that is left for me to work on a fog-of-war system, add some particle effects, fix a few bugs, change a few numbers in the code, and then I'm ready to go.

Improving feedback
One thing that I got feedback on during the beta testing, which we had earlier this week, was that I need to give the players more feedback to what's going on within the game. I've been adding sound effect when the various units are in combat with each other. I've also made it is so that the unit that you currently have selected is rendered using different materials than the other units

New fog-of-war system
During this week, my teacher gave me a fog-of-war system that I could use in my game. And for most of the part, it was basically drag-and-drop to implement that system properly. The system worked in the way that the main camera was essentially all black, and then you put fog-of-war revelers on your game objects to show parts of the map.The system had one issue though. There was a hair-thin line between revealing to much and to little of the map. As a result, I decided to ditch that system and instead start working on another system. I can show more once I get the system to function properly.

Other improvements
I will also look into adding particle effects to the units when they are in combat. I will also fix the last few bugs that exists in the game. But other than that, the prototype is looking in good shape.

Warbreaking Point Weekly Round-up - May 10th-17th

More and more progress is being done on this game right now.

State Machine Progress
The work on the finite state machine of the units is going forward; I have one more bug to fix on this front (and I've managed to narrow down the possible causes for this bug) and then this part of the units will be done. However so far there hasn't really been much of a game and that's another thing that I've been working on.

Resource System, Constructing Units and Goals of the Prototype
I managed to get some kind of resource system to function this week, so I can demonstrate a demo of the game next week. It's not exactly as I want the final game's resource system to function, but it is at least something.

Now I'm working on a system to create units manually in the game. Currently the state machine bug above is putting a stop for my progress on this front, but once I manages to find that bug I think things are going to go smooth from here on. How this system will work is that the player will press a button on the keyboard and if the player as sufficient resources, a unit will spawn near the player's base. I wanted  it to function a bit differently, but due to a bug that I (and a few friends that I ask) can't wrap my head around why it is happening, I went with this solution instead.

For GGC (The conference where all the students show of their games), the goal for the player will be to eliminate a certain amount of enemy units in order to win the game. This was chosen because it should be relatively easy to implement. Even though I want to have the player to destroy the opponent's building as the goal of the game, it would require more work in order to function properly, as well as a general overhaul of how the back-end code of the game works.

Warbreaking Point Weekly Round-up - May 3rd - 9th

This week has been a slow week for me and the development of the game. There are two main reasons for this. The first has been that I have been sick during parts of the week, and therefore haven't had as much energy to work on this as I've hoped. The second reasons is that things have been going slowly overall, solving issues has taken more time than I anticipated. But some progress has been done, and now it's time to talk about what.

The State Machine for the Unit
This week I have been working on the units Finite-State Machine (or just State Machine for short). And this has been proven to be harder than I anticipated. There are essentially two parts of the State Machine that the units will have in my game.

The first part is a State Machine that automatically changes the internal unit type of the unit as required. And why is this needed in my game? The reason is because of how the the system I use for the grid, tiles as well as movement is built up internally; you can only have one unit of each unit type at a single tile at any given time. However; units from different units type can be on the same tile at the same time, and the type can be changed while the game is in progress. I manged to get this code to work, I just have some occasional bug left to fix and then this is done.

The second part of it is a State Machine that changes a unit's state based on the events on the board. For example, if a unit from one player is on the same tile as a unit from another player, then the two units should go into combat with each other. And this part in particular has taken more time than I anticipated. I only managed to get the very basic parts of this to work this morning. I will need to spend time during the weekend and next week to implement it properly. But I believe that it is doable to get done relatively soon

Work-in-progress screenshot
Here are one work-in-progress screenshot of the game. All the graphics are placeholders for now and they will be replaced with new graphics later on.

Warbreaking Point Weekly Round-up - April 26th - May 2nd

Another week of development has passed and more work is being done on this project. Here's what I managed to achieve this week.

I got a logo for my game!
With help from one of the staff members at Campus Gotland, Lina Tonegran, I finally got myself a logo for this game. I gave some ideas of what I wanted, she gave my some sketches and eventually we landed on the final logo of the game.

Once again, thank you so much Lina.

Get the input, grid and movement system to work
After much sweat, I finally managed to implement the input, grid and movement systems inside the game. This was achieved by looking into the code for the scripting package Tile Based Map and Nav (Which is the base that I've been working from) and try to adopt the included code so that it could fit my game. It took some time to get right and it also took some time to debug it all, but I finally manged to make the core system of my game to work.

Some fixes still remains to be done on this front though, but most of it is now ready for further development.

Design decision: Max 3 units from one player can occupy a tile at any given time
I mainly based my decision on 2 big reasons. The first one is because of how Tile Based Map and Nav is working internally. Each tile in the game is assigned certain values for it's tile type. For example, it could be a land tile, an water tile or both at the same given time (For example, in an harbor). This makes it tricky (but not impossible) to make a general code that can handle a big amount of units on each tile at any given time.

The other reasons is that it would be to tricky to manage squares that has to many units on them at any given time. I noticed this when I was playing Europa Univeralis 4 a while back (that has a similar systems to those I want to have in my game), and I noticed it was hard to proper manage provinces that had multiple units on them at the same time. This is not a major problem in EU4, as you can pause and unpause the time in that game. However, my game is a real-time so unlimited unites per square isn't going to work all that well

Because of this, I decided that on each given tile, there can only be three units from each player at a single given time.

Implementing simple 3D-models
Even though I'm currently only using placeholder units from the grid system that I bought at the Unity Asset Store, I've managed to implement 3D-models into my game. It's just placeholder models for now, but it's enough for the development of the game for now. I'm not an artist, and my priority right now is to make the gameplay function properly.

Preparing for year 3 already now.

Right now, the Big Game project course has started. Some groups are already well underway with their projects, others who lacks groups will pitch their game ideas tomorrow (Friday 4th April) and try and find the members they need.

I talked to two teachers at Campus Gotland, Håkan Mattsson and Adam Mayes, about the idea I had for big game project. And they really liked my idea. But the scope was to big for the time that is left on the Big Game course, in combination with some personal reasons affecting my life (It's nothing serious though,  you do not need to worry). But they encourage me to keep the idea alive and try to make during year three. Which I will do.

As much as my summer schedule will work, I will keep polishing the ideas that I had and try to code simple prototypes of the game. And we'll see what'll become of it.

Level Design Diary Part 1 (10-12 March)

I'm currently working together with Johan Wittrock on the final assignment in our Level Design course. The assignment is to analyse an level in a certain game, and try to arrive at conclusions to as of why it is the most popular map. Me and Johan choose to analyze Payload maps in Team Fortress 2.¨

So far, by looking at server statistics, we have come to the conclusion that Badwater Basin is the most popular Payload map, followed by Gold Rush. Now, our goal is to put of hypothesizes  to as of why Badwater is the most popular map, and try to see if those hypothesizes are correct 

Analyzing: Counter-Strike: Global Offensive's Competitive mode. [UPDATED 20140213]

Earlier this week, we had our first real lecture in our Level Design course. In the lecture, our teacher (Ernest Adams) mentioned a couple of principles that you need to take into consideration when you are designing a game and design the levels inside the game. During the lecture, I started to thinking that I should do an analysis of Counter-Strike: Global Offensive's competitive mode after those principles.

But before I start talking about that, you will need to understand how CS:GOs money system works. This image below belongs to http://www.vakarm.net/ and it explains how the money system works on defusal maps. What isn't mentioned here is that each player begins the game with 800$ and a full list of what everything costs can be found here. Each competitive match is played over two 15-round halves (the player swaps teams after 15 rounds) and the first team to get to 16 rounds wins.

UPDATE 1: Another link explaining the money system, including the money system for hostage maps, can be found here

Now, lets get down to business and analyze one principle at a time. I'm only analyzing the points I find relevant for CS:GO.

When the player defeats a challenge, replace resources he consumed

In CS:GO, this is done in the form of giving the player and his team some cash when they manage to achieve something in the game like getting kills or planting the bomb. The cash can then be used to buy new grenades, armor or weapon later on in the game. It may not seem like much, but in competitive CS every little amount of money matters. And if the whole team wins a round by achieving a goal together (like planting and detonating the bomb, rescuing hostages or eliminating the opposing team), the whole teams gets a bit of money back as well.

At the start of a new round, every weapon the player has managed to save gets fully replenished with ammunition. Grenades and armor is however not reset at the end of rounds and have to be re-bought. It doesn't replace everything the player used, but it does restore some of the resources used.

·       Be clear about risks and consequences

This is one thing that is very clearly present in competitive CS:GO. If you don't think of what you are doing inside the game, you might very well lose the round, which in term is going to hurt you and your team's economy in the long run.

This is also present when you are constantly firing your weapon. Not only does this alert your enemies of where you are, the recoil and spread of the weapon can also make it so that you actually don't hit anything of what you are aiming towards.

If you die, you don't keep anything your carried during the last round; you start over with just a knife and the default pistol, meaning that you have to re-buy everything again. This makes it clear that you shouldn't take any unnecessary risks in the game.

Be fair to all the players

This is a little tricky to analyze in CS:GO for a couple of reasons. While the rules for getting money inside the match is the same for everyone, and players can freely choose if they want to replace their M4A4, P2000 and P250 with the M4A1-S, USP-S and CZ75-Auto respectively, there are still a couple of points that makes analyzing this point a bit tricks

1) As my friend Inge said to me while we were playing the game, the reason to why the Counter-Terrorists weapons and equipments cost a bit more than the Terrorists is because they usually have an strategical advantage on the maps inside the game on defusal maps. And on hostage maps, Counter-Terrorists can get lots of cash even if they don't win the round, because reaching hostages rewards quite a bit of money.

2) While it may be a Best-of-30 game, you still have to take into consideration that the teams first plays 15 rounds on one side, and then switches sides for the next 15 rounds. While this may seem like a good way to balance out the fact that all maps might not be entirely balanced, and therefor forcing players to play well on both sides; winning the first half of a match can still give a psychological advantage over the opponents.

3) And of course, lots of balance is not just about weapons and cash, it's also much about level design as well. Some maps are IMO much more balanced than others, which makes it hard to analyze it in general as well (especially as a relatively new CS:GO-player)

In the end, I still do think that CS:GO is fair  game for all the players, however if we also take the mental human factor into consideration as well, it's get a bit tricky to analyze all of this as well.

 Use big rewards and small punishments

In CS:GO, this principle is more used like big rewards, big punishments. If your team gets killed and loses the round, you only get a little amount of money initially, while the winning teams gets more money and the surviving players gets to keep their weapons. But the more rounds you loses in a row, the more money your team gets, meaning that it is not entire over only because you lost a round.

When it comes to kills, the kill amount for each weapon is there to balance out the risks with certain weapons. For example, the reason to why a kill with a knife awards so much money is because you have to be in your opponents face in order to be able to deal damage with the weapon. Shotguns also rewards the player with extra money because they are only good at close-combat.

The reason for why the AWP rewards the least amount of cash per kill is because of that the AWP is one of the best weapons in the game; it will 1-shot kill any opponent aside from hits in the legs, it is a very accurate weapon even at long distances while the player uses the scope and it can penetrate through most materials and even players inside the game. However, it also comes with a couple of disadvantages as well, meaning that it is a high-risk, high-reward weapon.

I think the reason to as of why CS:GO does it this way is because in order to keep the game interesting. I don't think competitive CS would be very interesting if the principle of big rewards/small risks was used in the competitive mode, because that would take away much of the challenges with the game.

Update 2: Small improvements

Board Game Progress Report (Advanced Game Design) - The End

Yesterday, we presented the final game that we came up with for the other groups and some staff at Campus Gotland. Below are some of the changes that was made to the final version of the game.

In addition to a slightly reworked board, there are also a few tiles on the board that only the monster can move on (marked green on the image below). The reason for adding those tiles is because we thought that the monster needed to get stronger in some way. We tried and solve this by having the monster rolling one or two D8 instead of D6 as the players. This made the monster to powerful however, so it was scrapped. What we instead came up with was a few shortcuts that only the monster could use, to improve it's movement somewhat. This also increases the risk for players searching the small rooms (marked 60 and 168 on the image below), as they can now "get attacked" from two sides. However, searching the small rooms gives the players two wand cards instead of one.







































Aside from the new board, the only thing that was added was the name of the game, which we decided to call ShadowPath. Now all that is left is to write a postmortem of the game and hand it in on Friday. Then this course is over and I start new courses in math and programming, my two favorite subjects!

Board Game Progress Report (Advanced Game Design) - 20131029

Today, we had our teacher for the course (Adam Mayes) play our game and give feedback on it in it's current state.

Initially, he was skeptical to as of how the monster's hidden movement was going to work in practice. However, after playing the game, he liked the game as it was. He got to play as the monster and the game was very tight overall to the very last. Although he thought that we could keep iterate on what we already had, if all of that failed, we could reverse to the game as it is now and hand that in.

One thing that we started testing before meeting Adam was a new, larger board and making it so that the players moves 2D6 rather than 1D6 each turn. The reason for testing this out is because we thought that the game would be easier to balance with 2 dice rather than 1, because now we can keep the average of 7 from 2D6 in mind when making the new board.

As before, Christian Roupé is the main person responsible for design the new board. Although we are going to make more changes to the new board, here is how the board looked earlier today.

As before, the monster starts in the middle and the other players starts in the corners. The red-marked rooms are search rooms, where the player has to search for the talisman and then escape the maze by getting to one of the corners.

Board Game Progress Report (Serious Games) - 20131027

We are now nearing the end of the final assignment in the Serious Games course; on monday we are going to handle the game in as well as the rules and a individual report.

This week, our group sat down and polished the numbers that we had in our game, as the game's mechanics were finished but the numbers for everything could use some polish. We also made it so that the player in the game can now discard two tool cards during a round in order to draw a new card. This was added so that the player wasn't completely screwed if he ended up getting tool cards that he would not have any use for. Other than that, we made the cards in the game look a bit more nicer, even though they doesn't have fancy graphics.

Other than that, we now have more concert explanations on the tool cards to as of why the tool cards works against diseases. The information for this was mostly gathered through Socialsyrelsen (Sweden's Social Board) and 1177.se (A site containing information about sicknesses, diseases, health and the such), as having trustworthy sources for a Serious Game is important.

But there isn't really all that much more to say about the game, it is now finished and we are going to hand it in tomorrow.

Board Game Progress Report (Advanced Game Design) - 2013027

(I haven't made a blog post about some of these things earlier because there has been things that has been coming in the way for me)

This week, the work has been more divided among the different members in the group. One person was looking into a new version of the board for our game, others were looking into wands (what we call items in the game that could be found by searching) and others looked into writing on the game design document.

As a mentioned earlier, we now have a new board in our game, that is better balanced and more fair for all players. We also have new wands (full list is available here) that the players can use to their advantage and the design document is hopefully more readable.

We had a play-testing session earlier this week, were we let other groups test our game and give us feedback. Overall, people seemed to like our game but thought that we needed to polish some things more in the game. That is fair feedback if you ask me, the groups that tested our game brought up some good points that we can take into consideration when we keep working on our game.

In addition to new wands and a new board, we've made some other changes to the rules of the game as well. Now the players have two health  points, and they are out of the game when they have lost both of them. The players also have the option to steal the talisman from a player carrying it. This was added so the game would get more interesting, as we had noticed that the game could become stale as soon as someone got the talisman. Now the monster moves with a D8 rather than a D6 as the players, as we felt that the monster needed to become faster somehow.

The biggest challenge for us this week was to find a place and time where we all could together. Three persons in the group have the course Serious Games, and trying to synchronize those groups with this group has been a big challenge for us this week. And in my case, I had to skip over one meeting that the others were going to because of that it was the only time where we could work together because one person was going to leave the island later that day.

But with that said, I still think working as a group went well when we could work together. When we worked together, we were able to get stuff done and sort things out. We also know what we need to work on during the next week.

Board game progress report (Advanced Game Design) - 20131023

Today, some big progress was made to the development of our board game. Thanks to the work of our group mate Christian Roupé, we now now have a new board that is (hopefully) more balanced than our previous board.

One problem we had with out previous board was that the distance to the search areas were different for each player. But now, the distance should be the same for everyone, meaning that no player has an advantage over each other. Now we just have to play-test the board.

Board game progress report (Advanced Game Design) - 20131021

Today, we had a seminar this morning in Advanced Game Design. Marcus Ingvarsson, the teacher holding it, decided that each group talked to him in private where we demonstrated our game in it's current state.

Since our group had a late time with him, we decided to do some more polish to our game before showing it to Marcus. Today we tested the wands in the game (previously called items). The purpose of our game is to find a talisman and escape the maze with it. Initially the containing the talisman deck was separated from the rest of the cards, and it had some blank cards in it; but after some testing they where merged together as we found out that the game was going to work better that way.

Wands can be cast before or after the player has moved. When a wand is cast it is put to the discard pile. Below are some wands that are present in the game. Note that only one wand can be played each turn.

• Illuminate Allows the player that played the card to see where the monster currently is.
• +1D6 Allows the player playing the card to roll on an additional D6 when he would role for movement. The sum of both the dices is added together and the player may move up to that many squares across, the board
• Stun Stuns another nearby player, forcing her to skip her next turn.
• Teleport Short-range teleport for the hero
• Swap Swaps the player with another nearby player

Marcus though that we had a good base to build our game on. We needed some more polish to it, but overall he seemed to like our game. One suggestion he came up with was to try out different scenarios for the game.

Board game progress report (Serious Games) - 20131020

Today my group in Serious Games has a short session where we begin making a more concrete version of the ideas that we had for our game there.

After some brainstorming and discussion, we initially had a plan where we had a board that contained regions, and certain diseases cards and actions cards only had an effect on certain areas, other where omnipresent ones. This concept was scratched however, since we noticed while play-testing it that it would be to much to keep track of. So now the player is instead working entirely omnipresent.

The rules of the game was made more concrete. As before the player has a deck with diseases  that could hit the area and a deck with the tools that he has available to stop them. Now however, a player begins their round by looking at the top five cards of the disease decks, then shuffles those cards and put them back on the top of the disease deck. Then the player looks at the tools he has available and plays the card he thinks will stop most of the diseases.

We still have a point system present in our game, where the player starts with a certain amount of points. Each disease that strikes the town decreases that score. The tool cards may cost points to play as well, but they make it so that the points from diseases that "hurts" the player is reduced as well. For example, a certain disease cards may decrease 40 points from the player's score. But using a specific tool available, that amount is reduced by 15; meaning that the disease now only removes 25 points from the player's pool. Even though it may have cost the player 4 points to play the card, it still makes it worth it as the total points being reduced is being decreased compare to no tool at all.

At this point, we need to work so that all numbers in our games becomes more balanced, but we have
 a base to keep building our game from.

Board game progress report (Advanced Game Design) - 201301018

Today my group had a short meeting where we discussed what was done during the week, and talked about what we needed tog get done by the next week. The things that we came up with was that we needed a more polished board (as someone brought up some problems with it during playtesting), item cards implemented into the game, and a way to improve the monster's movement.

During this upcoming weekend, I'm going to test some ideas of how to improve the movement of the monster. Among the things we talked about included that the monster rolls a D8 instead of a D6 and that the monster can move a certain amount of squares in addition to the one that is rolled on the dice(For example 1D6+2). The reason for doing it on my own is because the other members of the group are busy with various things during the weekend.

Board game progress report (Advanced Game Design) - 20131017

Today was a play-testing day, where the different groups in the course was play-testing each others' games. We had a total of three groups playing our game in it's current state. Overall, people seemed to like our movement system and that the monster in the game was only revealed each fourth turn or whenever it lands on the same square as another player. People thought that we had a good base to keep building our game from.

During play-testing some interesting things was noticed that we haven't noticed for ourselves. The first one was that certain players on the board had a shorter distance to the search-rooms (where they can find various items, including the item that is required to win the game) than others. Our current board is not final so it's something we can improve. The second thing that we noticed was that it was possible for another player to re-spawn on top of another player (two players cannot be on the same square under our current rules, and players are currently re-spawning on their starting location when they are killed by the monster).

This showcases that it is important to play-test your game often, so you can get feedback on things that you don't noticed yourself. With all that said, I'm happy that we currently have a base for our game that people like.

Board game progress report (Serious Games) - 20131016

Today, my group in serious games sat down and started working on our board game assignment that we got in that course. The main purpose of our game is to inform people about disease transmission. So we began by doing research on the subject, put together what each of us had found and worked our way from there. Note that the design below is the current rough version of what we got, it will most likely changes as we keep developing our game.

What we came up with was a strategy game and here is a rough description of what we came up with. In the game, the player has to manage a certain area where they have to work with preventing disease transmission. The player has two decks. One deck that contains card with the challenges that the player is facing and one with the actions that the player can use to prevent it. The player has to play the right tool card at the right time and prioritize what needs to be done.

The most important thing with our game is that the information on them is extremely clear. We want to teach the player to as of why something works or doesn't work against a certain kind of disease. However, we don't want to scare people with out game, we want to inform them.

Board game progress report (Advanced Game Design) - 20131015

Today, my group in advanced game design sat down and did some design on our board game assignment. This day we tested the movement system that we was going to use in our game.

The idea of our game is that there is one monster player that is hunting the other players down, who in term has to search buildings to find a item, which they then has to get to a certain location. The first player who achieves this win the game.

But there is one twist to all of it, the monster stays hidden from the other players for most of the game. The monster is only revealed after a certain amount of turns has passed (currently four) or if they land on the same square the monster. If the monster and another player lands on the same square, the player is killed.

One question that might pop up know is, how does it prevent the monster player from cheating? The answer is that the monster writes down the movement he/she does each turn, which the players can then check up if they question it.

Our first version of the board and rules of the game

Now lets show some images from the development process today.

The initial version of our board looked like this. The monster starts in the middle and the other players starts in each corner of the map.

Each square was given a number on the board, which is used by the monster player to write down his movement across the board.

Here, the rules were that each player (including the monster) would roll a D6 and then move up to that many squares across the board. The roll of the monster is also open. The goal the players has is to go get to the white square, fins items and then retreat back to their starting square (1, 6, 11 and 16 respectively in the image above). The players can move between the diagonal shortcuts, marked with two white lines (all other white lines where not supposed to be there)

We did some testing with this board, but we quickly realized the the board was to small, becuase it became very easy for the monster to catch up with the players. So we decided to try out the same mechanics but with a bigger board. Below are some images from the evolution of our new board.

The second version of the board

We started out with a simple squared paper

Added some start points

We started to come up with ideas for a maze

 And eventually evolved it into our final version of the board

In this new board, the boxes that are red are search areas, where the players have to go to and find the items they needed. However since that system was not the main focus today, the search system didn't do any impact on the game play other than the player has to forfeit a turn when they search for items.

One thing needs to be said about the board. Aside from the two small blue lines just over the lowest red search area, every line on the board is passable as long as the players doesn't move into the filled blue territory.

Playtesting the second board

We kept the rules mostly the same as we had for our first board and played three games on the new board before we were to tiered to continue. The rule change was that instead of being permanently killed by the monster when they land on the same square, heroes are instantly respawned at their starting location instead.

This time, we liked the board better because this time, it wasn't as easy for the monster to keep up with the player and when the monster did, it was also more spread out over time and not all at once. We let different persons on our time play as the monster, and mostly got the same results to as of how often the player got killed.

When we was to tiered and hungry to continue playing, we deiced to call it a day as we had come up with a movement system that we were satisfied with and that we could build our other systems around.

Learning Video Game Design - Making Board Games

Time for a quick post.

Even though I'm reading two courses about video game design right now, I'm currently tasked with making a board game (in a group) in each course. Why is that? In my opinion, the reason for this is because video games and board games has more stuff in common than most people might think when it comes to the design part of the respective kind of game. For example, if you break down a strategy video games and a strategy board game, I'm pretty sure that you will notice many similarities between the games. I'm currently working on a post where I'm talking about what video games can learn from board games when it comes to randomness The post is going to be long though, so it will be a while before that post comes up.