The premise was rather simple: Within two days, we had to construct a drinking (yes, indeed) game, test it (no further details were given of the nature of that, but we did it the only right way – with beer) and present it for the rest of the class. Challenge accepted!

I find it quite amazing that I never thought about posting it until now, because it was (or rather: is) a very nice drinking game. It has certainly done its part in delivering as a proper drinking-game should. The only negative part you could say about it, is that it might be a bit tricky to find 9 cups and a coaster – but at the very least you do not need any cards or any number of dice.

Anyway, onward to the important part – the rules:

THE SETUP AND WHAT YOU NEED:

• 3 to 6 players (more or less is possible, but not recommended).
• 9 glasses for the board (5×5) placed in a square (3×3).
• A middle-marker (a coaster is perfect for the job), placed under the middle cup. This only serves to make it easy to see where the middle is.

The below drawing shows the outer square-positions with the x’s, the initial glass-positions with circles, and the coaster as the square.

Every participant buys an amount of beer (it doesn’t have to be beer, the crowd just have to buy the same kind of drink), best done in a pitcher or likewise. The glasses are then filled up to 2-3 fingers (or more, depending on how hardcore you’re playing). Shot-glasses are excellent at this, as they can limit the maximum contents, while removing the need to check your pouring.

A TURN IS PERFORMED AS:
The first player takes a filled glass and jumps (vertically/horizontally) over any amount of cups (similar to the game “Checkers”). The outcome depends on whether or not the glasses which has been jumped over is empty or full.

• Each jump is one cup maximum, but you can take several jumps in one turn.
• You can jump over both types of glasses in a given turn.
• You may not end up outside the 5×5 board.
• You may not jump over the same glass twice during a turn.
• You may not use the same glass, as the previous player used, to jump with.

The outcome of a given turn depends on the amount of each of either full or empty cups. If a glass is full the next player drinks it, else the current player fills it from his pitcher. If 3 or more empty glasses are filled during a turn, you can fill extra in filled glasses – if you jumped over any of those.

Another choice is, instead of moving a cup, is to move a filled glass from the outer circle to an empty spot in the inner circle. By doing that, the player must drink it, then fill it. This does NOT have to follow the jumping rules.

In case there’s no moves left, the given player drinks all full glasses, fills all of them, and reset the board to the starting position (The 3×3 square).

END OF THE ROUND:
When all players’ pitchers are empty, and there’s no more beer to fill in the glasses, the players will eventually end up having no more possible moves, and the board is reset to the original initial 3×3 view, with a new round of beer – if possible.

The game was created along with Julian Møller, Mads Johansen and Steen Nordsmark Pedersen. Looking forward to the next game, sooner rather than later.

It started with the following link was thrown out at the internal Facebook-page for the Game students at ITU: http://videogamena.me/

As fate would have it, people started posting their favorite hilarious names. Lots of likes and – at least from my part – local giggles and burst-laughs was done. Then, it took a turn, when the idea of having a Game Jam was added, with making up a game based on what the generator spat out.

However, in the end, just when I tweeted the link, I figured a very simple – yet rather hilarious – game could be made from it. The rules are quite simple:

First, gather a few people that wants to play. Not too few, not too many (4-6 would probably be perfect).

The following is then needed:

• A device that can display the Video Game Name Generator.
• A block of paper and a writing device, per player.

A person activates the VGNG, and the resulting name is spoken to the crowd. Each player now has a maximum of 5 minutes to come up with the best game-idea, based purely on the name. The winner is judged by social voting amongst the players. Naturally, you’re not allowed to vote for your own game.

Looking forward to seeing if the idea actually holds. At the very least, I’m going to see what it’ll turn to!

Awesome, yet bad idea: Get Sylar to playtest your game. No matter what, he’ll always know how it works.

See, the joke is – like many other jokes – requires some background knowledge, which at this point is two-fold: “Who/what the hell is Sylar?” and “Why would it be a bad idea?” The latter is probably the less important, but it still adds some depth to it all.

Most people will get the Sylar-part, as many have seen him, Zachary Quinto, in the role of Gabriel Gray, in the Heroes series. The series is basically about various people who gets super powers through the genetic evolution of the human race. Sylar’s super-power is simple – he knows how things work. I guess that’s a given from the tweet itself, but that’s how that is it. Unfortunately, he’s also the perfect super-villain, as he spent that knowledge for his own benefits, and was always scheming on how to achieve more power.

If we ignore the parts of him killing every single one of us to achieve the knowledge we have, being a fictional character, as well as stealing our super-powers, wha- . Yes, super-powers. I have some, you might not, but some of us have them. Carry on, it’s OK, we can’t all be super heroes after all.

Now, disregarding all those bad things, why would it be bad to have a person who knows everything play-testing your game? Obvious – he knows how it works. The best testers is those that tries the product for the first time, and then tries to figure out how the game works, and slowly learns it – as it was intended in the first place. Not only that, but all the little quirks would be hidden until they got told or finds out by accident. Sylar? He would simply know it – even the secret moves that the programmers added in, but didn’t officially finish yet.

After all, the process of game-testing is about figuring out what’s wrong in the game, what can be made better – not playing a game you already know all the little details about. The fitting quote here, is from Samuel Beckett, heard during today’s Game Design lecture:

All of old. Nothing else ever. Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

I guess that’s also why jokes should never really be explained. Unless it wasn’t really a joke, but simply truth in compressed form – and thus, “it’s funny, because it’s true” applies. Success!

To give a quick rundown of the project, it was done by writing a program in C, that was sent via a serial port to a ZiLOG Z8 Encore! Z8F6403, and from there we could listen via a Telnet-based Terminal (from another serial port), and/or via the on-board LED display (which I got a nice example of here: The Failboard), and get inputs by pressing the 3 buttons. The first week was various exercises to get used to how it reacted to various things, how to control its register-calls, and coding C in general. The various exercises was naturally elements that would all be used in one way or the other in the final project. The last two weeks however, was where the interesting stuff started happening, as we finally got to know the final objectives: Create a game based on “ReflexBall” (which is basically ArkaNoid, without any objects to hit), and develop it into either (you guessed it) ArkaNoid, or something else entirely – pretty much freely chosen, but it had to satisfy certain criteria.

For the fun of it, we chose the latter, and got the idea for a – potenially – pretty fun idea: Gwardar. Naturally, that name doesn’t say much, but it should help a lot when looking at what a gwardar actually is: a snake. So, our idea was a hybrid game of ReflexBall with Snake elements, which ended up being quite fun, and the actual game was – in fact – pretty fun as well.

I mainly worked on the gamefield – where the snake bounces around, collision detection – which was a much more essential part than for an ArkaNoid-game, as the ball/snake shouldn’t be able to hit itself, and react differently when hitting different things, and the ball/snake itself – which made sense to do together with collision, as that should be based upon where the ball was.

The first had some interesting challenges, as we only had a practical resolution of 63 x 21 “blocks” (columns and rows in the terminal-window, respectfully), and still wanted the ball/snake to be able to move with more than 8 different directions. As thus, we gave each block a 10×10 background, essentially giving us a gamefield of 630 x 210, which gave many more possibilities in terms of directions (early screen here, showing it). However, to properly do that, we had to ensure that the ball/snake always moved to a new block, which was done by scaling the directional vector, so that the numerically longest of x or y was exactly 10 (or: 1 block). Any more, or any less, would mean that it could potentially skip, or end up in the same block.

In regards to collision-detection, it was done by first detecting what was on the target block, judged from the directional vector, change it in case the target was a wall or the “striker” (the board the player controls), grow in length if objects was eaten, or die, in case it was itself, or the void below the striker. In the case it was hitting something that would change the vector, the new target block was checked, and the ball would only continue moving in the case that there wasn’t anything there – or it was an edible object. The tricky part about the collision was detecting when it was hitting itself, and let that be handled properly. To explain that, it’s probably best to explain the properties of the ball/snake first.

The ball was given a “history”, of up to 50 blocks, that kept track of up to the previous 50 positions it had been placed on the detailed gamefield (that is, in the 630 x 210 grid), which initially served as a way to “erase” the balls previous position when it was redrawn at a new position, but later – when the ball turned into a snake – also a way to show the tail itself, by only erasing the tail length’th object in its history. In the end, the history was also used to place objects whenever eaten, at the very last position of the history – which turned out to look like it was random, especially when the tail length was short.

Getting back to the collision, it was obvious that low angles (meaning a directional vector of (10,1), for instance), would most likely cause the ball to “hit itself” upon bouncing against a wall, which would make it more or less impossible to ever reach the maximum length, or simply get very far at all. Still, it should naturally be possible to hit the tail, so we decided to simply ignore the first few parts of the history, when checking collision, so that the ball/snake had “time” to get free of itself. Hitting directly into a corner, would however still result death, as the overlap would be too great.

The other collision-based problem that surfaced was when “crossing itself”. A problem we never actually experienced exactly, but would look incredibly awkward if it did. Basically, it could happen as it would never actually hit itself, but on both sides, on points where both the “rough” x and y coordinates had changed (that is, on the 63 x 21 grid). Basically, it was done so that every time a situation like that happened, the collision-detection would check if both the coordinates (current_x, target_y) and (target_x, current_y) was in the ball’s history. In that case, it would have struck itself.

Now, going away from all the technical matter, the game proved to be very fun to play as well. The idea has been tried before, and there are quite many possible ways of combining the two basic games. In my personal opinion, ours was a success – but that’s always easy to say as one of the developers.

As a last word, here’s another screenshot, which should catch the idea pretty well. Try to imagine it with the tail being up to 50 “blocks” long.

And so, there I was, taking a few minutes to ponder why I had even chosen it. The most immediate answer would be that I’ve gotten to like the who theorizing-part of discussion/argument for various stuff I find interesting. Delving a bit deeper, I – which I for some reason can’t recall writing here – had a course called “Methods in Language-Psychological Analysis” (!), which gave my general critical point of view a nudge in the right (wrong?) direction. I like having a real way of pointing out faults, inconsistencies and weak statistics and quoted stuff out in various texts – even if it’s only done “because I can”. That’s just me.

However, there’s also another reason, which I had probably known all along, but came to me when I said there wondering what to say. My writing side had been in me since early elementary school, and had most likely been suppressed (or just felt too natural for me to notice it), as my force lay in the numbers. Proving something was right in those subjects is easy, as it can be proved by applying “this formula” to values “a” and “b”, which will then always give “c”. Naturally, that doesn’t make the whole work trivial, just meaning that, if performed correct, there would in fact always only be one answer. And, sadly enough, Real life just doesn’t work like that. We have these dynamic values that gets applied here and there. And, as a reader of this, you know that I’ve “recently” gotten my urge of writing back.

All in all, I’m really looking forward to following the course and learning more of the fine arts of rhetorics, and getting to know Captain Obvious a bit more.