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]

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.

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!

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!

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

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.

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.