We intend to create a world where everyone will enjoy our games without exception.

2012/03/03

UHM at GDC

Filed under: Uncategorized @ 22:47

UHM will be present at next week’s Game Developers Conference in San Francisco, armed with demos of exciting new games!  If you’re interested in meeting up, just email me or Teddy here at UHM.

2012/02/15

Banker’s Dozen Game Carnival Talk

Filed under: Uncategorized @ 19:38

Last year I showed Banker’s Dozen at the UCLA intermural game carnival and It looks like they recorded the talks. Here it is, for your enjoyment and edification.

2011/07/19

A 2-Minute Postmortem of a Game Made in 2 Hours

In the midst of a large project – my graduate thesis game – I decided on a Saturday morning that it might be enlightening to take a brief step back and review some of my prior work. However, I wanted to mitigate the amount of time spent in this retrospective, so as to get back to my passion project quickly.

So I decided to look at the game I have made most quickly – Hello World Double Jumper – made in 2 hours and thusly named because I was working so fast, I neglected to take the “Hello World” print statement out of the template I use. Hello World Double Jumper is a 2-player competitive game in which the goal is simple: jump on your opponent’s head more than she jumps on yours, and collect as much jump power as you can while doing it.

“It would be silly,” I then thought, “to spend more time reviewing the game than I spent making it.” And so, I came to what you will hopefully now read…

Hello World Double Jumper:
A 2-Minute Postmortem of a Game Made in 2 Hours

  1. I spent 45 minutes just figuring out the idea, and was left with just 75 to make it. I just sat there, thinking “That would be cool! …No! Scope down! Oh, that would be cool! No, scope down!” It worked, but it was painful to cut as I was brainstorming.
  2. Make Reusable Code: I probably saved 30 minutes by having a template for my Flixel project. But I could have iterated even more had I used movement code from an older project.
  3. Playtest! I actually finished with 15 minutes for playtesting, and it made a huge difference in the final product. Remember to playtest!!
  4. Screen Scale is HUGE: I spent a while trying to make the characters just the right size on screen. In the first iteration of the game they were far too big. The game gained a ton of verticality when I scaled them down.
  5. People will at first be far worse at your game than you are, but quickly, you will see some players become better than you. I saw many of my friends surpass my skill at the game, and I learned a lot about what I had created by watching the strategies that THEY…

Time’s Up.

2011/07/05

Vikingr’s June Prototype

Filed under: Vikingr — Tags: , @ 19:35

I vowed recently on the development log to spend two more working days on combat and then share a playtestable prototype. Well, I took a little vacation, I had to wrap up another project, and then there was the holiday, so I finally reached my goal today after an estimated four solid engineering days within that broad time interval.

So that’s good news! This is an iOS project that ought to work equally well on iPhones and on iPads. I’ll be distributing this build using the Testflight app, so please visit this link to get registered and send me your device’s unique identifier.

This month’s (well, last month’s) prototype covers the core combat of Vikingr. In practice, it would be situated in a larger, more strategic game of viking household management and political simulation, forming an intense, risky, and uncertain means to fame and fortune. Raiding—or being raided against—is one of the emotional high points of Vikingr. Please keep in mind that all art and UI are temporary, and the introductory screen is best thought of as a “debug menu”. One notable difference between this prototype and my future goals is that not all visits to other households should be raids: even in the context of viking raids, a smart raider would prefer to trade with a household that seemed too tough a fight to pick.

Vikingr requires the use of Apple’s Game Center service. Before you launch this game, please log out of Game Center using Apple’s Game Center app. Vikingr will ask you to log in to a special “Sandbox” version of Game Center, and you should create a new user account for this “Sandbox”.

You’ll need someone else to be playing on their device at the same time; alternately, you can choose “Fake Attack” or “Fake Defense” to play both sides locally. If you do play on the network, I highly recommend WiFi over 3G connections—I haven’t put much effort into resolving bugs with 3G multiplayer yet.

For now, everyone is in Iceland and the only valid attack location is Iceland. If the UI tells you that there’s no one to raid in Iceland, go ahead and “Fake” it.

Once your raid begins (or once someone raids you!), tap one of your four vikings (with the green circle at their feet and green names) to activate him. Once active, you can change the direction he’s facing with the arrow buttons or change his combat stance to “Reckless (Attack)”, “Prudent (Attack)”, or “Cautious (Defense)”. There are also two buttons behind the character; the grey one surrenders and the red one flees. In either case you lose control of your viking, but they might escape the fight with their hide intact. Viking culture looks down on retreat—even though your viking’s surrender may be rejected by your opponent (with deadly consequence), at least he won’t live with a reputation as a craven coward.

To move one of your vikings, drag him with your finger. Valid movement destinations will light up blue. Move your finger to another hex and release it to start him moving. After this movement, you may notice that a number on top of the viking is slowly decreasing; this viking cannot move again until this “fatigue” counter returns to zero.

A viking in an attacking stance will strike at anyone in front of him and will turn to face any attacker. As he deals wounds to others (or as he is wounded!), combat messages will appear. Don’t get too distracted by individual encounters—you can use the many vikings at your disposal to gang up on an individual enemy or to split up brawls into less dangerous skirmishes.

If a viking receives too much damage to one of his six body parts (head, torso, left arm, right arm, left leg, or right leg) it will become crippled and then ruined. A ruined left arm prevents a viking from blocking with his shield, and a ruined right arm keeps him from attacking. A viking with no arms will surrender automatically. Damage to the legs will reduce the viking’s movement radius, and ruination of the torso or head will result in death.

The raid is over when all vikings on a side are fled, surrendered, or killed. Afterwards you may read a textual summary of the battle’s outcomes sorted by each viking’s perspective.

A future prototype will target these combat results. It will recognize patterns in the combat and movement record and grant vikings titles, epithets, stats, personality traits, and other narrative outcomes based on their relationships to each other and to their enemies, and present them in a more exciting format.

2011/06/19

Why Combat? Why Now? What Now?

Filed under: Vikingr — Tags: , @ 23:08

Recently, I shared this design log with my industry advisor. His response suggested that I focus less on the intricacies of a detailed combat system and more on the important narrative goals of the project, abstracting combat as necessary. As I understand it, the concern is that if there are too many choices in and too much design emphasis on combat, it will overshadow the rest of the game in the players’ (and possibly the designer’s) minds.

That said, I want to take this opportunity to justify my design-time expenditure on combat. The importance of feeling like a Viking and the need for compelling low-level gameplay are clear, but perhaps an examination of the perceived need for a robust simulation of raiding is in order. My goal for Vikingr’s combat mechanics is to drive home the sense that fighting is both glamorous and dangerous, drawing a contrast between the slow, steady, safe progression of farming, trading, and political games with the meteoric rise and precarious position of the raider. To that aesthetic end, maybe there is a more abstract interpretation for conflicts between two groups.

My plan at the moment is to spend two more engineering days on the system I’ve already paper-prototyped (and spent some time programming), taking the shortest route from what I’ve got (matchmaking, movement, networking) to a start-to-finish combat scenario with some narrative outputs. Specifically, I’m thinking of some acknowledgements of recognizable patterns: combat style preferences, turnabouts, cowardly or brave acts, and so on–or at least the seeds of these kinds of reports.

If, after two days of design and engineering effort, combat looks like it will continue to be a timesink, I’ll put in some hack and get on with things. That, too, is something I need to learn.

« Newer PostsOlder Posts »