02 03 04 05 06 07 08 09 10 11 12 13 14 15 16

Dec 28, 2014

Making Skelly Dungeon, a Zelda clone part 3

It's been a slow week since it's been Christmas and all. Last week I finished movement and for the player and this week I've gotten around doing the Rooms. I ran into some problems concerning collision with walls which I'll sort out later and the next step is managing more rooms as well as switching rooms.

The rooms are now defined and usable! In a text file you write down the name of the room, width, height and what all tiles are which are then loaded into a two dimensional vector and then translated to the corresponding tiles.

This makes it so the level designer can implement the levels without the programmers aid, which is good practice.

The only tiles supported right now are ground and walls, and the walls are created separate as objects with collision. Later I plan on implementing doors which would then lead to other rooms.

Speaking of other rooms, that is the next mission in this. We want to be able to go into different rooms and have them connected. And I have a plan for that. I have a room manager which holds all rooms in a map which can search be searched to find the room in question. You can even name the rooms special things to remember them by.

Another problem I ran into was collision with walls. The problem comes from diagonal movement from the player which makes the player move 0.7~ in both x and y direction when moving diagonally as to not speed up. The problem is when a float is converted into a int the float gets rounded down no matter what. This makes it so moving positive in x direction lowers the movement while moving negative in x direction speed up the movement.

Either I have to remove diagonal movement or I have to find out where the horrible float to int conversion takes place and fix it in some way. But as it doesn't break the game right now I'll deal with it when it comes.

Next task in line are:

  • Enable changing rooms
  • Doors
I also need to talk to my partner about how we're going to split the workload. It's hard to figure out at the early stages of programming experience since I tend to get stuck in my own thought process and I can't "help" without figuring everything out myself.

Welp. I hope it works out at least. See you next time~~

Dec 20, 2014

Making Skelly Dungeon, a Zelda clone part 2

A week has gone by and we've gained a foothold on our project we feel confident in. With Github me and Dee can easily work on the project at the same time without trouble. And now that we've implemented some of the basic functions I can see the whole project coming together.

What we've done this week:

  • Player can now move and it feels natural
  • The players animation works while moving. There are a few errors here which will be fixed later
  • We have included hearts which can be picked up and a Item class for objects that can be picked up, which will make other pickuppable items easy to handle.
  • We have walls which have collision, so you can't move through them.
While it might not seem much, there is a lot of generalization so we can work with everything in the future.

This is our to-do list for the next week:
  • Give the player a sword with animations
  • Create enemies which have collision with the sword
  • Make a system for rooms which is composed of walls and ground sprites

I'll most likely be working on the room system. I got really inspired by the animation lecture we had before the break which read in a text file with information on how the animation would look like. If I could create a text file with information on how the room I want looks like then the program could interpret that into the actual room. Then I could even make a room editor so that anyone could make levels for the game.

That will probably be the next update. So until then have a good time!

Dec 14, 2014

Making Skelly Dungeon, a Zelda clone part 1

I have now started working on the last assignments for the first programming course. The assignment consists of using SDL, a library for media functionality additions to C++, to make a clone of an old school video game.


The Team


On this assignment I'm working together with Dee Majek whom you can find here: https://gamedesignandthings.wordpress.com/

The Game

We've chosen the first Zelda game for NES to clone. We wanted to make something along the line of a dungeon crawler inspired buy nethack, but since ASCII art didn't fit with the assignment we chose to start out with Zelda and perhaps make some fork in the road ahead and add our own design.

The Start

So far we've made a list of objects in the game and written down their properties, behaviors as well as their relationships with other objects. This will create the framework for when we'll start coding the objects into the game. These objects are the player, the enemies, the items, pretty much everything in the game is considered an object.

During the project, we will write what needs to be done and then order them in a priority list. Every time we continue working on the project, we look at the list and pick an unfinished task and update the task to "in progress". When the task is finished then you mark it as such and look at the next task in line. When a priority level is finished, you can move to the next level and work on that.

Updates

And I'll be updating our progress on this blog! Expect pictures, code and perhaps even design reasoning. Oh, you want a picture now? Sure, hang on.

Picture of potential player

Nov 30, 2014

Third Week of Programming: Back from vacation and Tic Tac Toe

Since I last week wrote about most of the assignments for this week, I'll talk about one assignment which took more time than the others. Making a game of Tic Tac Toe.

Tic Tac Toe is played on a 3x3 grid in which one player is represented by across and the other player is represented by a circle. The players take turns putting their symbol into the grid and if three of the same symbol align vertically, horizontally or diagonally then the represented played wins.

The assignment was to make Tic Tac Toe with classes.

Firstly I made a Board class. Since the board has a physical representation in the game. I made a function to draw the board which consist of asterisk (*) and underscores (_). They form boxes which becomes the game board.

[TO BE CONTINUED]

Nov 24, 2014

Second Week of Programming: Making Pong and Doing extra work with Classes

Since I'm going back to Stockholm during week 3's classes, I asked for the assignments in advance so I could brush up on my old C++ knowledge.

Firstly though, we made pong with SDL(Simple Directmedia Library). A programming library is a set of predefined functions and classes which can aid you in different ways. If I want to make a game, I don't necessarily need to know how to program the graphics card, but SDL do and helps me with that process. The back end takes care of the hard stuff and I can just write
Window win = CreateWindow();

Now, with the library in place and our instructors initial program, we made pong. The process was mostly figuring out how the objects in the game should act and then define that behavior in code.

Paddles move by pixels when the player press up or down, that is easy. But the paddle cannot move outside the screen! If it does we send it back before redrawing it on the screen. Also if we move the paddle every frame, slower computers will have slower movement. We don't want that! So if we base the movement around time we can have a global measure to go after.

And for the ball we need to define movement in two directions, vertical and horizontal. And to make the ball bounce, we need to define that when touching the upper and lower screen, the vertical speed is reversed, and when touching a paddle the horizontal speed is reversed. And when touching the left and right border the score count for the correct player should go up.

One more thing to add is game states. This game of pong is either running or paused. To start the game from pause you need to press enter. To pause the game a player needs to score. Game states are good for enabling a certain behavior at a certain time. You should not be able to move during pause and neither should the ball.

I also went through classes again and there were several new things I ran into. Classes are good for several reasons. In a class we define what an object of this type of class looks like so we can use that for the purposes we define. Bullets in shooters are objects defined by a bullet class and every time someone shoots, bullet objects are created.

It sounds easy as a concept, but defining exactly what you want can be pretty hard. I made a card class which can hold suit and number. Then I made a deck class which creates 52 cards in a array to mirror a real deck of cards. Then I made a class which holds a hand of 5 cards and can do things like discard a card and draw a new card.

The process isn't too easy for a beginner and I do feel like I'm learning a lot of new stuff every week. I'm glad that I'm ahead in this course so I can reinforce my knowledge even further. The next step in the program above should be something like making a game of poker, but that is for another update.

Nov 14, 2014

First week of programming: Making a text adventure game

The programming course has begun. Since I already know most things taught in class, I decide to brush up on the subject in my own way.

The lectures we've had this week mainly consisted of learning control statements like the for statement which loops and the if statement which checks for certain conditions. This is basic stuff I learned in high-school, so I did a little exercise of my own.


This is my text adventure game. It doesn't have a name and is still a work in progress, but it works! The main features I use in the game is switch statements, which looks at where the player wants to go and sends him/her on their way to that part.
EXAMPLE: "Where do you want to go?" "1. Left, 2. Right" input=1, goto left.

The second feature I use is the if statements, which triggers at certain choices if the player has visited other locations.
EXAMPLE: if(Player_has_visited_left) then he goes right.

It's a simple game with simple code. It's not the most optimized and there are a lot of manual edge cases. But that's where the next part comes in. I'll keep this going throughout the weeks, adding new things every week.

See you next week!

Nov 9, 2014

Game design introduction course completed. A quick look on the experience gained.

Now we're finally done with the concept document for the space shooter. Hard times were had and lessons were learnt to make it easier in the future.


A game about a detective who must defeat mafia bosses in order to pass on

I was the producer for the game concept called Desert of Tombs, and it was not an easy task. We had our good times and bad times throughout the project, but I think the most important thing of all were the experience of begin thrown into the lion's den. I do think this project is too hard, we are new to game development, we do not know how to pitch and this is the first time we're doing anything like this. But it is well motivated by everything I've learnt, not only what we did wrong as a group, but what I did wrong as well.

A mockup of Desert of Tombs

It is hard to work on a game concept when everyone on your team has visions of different games, and this is the main reason why our project want astray. Firstly, we did not have clear aesthetic goals. We wanted to have something with challenge and discovery, but those are from the types of fun category. This made designing hard because everyone chimed in with their interpretations of the game. Since we also didn't have roles to divide different work areas in, everyone decided on everything which made it a work of very different ideas which did not work in harmony.

Example of a boss fight

On of the most important lessons for me though is that I need to stop trying to have control over everything. Since we had discussions on everything, I voiced my opinions over the others almost every time. I was like a cynical producer who wanted to double check every decisions made by the team. 

But this is something to be learned from. Through this project I have learnt that I should not take control over everything. Other people have ideas as well, and they can do good work if I just give them the chance. For the next project I will make sure the team's vision is clear. Then everyone will have their area where they are the ones making decisions. I will not be telling everyone what to do and I will not make the final decision on everything.

Now it is time to move onward with new-found experience!

Oct 21, 2014

Desert Noir Paper Prototype UPDATE

Here is a one-page rule explanation of our paper prototype. It represents our core gameplay which is run and gun combat. When people playtested it, they found it really fun to run around freely and some people even started climbing chairs. Even though that was unplanned, it actually kept the core experience intact.

This thursday, we're going to show off our prototypes. I believe our players will run around and have a lot of fun :D

Oct 14, 2014

Paper prototype of Desert Noir, space shooter extraordinare

Now we've begun on our final assignment for the game design introduction course. The group seems good, we've got a nice concept, what more could you ask for?

The goal is to make a game concept document based on two words and some restrictions. The restrictions of no gravity, a projectile present and powerups basically makes it a space shooter.

The game is shaping up good. Today we made our first paper prototype, and it's... special. Our game's combat is focused around shooting enemies who dies in one hit while they are running at you trying to melee you.

The first idea was to have a piece of cardboard with the player controlling a paper dot while trying to avoid other paper dots controlled by us, the designers. But we realized that wouldn't capture the fast paced action the game offered, so we changed paths.

The second idea was this: The player runs around freely in the current room while the designers (us) tries to walk towards the player. The player can form his hand into a gun and with a "Bang" sound shoot the designers, which will then become inactive for 3 seconds. Shooting each designer 3 times results in a win, and faster designers next round.

It still needs a bit of tweaking, like the inactive time and win condition. The core experience is there, we just need to fine tune it a bit.

Shout-out to my team for being awesome and making this possible. I think we can make an awesome concept since we've gotten so far in such a short time.

Oct 13, 2014

Concept Challenge - Lady Lovelace and the mystery at sea

A chance to test out our skills and prepare ourselves for future assignment, the random narrative concept challenge had us pick a narrative randomly and then make a concept pitch about it.

Your main character is a fun-loving 50 year-old woman. The story begins in a boxing club. Someone is haunted by a traumatic experience at sea. It's a story about prejudice. Your character approaches the situation extremely carefully.

We really liked the potential of this character. Our first focus was on the 50 year old woman and the traumatic experience at sea. This screams horror/puzzle game and we went from that.

Aesthetics
The aesthetics becomes:
Narrative: Story engagement
Discovery: Investigation
Challenge: Logic Puzzles, Stealth

The perspective is third person.

Story
We loosely defined the story, a woman looking for her husband in a spooky environment. It starts at a boxing club with a patron having a accident at sea and knowing something about Lovelace late husband. It the game, the lady will go trough rough city blocks and uncover something much larger than she expected.

MechanicsThe mechanics are:
Walking around
Talking with NPCs
interacting with objects
picking up objects
Using picked up objects

Death by enemies

Dynamics
Sneaking around enemies (Investigating, stealth)
Solving Puzzles (Logic puzzle, investigating)
NPC social puzzles (Investigating, logic puzzle)
decisions based on story (story engagement)

Core Loop
Solve Puzzle -> Story Progression

Key Features
No inventory - only one object may be carried at a time. This enhances the puzzle-solving aspects of the game and encourages players to think about the challenges before them, rather than simply hoarding items and using trial-and-error

Feedback

Adam really liked the no inventory feature which also made sense on context of what we're trying to do with the game.

Takeaway

I noticed something doing this analysis. Firstly, it is a pretty boring format. I am mostly analyzing the system and not features in the system which makes them work. I think this is a pretty big mistake which I realized doing this post. In the future I will be more focused on features rather than the MDA.

Oct 6, 2014

Game Jam with Mayesrunner

Game Jam with the GAME crew. What an amazing experience. I'm happy with my amazing teammates and the 6 hours we put into our game. And we even won a reward, how wonderful isn't that?

We had a game jam last Friday. It was called "My first jam" and was centered towards building relationship between new students and older students as well as creating the opportunity to be making games.

The team was really nice. The seniors helped us when we needed it and let us actually be a part of making the game. I did the player controls as well as the collision and I felt that it was a job well done. Maybe it wasn't much, but it made me really happy to be a part of.

The game we made was Mayesrunner. The seniors on our team made a game parodying Ulf last year, and they wanted to make something similar this year. The theme of the jam was Addiction X which but we didn't look at it too hard. We wanted to make something fun. I like Adam, and the seniors does too so no hard feelings were meant. There is a running joke between the seniors that Adam doesn't like grading papers and we based the game on that.

The game is an endless runner with Adam Mayes running from students trying to get him to grade their papers. On the way you can pick up coffee to run faster. If you touch a student you die and if you run into a block, you get slowed down. After dying the player can see how far he/she got.

It was awesome to see everyone's creation after the deadline. There were so many creative games. And even if some of them were bad, they all had something interesting which could be made into something great with time.

I'm really hyped for the next game jam. It feels great having completed my first game! And it feels like I really can make games. Now I just need to make better games.

Backlog on the previous weeks

So somewhere along the lines I forgot about blogging about school stuff and went on the do my own analyses of games. Here are some snippets and thoughts behind the recent weeks.

In the recent 3 weeks we've actually had quite a lot work done. Assignments to be presented the day after receiving them, writing of essays. So I'm just gonna write about the recent happenings and my thoughts/reflection on them.

Sissyfight

We played Sissyfight and then we added a new mechanics to it. Our group actually forgot to play test which we learned later was a really valuable experience to keep in mind. We thought our mechanic was pretty solid, instead of life you have walls, and when the walls are lowered you can 'Assasinate' an opponent. This mechanic didn't change even after play testing.

Then we got the memo telling us to add collectibles to the game. This confused us since we didn't know if it meant TCG collecting or game mechanic collecting. We went for the latter and added coins to the mix. When attacking another player, you get coins equal to the damage dealt. We didn't have enough time to come up with good ways to use coins, so we just added a bribe mechanic, tested it out and said that it works. I would really like to go back to the coin mechanic and change it. I feel like I have much more experience and could make something much better now.

Earnets Adams Workshop

Earnest Adams, author of "Fundamentals of Game Design" arranged a workshop where all students were divided up in teams and made a game concept based on a dream. Our group got "I want to be a real cowboy (not a gunslinger). We also had roles. I was the mechanics designer which I still don't really get how it works. It felt like I decide mechanics, then the UI designer translates them into buttons, then the level designer does the implementing. But there is a discrepancy on the way. For example when the UI designer decides the whip is controlled by circling the right control stick.

It felt like a slow process where no one really had a grasp on what the others were doing and I didn't see it go in a good direction. During the presentation there were some mixed results from the other groups. Some had really interesting ideas while others just went for the standard approach. It made me wish I had gotten something more interesting than cowboy. I also think me and others interpreted the assignment as serious business sine it talks about dreams and then really wanted to replicate a simulator type game.

The game with trolls and steamroller was the most interesting imo.

Adam Mays spontaneous assignment

Next Monday after the workshop: "Make a game, come back tomorrow."

New assignment. Make a paper prototype of a digital real-time game which captures the core experience of that game. Our group chose Skyrim.

This was actually the most fun assignment yet. It was the same group as the workshop and we were all very motivated to succeed. The group: Me, Anders Hagström, Erik Starander and Emil Nyström worked hard on our board game version of Skyrim. I made most of the mechanics and balanced the monsters powers, Anders helped a lot with the overall design of the game and came with good opinions and changes along the way. Erik made a beautiful world map which perfectly captures the Skyrim feel. And while Emil missed most work time because of an appointment, but he made one of the most important touches on the game before it was finished, he made the player avatar out of his snusbox, and it fit perfectly. After sleeving the cards with padding of magic cards, the game looked and felt really good and fluid. I was happy.

Essays

We've had two essays recently, with the creeping doom one in game design. I think the thing I learnt here was that if you stop and really think about it, you can come to a good conclusion. If you look at fear and what situations can arise, then think of how to represent that in a game, the assignment is easy. Though it still meant correct writing, which went fairly well in my case. Interesting topic this one.

Oct 1, 2014

Analysis of Sushi Go!

Collect sushi with cute anime faces. Dip them in wasabi and triple their points!

Every round in Sushi Go! you collect sushi of different kinds, then you count points based on what you picked. Often you need a collection of the same dish to get the required points, but some cards combos with another card.



Every round, each player starts out with X cards in their hand. Based on the number of players in the game, this is around 7-10 cards. Then each player picks one card and lays it face down on the table. At the same time all the players reveal their chosen card and then pass their hand to the player on the left. When all cards are gone, you count points based on the types of cards you picked. 3 Rounds and then you count the point total and the player with most points win.

I'm not gonna list all the cards and their effects. The game is really simple and should be picked up if you like cute games with lots of fun.

Analysis

The aesthetics of Sushi Go! are:

  • Fellowship: Competition
  • Challenge: Planning, Social Understanding



The competition is the wish to win over other players, which is exactly what the game is about. This is also evident since everyone has the same opportunity to pick the cards in the pool, making the choices you face every turn based on when the opponents are picking.

Planning comes in when you open the first hand. You see what your options are and must choose carefully. If someone is taking the same thing as you are, the chances that you are getting those pieces are diminishing. And for every card reveal, the planning must be altered which keeps the game fresh and interesting.

The social understanding comes from what I wrote above. You must not only think about what you want to take, but also what others want to take. You could alter your own strategy to pick the pieces no one's taking. Or you could pick the pieces others want before they get them to disturb their planning.

Core Loop

Pick card -> Get points

This is what you do all game. The theme of the game helps immensely when taking on this mechanic. Picking cards feel good because they are so cute. It's helps the player relax when thinking about what cards to pick. It also helps that many of the cards are flavored in such a way to make the understanding of the game easier. Dipping nigiri in wasabi gives triple points. Dumpling gives more points for each individual you pick. Getting the points is also satisfying since at the end of each round, you really feel content with what you got. Since every player at least finds some pieces which made him/her happy.

Mechanics and Dynamics

Mechanics:

  • Hands are passed around
  • Players pick cards
  • Players reveal their picked cards
  • Cards gives points based on other cards (combo based)


Dynamics:

  • Players wanting to pick certain cards which they think will works well together in the future (Comptetition, Planning, Social Understanding)
  • Players picking cards based on what the other players are building (Competition, Social Understanding)


Takeaway
The best thing Sushi Go! does is how good it's core loop is. Picking cards is easy and feels good to do. The faces add a nice atmosphere to the game which also helps players understand the rules to the game. Since sushi have become widespread in the western world, even kids will have an easy time figuring out how the mechanics are represented through the theme.

tl;dr a good theme makes mechanics easy and the game fun to play.

Sep 20, 2014

Cooperative chess game

Fundamentals of game design chapter 1 exercise 2: Use a chessboard and chesspieces and the ways they move to create a cooperative game where two players work together to achieve a victory condition.

My first idea on this is to have the colors represent each player. This makes it easier for the players to consider themselves important and also guides them in what they can move. I want the enemy to start on the other side of the board and have a system which moves their pieces. The system is taken care of by the players moving according to rules. It's turn based and the players have their turn together with both of them moving and then the enemy moves.

The still needs to be something which separates the players pieces from the enemies, since the colors are the players own. The pawns are pretty boring, so they can be given to the enemy. Also, if the players begin on one side of the board then there is only eight spaces where they can start (if we consider only using the back row).

If the players only gets the tower, horse, knight and queen the starting point can look like this: THKQQKHT with the player colors split in the middle.

The pawns should be boss like to create an enemy. If you have four pawns in a square that looks pretty threatening. The pawns can move like pawns move regularly, except they are one big pawn. But let's have two big pawns because otherwise it would be too easy. If the pawns could move to multiple targets, then the players get to choose the direction.

This looks like a good starting ground. Now, off to playtest this and then report back the result.

Sep 19, 2014

Mechanics are hard


What do you get when your assignment and course material contradicts each others and the presentation that should have been uploaded isn't there. At least a confused as fuck student.

Maybe it's just me, but the game workshop where I took the role as the mechanics designer was really weird. The paper was full of fill in the blanks of gameplay modes. The description says I should design core mechanics. The course material says there are lots of types of mechanics. The assignment paper only mentions one. I have no idea if it even helps my team if I only write the game modes, because we kinda did that already together. So I wrote some mechanics I guess?

???

Maybe I'm just overthinking things.

My mood didn't improve when I found out that another assignment everyone in the class though to have been pushed forward is actually due tomorrow. Nice. At least I worked on it for a bit yesterday so I could finish up in an hour, but it seems a lot of people in my class just said fuck it and hopes for the best.

Takeaway
Uuh. Student lives are hard? I dunno it's a little stressful but still nothing big. I'm more upset about myself for not understanding the workshop assignment. It feels like it is a learning potential gone missing. Time to read my course material some more. It's good stuff!

Sep 17, 2014

Creeping doom and scary games

What is horror games? Does it make you feel afraid or does it just scream in you face?
Horror games has the last years had a really dull view of fear. The game industry thinks that simply a monster in a closet will get us happy and content with the scare factor. And while monsters can be scary, just having them chase us is not enough to make a good horror game. Dead Space wants to call itself a horror game, bah. Now, Dead Space is a good action game, the horror sucks. Jumpscares will not carry a game, the atmosphere will. Amnesia went in the right direction, but ultimately failed because of AI failures and the last area being a quest.

The reason why the subject today is horror is because it relates to my homework for Friday. We're supposed to write an essay on how we would design a game of creeping doom. The restrictions are:

  1. Players can't move
  2. Players cannot win the game
  3. The players will lose at the end
  4. There must be a theme of Creeping Doom
Since the essay is supposed to be super academic and stuff, I'll post some of my thoughts on the design here.

Approaching this design challenge, I thought about what the game is about. Fear is the thing we're working with, but what different kinds of fears are there. I found a link with a professor talking about the shared fears we all have (http://www.psychologytoday.com/blog/brainsnacks/201203/the-only-5-fears-we-all-share)

I also took into consideration the story my teacher told us about the shaving game. Last years a couple of students made a shaving game where you have to shave before you go to work, and that broadened my view of the assignment. I started thinking about bullying, since we've been working a lot with Sissyfight recently.

I'm not completely finished with the essay yet since I got sidetracked with the fear line of thinking (which I cannot use in the essay since I lack the sources and it's kinda off-topic) but once I finish I will put up the idea here and discuss the forks in the road to completing the design of the game.

Takeaway
Horror games can be much more than just super scary. Creating a frightening environment can be enough if you put the right characters and situations in place. The goal of this assignment was to get us to think outside the box, since movement is not an option, how are you going to feel scared? To finish this assignment we need to look within ourselves and see what we think is really scary, instead of guessing what other people think is scary. So maybe it's more inside the box than we thought.

Analysis of Klondike - From computer to reality

How to use mechanics in a way the player can remembers, use and enjoy.

I'm gonna use the same picture this time around too because I like it and it is an accurate depiction on how a game of Klondike looks when played on a computer.
And this is how Klondike looks on my kitchen table. Both these games have the same mechanics, dynamics and aesthetics. The big difference between these two is that one of them is set up and handled by a machine and the other a human. Yes they are both played by humans, but in the tabletop version the player must take care of the setting up, the stock, revealing cards, checking wrong moves etc.

Simple system mechanics make human happy.
Klondike is designed to be played on a table with a human running through the motions. This can be noticed by how the game is set up and how the stockpile functions. The setup is easy to remember because it follows a easy motion:
Shuffle, One card up, count six more piles face down. One card up, one face down on the rest, One card up, one face down on the rest, repeat until there is a face up card on every pile. It feels good to deal out the cards and the stockpile is left in your hand afterwards. Simple and clean

The stockpile is also handled in a simple way. The player takes the three card on the top of the stockpile and lays them out. The topmost card can be moved which, if moved, the card below it can also be moved. If the player wants three new cards then the old ones are discarded face up to the waste pile which is kept in order and never shuffled. If all three cards are used up, the player can start using the topmost card in the waste pile.

Here comes a big rant though. While the mechanic feels good to use in the beginning, it stops feeling good once you realize that the cards in there gives you important information from the beginning. It now becomes a chore to look through the cards and memorizing them. For a player playing on a table it is much easier to just pick up the cards and look through them. For the computer it also behaves in a weird way which you probably won't bother to look up because you just want to submit to the rules. The sad part is also that this mechanic is crucial to winning the game, and when the player finds that out, submission lowers and challenge rises. Now you have to really think about your moves so that you can find the optimal way out at all times. 

Takeaway
When designing card games, especially ones you play with paper, you need to consider simple mechanics which is easy to remember and still feels enjoyable to use while containing a good gameplay.

The setup is a good example of a simple system of actions the player performs to get the game going. The stockpile, while feeling natural to use, fails when the player realize it's importance to finishing the game, which then cannot be ignored when playing in the future.

The stockpile creates the conflict between Submission and Challenge which splits the player in two sides based on how much they know/experienced of the game. It creates a nice front, but it's a game that will ultimately fall flat on its belly for anyone playing it long enough to actually want to learn the tricks of the game.

Sep 15, 2014

Analysis of Klondike - Effective submission game design

You probably have this game on your computer. It's an all time classic to play when bored and it can be a really addicting pastime. The colors of the cards is the most important lesson!




Klondike is a form of solitaire which means single player card games. I think most people would recognize this game through their computer since it's one of windows most classic "games which comes with the machine". I also think almost everyone has played it at least once, and the design of this game makes it easy to pick up at all times. Here is a link to the rules, let's begin cutting it open!

Core Loop
The core loop of Klondike consists of
Move card(s) --> Reveal card

Mechanics
Moving a card is clicking a card which lies on top of either the tableau, waste pile or foundation and then dragging that card to another card on the tableau which is one number higher and in a different color.

You can move to another card on the foundation with a number which is one lower and in the same suit. Aces can be moved to empty spaces in the foundation.

Revealing a card is done when there is only face down cards in one column on the tableau in which case you flip the topmost card face-up.

The players action is moving of the cards. The reward for moving cards correctly is the revealing of the card beneath. Some cards are allowed to be collected based on previous cards collected. This is the core loop of the game which repeats itself.

The first thing of interest is the how the colors of the cards interact with each other. Since the player always needs to look at what cards they need to move right now, the color of the cards not only makes them easier to search for, but it also shapes an appealing pattern when laying them on top of other cards. Humans love seeing patterns everywhere, and this core loops abuses it.

The revealing of the cards is also interesting. It comes as a reward which feels nice for the player, but it also creates a sense of suspense to find out what new possibilities comes for future needs. Maybe you've been waiting for an 8 to come along for some time now. You will wish for that 8 for every card you reveal, hoping it will give you the miracle you need.

Aesthetics
Challenge: Logic puzzle(Brain teaser?)
Submission: Rules indulgence

As a single player card games with non-narrative cards, submission and challenge is what Klondike is achieving. There are rules which you follow strictly(Submission) and the game is really challenging to complete(Challenge). It's the type of game where the rules are simple while figuring out how to use them well is a bit complex which creates the challenge of wanting to understand the system. Since the game isn't hard to play and can be fun to sit through even without thinking too hard about it I would say challenge is a minor Aesthetic. The rules are everything in this game, and the player only moves according to the rules. Which means we can turn our brains off the let ourselves indulge in the game world.

Takeaways
I'll be doing this also. Because if you are just analyzing, then you're missing the point of analyzing. We're doing this to improve, so what can we learn from Klondike?

The game's Aesthetic wants us to relax and sit back and it does it through it's really good set of rules and especially in the number/color matching which creates patterns every human loves. The takeaway here is that pattern matching makes really good submission games(Oh right candy crush saga makes so much sense now...).

Sep 14, 2014

A deck of cards and unlimited potential

The plan is to get a habit of doing something creative. Let's take a look at the many games that uses playing cards!

"Read everything. Cut them open. Steal their power." -Warren Ellis
Those are words from a comic author about improving your craft. for game designers, this could easily translate into play games ehu! But that doesn't cut it alone, because that's not giving you anything back. The analytic part is what creates improvement, and this is where my new plan comes in.

I bought a deck of cards.
Adam recommends getting a habit of doing something creative at least once a day, to get in the routine. I've always been interested in card games, especially how cards can translate into simple and clean mechanics. So, I'll be looking at card games that uses one deck of regular playing cards. 52 cards and three jokers, what possibilities does it hold? It is time to look at, test and analyse different card games and to find out what makes them tick.

Lots of different games.
There are maaaaany different card games out there. And many of them are really complicated and rules heavy. My initial research (Googling card games) showed me that there are a lot of point grabbing games, often where the main goal is to get pairs of different kinds and then writing down points based on performance. Already, these aren't the games I prefer, but I'll at least take a look at some of them since they are classics. What I'm more interested in is card games with interesting rules and win condition. President and Old Maid is the kinds of game that interest me the most, since they go beyond the simple get points system.

Where do we go from here.
Looking at card games, analyse them and then of course build one myself! That is the goal of this exercise and I hope to learn something that will aid me in my studies.

It's always good to overachieve!

Sep 3, 2014

Starting with a bang

So. What did I expect from studying game development at Gotland University. Alot of my friends who were experienced programmers at KTH back in stockholm warned me and said that I shouldn't go to Gotland and instead do something more programming heavy and keep game design as a hobby. But after getting here and experiencing my first lecture, I'm sure that I didn't make the wrong decision.

Hello, my name is Simon Lundgren. I like games of all kinds. Video games, Tabletop games, Roleplaying games, Card games etc. For a long time I've been really interested in design and especially in the design of games. There always seem to be alot of thoughts behind great game design and I always loved looking at those design choices and thinking about ways which I could make the same good decisions... After the first lesson I got a sense of what I'm in for, and boy is it much more that I ever imagined. And I feel pumped at the chance of getting way farther than I ever could have dreamed of!

If you see something you find interesting or if you'd like to listen to me ramble sometimes then feel free to follow or ask questions. I'll be updating at a steady pace.