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.

Be sure to check the bonus video-clip at the end of the post! I guarantee it’s worth it!

Drink whenever:

• Arnold is first seen, at the start of the movie (that means: not chronologically). Everyone cheers!
• The title of the movie is seen or heard. In honor of “End of Days“
• Arnold says “HU-ARRRHHEEH”, or a variation thereof.
• Arnold drinks alcohol (we have to support him).
• Arnold has violent (the definition of “violent” is up for discussion among the participants) PHYSICAL pain.
• Someone humanoid is killed. Large amounts of deaths is drunk continuously. In honor of “Total Recall“.
• Arnold makes breakfast (double, if it’s in a blender).
• There is a reference (has to be accepted amongst the crowd) to another movie (double, if it’s with Arnold). In honor of “Last Action Hero“.
• Arnold meets or sees himself in any possible way. In honor of “6th Day“.
• Someone (double, if it’s Arnold) says/yells “get down!” or a variation thereof.
• There’s an explosion (minimum-size has to be agreed upon in the crowd).
• A car chase starts (other gasoline-driven vehicles also counts).
• Arnold changes weapon (unarmed included). Weapons only counts if used, thus it doesn’t count as “unarmed” if it’s from one weapon to another.
• Arnold changes vehicle (same properties as the rule above).
• A fence or a variation thereof is mentioned/used/plowed down, in any way possible.
• A party is mentioned (double, if it has any connection to Richter).
• A national monument of the United States is seen on screen.
• You call out a rule, and the crowd disagrees (You lack discipline! You can already drink when you want – don’t make people drink under false premises without getting away with it).

Empty the bottle/glass whenever:

• Arnold yells “GET TO DA CHOPPA!”
• The bad guy(s) dies. Again, in honor of “6th Day“.
• Arnold dies, shuts or melts down, or anything else that renders him “un-functional”, for the rest of the movie.

Also, as a funny coincidence, this was posted a few days ago…

How many times would you drink during it?

For those of you that doesn’t know, I decided to challenge myself in the world of Sanctuary – the Diablo universe, and it did indeed prove to be a great choice. It was a splendid challenge, and the result is – in my own personal opinion – quite great as well.

After the defeat of Diablo beneath Tristram, Etophir – a paladin of Westmarch – travels east to find out more about the order of paladins, that seemed to have been turned to fight his kingdom. As his journey out-folds, he’s given a whole new view on what corruption can really do.

So, why wait? Read it right here, in PDF-format.

As last time, I’d love to get some feedback, and hear what you think of it – it’s my only payment from writing it, after all. As a result of that, I also updated my Fanfiction subpage, to better reflect the new work.

Last time, I stayed within the familiarity of the Warcraft Universe, with the story “A Change of Ways“. The advantages was that it has a rich lore, with tons and tons of details and places, and the more obvious thing that it’s the universe I’ve spend the most time in, so far. But, what’s a competition without a challenge?

With that in mind, only two real universes remained: Diablo and Starcraft. Being more a fan of dark fantasy than science fiction – although I do like both – and knowing something about Diablo, I chose the realm of Sanctuary. The lore is less detailed, and lots of stuff is still clouded in mystery, which makes a lot of nice openings for a good story.

So far, I’ve gotten a plot shaped, and slowly iterating through it and adding details, fleshing out characters and figuring out what part they’ll have. The main thing I want to do, is tying the various games together, and make further connections, as one of the things I’ve been having on my mind lately is just that. Looking forward to seeing how the story will turn out. This time, I shouldn’t have a problem with with time running out – I hope.

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.