It’s a gift.


I think… I think I’m done. It’s a little Vampire Survivor clone (I guess someone invented a genre title, Horde games, for this now) that started out as a one day exercise and grown to become so much more.

You can play it here or in its own dedicated window, if that’s what you prefer.

The initial concept for this game took one day to finish. Getting most of the game mechanics working took about two more weeks. The rest of the minor tweaks and balancing… took a month and a half. All in all, I’m happy about the result, especially since it actually runs relatively smoothly on real hardware once I’ve stripped out and rewritten some of the more computationally expensive components – like per-pixel accurate collision detection. I think I have literally run out of storage space to develop for actual hardware though – any major feature that I try to add would break the build file that I try to create.

This was created for my niece, Sophie, with a small cameo from her cat Jiji. Jury is still out on whether she’d like this or not. Fingers crossed!

In The Beginning

Wall 2 was one of the first games I created, all the way back in 1996. It’s an unholy mashup of Breakout and Pong that doesn’t quite hold up in more ways than one, but I would occasionally still go back and play through its arcade mode. For one thing… it’s actually a finished game, unlike a few others that I’ve attempted to make in that era.

(warning: there’s a buzzing noise that happens when the game first loads)

I’m still amazed at how far things had come. Here’s a game running inside an emulator of an OS written in an interpreted language running inside a browser application on top of another OS.

Oh yeah, and then the sequel that came more than 20 years later somehow managed to run at a lower resolution, with less colors and features:

But it warms my heart to find a new platform that works for me after the demise of Adobe Flash. It also took far less time for me to complete this “sequel” compared to the original (days versus months).

And in the spirit of Wall 2, this is very much an introductory project for me to dip my toes in the water of a new system and platform. There’s far more interesting thing that MakeCode Arcade is capable of, in spite of its original intent as a simple block based “my first game dev” platform for young’uns.

One last bit of trivia: Wall 1 was the first game I created that used a dedicated graphics mode (13h) as opposed to building graphic blocks with ASCII characters on screen – it was literally just Pong.

This Simultaneously Amuses and Infuriates Me.

I’ve started making games again since Adobe Flash died a horrible death, so that’s exciting. There’s tons that I want to write about in the days to come but here’s a preview of things to come:

It took me a week to kind of finish the thing that I’m working on, and for one reason or another I needed to make a quick and dirty screensaver…

This thing took 10 minutes to make. Tops. And it’s almost as good as the one week long game. Almost.

See title above.

Design Diary Monday: From Pirates to Bar Fights in Less Than Seven Days

Before I move on from Pirates to Bar Fights, let me finish explaining how the revised pirates duel work. The trinity (Strike, Parry, Focus) forms the core of the system. Because focus is not an attack but a bonus to another action, I added another card that’d benefit directly from focus and adds a little randomness to the game, hence Unload. Since Strike at this point would have advantage over two cards (Focus and Unload), I’ve added one final card that’s sort of a bigger counter to Strike – and that’s how Brutalize came about.

Staggering as a status was added to the game to resolve some of the hard counters between cards. Focus was added to shift the attributes of the cards so the counters would work differently from one turn to the next. This is all nice and well, except… well, it isn’t. The web of cause and effect gets fairly difficult to explain, and ultimately the complexity counteracts the attempt to reduce a sense of randomness to the card choice – between the focus buff and the stagger debuff, there’s way too many combinations of resolutions for any normal player to keep track of.

And then there’s the multiplayer version of this game, where you choose an attack and aim it at another player, then they still simultaneously resolve by order of priority… it’s just chaos from that point on. Honestly, I would still like to run a small test with these rules just to see how chaotic the attack guessing game goes, but I never got a chance over last week, and I felt like the premise should stay, but I should stop trying to make the game so deterministic.

Let’s introduce some chaos into the game.

I watched a rerun of Dead Man’s Chest again over the weekend (is TNT just showing this movie every other week?), and the bar fight scene gave me an idea. Let’s remove focus and brutalize and start fresh with a new trinity:

Now, let’s change Unload into some form of liquor. “Unloading” now means smashing the bottle on someone’s head. We’ll also untangle all the priorities and simultaneous resolution so besides parrying to counter, all the actions are played one card at a time. We’ve untangled the game completely and now we’re just playing a basic “take that” game (every turn a player toss a damage dealing card, some cards are there to block attacks, etc).

But the liquor part of the game can get interesting. Suppose there’s a running tab on the amount of liquor smashed and consumed, wouldn’t it make sense that the guys who lose the fight would have to pay the tab somehow? What if the liquor can be consumed to strengthen strikes? We arrive at the following rules:

  • There are three main types of cards, punch, block, and liquor.
  • Liquor can be consumed or smashed onto other people.
    • if you drink it, you play it in front of you and the cost adds to your personal tab, but your punches becomes stronger and you draw more cards based on the cost of the liquor, gaining a significant advantage.
    • if you smash it, you use the card as an attack on another player. The discarded bottle adds to a growing pool of damage tab that someone will have to pay.
  • Punch card deals direct damage. Every drink you have makes your punch stronger.
  • Blocks reduce or deflect damage, and are played as reactions to other players’ attacks.
  • If a player sustains X damage, he or she is knocked out and must pay for everything in the damage tab.
  • A player can also play a card to try and walk out of the bar fight. If he or she is attacked that turn, that player can’t block and the attempt to walk out also fails. If the player does walk out of a fight:
    • if multiple players walk out on the same turn, they share whatever has to be paid off that turn.
    • if there’s still players left, add up the personal tabs of the players leaving and each player pays an even share.
    • otherwise, you’ll have to pay an even share for the damages as well.
  • When there’s only unconscious players left in the bar, all unconscious players must pay an even share of everything that’s not paid for.
  • To give the player who is most invested in the fight an advantage, whoever is the most drunk (with the biggest personal tab) can go first.
If the numbers work out right, there should be an escalation of cost built into the game that’d make it interesting for players to decide when to stay and when to quit. There’s a much bigger factor of randomness, but I think the new design is “light” enough that more randomness might actually make the game better.
And now, back to assigning numbers. I hate this part.

Design Diary Monday: Revising Rock Paper Scissors Since 2012

Human creativity is weird. If you force yourself to think about new solutions to a problem sometimes all you can get are dumb fixes… but if you step away from the problem for days or even weeks, sometimes the solution would hit you on the head like an anvil out of nowhere. After so many previous failures, I’m not so ready to call this the design that solved all the problems, but at least I feel like it’s getting somewhere again.
In other news, I’ve learned that tags can do something other than serve the mysterious SEO gods. I’ve added a new tag to keep track of all the posted related to this particular game’s design progress:
To more or less reboot the design process, I’ve decided to take out treasure points, targets of opportunity, and all the other mumbo jumbo that’s related to scoring more points… I’ve reduced the game back down to its basics, a rock-paper-scissors game. I’ve also mentally sort through all the feedback I’ve gotten from previous play tests and incorporated a few suggestions:
  • Sometimes, randomness is not such a bad thing. While it reduces the deterministic aspect of the game, it creates situations with calculated risk that’d at least give a bad choice some chance to make a comeback.
  • Trying to resolve combat from a single card choice was probably a disastrous idea. Without a series of shifting parameters and each card choice giving the same probability to win or lose, the choice becomes completely random even if the decisions are weighted differently – as long as there’s exactly one hard counter to each possible choice, players are still forced to consider each choice evenly.
  • And building on the previous point, there really needs to be some way to predict player behavior in order for players to decide on an action instead of randomly picking one.
So I’ve added an additional mechanic to the basic “deal X damage” formula: modifiers that’d affect actions in the next turn. And with that, here’s the component dump of the latest pirates card game:

While still themed around pirates, the game is no longer about ship to ship combat with captain and crew – now we’re down to fighting over treasures on an individual level. A simplified list of rules is as follows:

  1. Each player begins combat with 5 cards.
  2. Each player plays a card each round.
  3. Higher priority cards are resolved first. If multiple players have cards of the same priority, the player with higher initiative takes precedence.
  4. As a player’s action is being resolved, grab the highest priority token that’s not yet taken.
  5. If a condition is applied to a card’s action, resolve them in the order they’re listed on the card.
  6. If a player takes damage and that player’s action card has not completely resolved, apply a stagger token to that player’s action.
  7. If a focus token is available, consume it whether the card has a focus condition bonus or not.
  8. A player who takes 3 points of damage or more is knocked out.
Balancing are a-coming, so I’ll discuss the cards and the justification for the rule changes in detail next week. In the mean time, here’s an example game of how the game works in its current form:
(Oops, I’ve forgotten to put down stagger tokens completely. Oh well, the player who takes damage is usually staggered…)

Bottom player plays strike and gains initiative. Strike can stagger gun Unloads and make them miss. Strike also deals light damage.

However, strikes can be parried. Parrying deals damage to the aggressor to inflict stagger (and it does resolve, since stagger for strikes resolve after the normal action).

You can unload guns on a player that’s standing around ready to parry for a 1 in 3 chance to deal 3 damage (in most circumstances, winning outright). Better yet, you can play focus to gain the focus buff. The buff makes the next gun attack 100% accurate.

However, since focus has lower priority, the bottom player gained initiative that round. In the next round, the players have the same priority, but since the bottom player maintains initiative, the bottom player brutally finishes the top player off by dealing 2 damage. Mmm, this is not exactly what I want to happen… Yup, changes are a-coming.

Next week: Justify your game.

Design Diary Tuesday: I Hate You, Drawing Board

… but it looks like I’ll be going back to it for a bit.

(this is game in progress that’s being discussed, just as a refresher)

There’s currently a lot of fuzziness involved with how projects are chosen and how players gets rewarded for making progress, completing projects, or exposing other player’s incompetence. Based on the results from yesterday’s calculations, the deck would also need to be more than 40 cards thick – maybe it’d go all the way up to 60 or even 80, an uncomfortable number to print play decks with.

I’m also being constantly tempted to add complexities to the game. What if when you undertake a project, you can boast or bid how far you can go with it? Go bigger for more funds and reputation, but get more blame for its failure. There should also be rewards for completing the same project before another player to earn extra rewards.

But adding all these things don’t change the fundamentals of “cheat” or “not cheat”. I really hope I can come up with ways to accomplish different levels of deception, with bigger lies yielding bigger rewards.

(Belated) Design Diary Monday: I Am Not a Wizard With Spreadsheets

One of the many weaknesses I have with game balancing is I have an extremely poor background in statistics, and apparently statistics is all the rage as far as balancing numbers are concerned.

A few weeks ago, a certain reddit topic brought me to the use of hypergeometric distributions. My current work in progress idea surrounding deception will make heavy use of the concept of “BS” style card game and some type of melding card game.

I’ve started with this google spreadsheet. The only relevant table is the third one at the bottom that shows the probability of the player having N or more cards after drawing X cards from the deck. The one published above uses a standard deck of playing cards, and calculates the probability of having N or more cards of the same suit.

If each project type in my game idea corresponds to a single card suit and the values doesn’t matter, then the distribution would show me how many cards a player might need to complete a project on his or her own, using materials (cards) of the appropriate suit.

Just to throw it out there, a 5 card project size seems to be a reasonable number. The distribution tells me that there’s a 50% chance I’d have 5 cards of the same suit… after drawing 18 cards? That can’t be right.

The percentages are deceptive. The number tells me the percentage of all possible hand of 18 cards… but I’ve been starting with a hand of 5 cards and consciously made a decision to pursue a suit that I already have – often with 2 cards. Adjusting the starting numbers to a 47 card “deck” (since I’ve drawn 5 cards already)  and 11 cards that’d yield me the same suit (since I already have 2 in my hand) yields a much more reasonable 50% to get 3 more cards of the same suit at the 11th draw… until I realize that I’ve already drawn 5 cards in this case so technically I’d get the 50/50 at the 16th card. Replaying a few hands with a real deck of card confirms this – getting that “flush” is actually pretty darn hard.

Interestingly, there’s a 62% of having 5 cards or more of the same suit in the beginning of a 4 player game, if each player draws 5 cards to start with. If the game allows trading, the chance of getting those 5 cards would be significantly easier.

These numbers, once I mess around with it some more, can tell me a lot – it sets boundaries for quantities that are within reason, and with these guidelines I can come up with a card mix for my initial test. It’s probably a lot harder to look for the fun in those numbers, but I firmly believe that’s where the number crunching part of game design stops and the art part begins.

Tomorrow (well, later today): the promised initial numbers for the deception game. This design is going overtime!

(Belated) Design Diary Monday: Deception

Last Monday I began brainstorming ideas central to the Pirate movies, and after mulling over it for the rest of the week I’ve found the concept of deception to be the most intriguing. Deception was present, or it was intended to be present, in every stage of the pirates card game design, where part of the crew you set sail with are suppose to be hidden, but in practice what your enemy brought to a fight never seemed to matter as much as your own composition.

So I kept the idea of deception as the central mechanic and narrowed my focus. When it comes to deception, two types of games come to mind: hidden role games like Mafia or The Resistance, and hidden value games like Dead Man’s Chest’s very own Liar Dice (okay, the movie didn’t invent the game, but it certainly brought it to most people’s attention). Of the two, I’ve come up with an idea to work with hidden values: the art of running researches and the possible deception involved in securing funding while having honest breakthroughs versus lying through your teeth.
In the beginning, I’ve started the idea with two very basic concepts: research projects and research breakthroughs, which supports the projects. The projects are public knowledge: everyone knows you’re working on a project and trying to complete it in time. The breakthroughs, however, are hidden by default: you may have materials strongly tied to the project (yellow), “wildcard” materials (green) that supports the project but not to the degree of the “pure” stuff, and fake materials (white) that are made up stuff to prop up your project’s credibility. The deception surrounding your research’s actual progress forms the core idea of the game.

Expanding on this core idea yield the following:
Let’s say your research’s real progress is the sum total of your relevant material’s strength (let’s just call breakthroughs “materials” for now). Strong materials gives you 2 points, related materials 1 point, while made up materials obviously 0. At some phase in the game, investors would come in and invest more funds based on the number of materials you have, not the actual progress of your research. In turn, you can pour those funds into acquiring more projects and getting actual breakthroughs. This sets up the incentive for players to risk putting down fake progress because it means they’d get themselves the real stuff faster. We still need a reward mechanism for busting other people’s lies though:

Here is one possible implementation of the investigation mechanic. An opposing player must spend some of the grant money for a private investigation into some aspect of the research. The more you pay, the more through the investigation becomes. For example, a cheap investigation can only randomly expose whether one of the materials is completely fake; another one might reveal several pieces of info at once; the strongest would probably tally all the materials and wager the actual progress is below a certain level. Problem is, I don’t feel like there’s a good reward to a successful investigation that is thematically and mechanically sound. I suppose the one paying for the investigation might get money from a lawsuit, and maybe this model is ultimately the best one (since it is extremely simple), but the one that I’m going to try developing actually looks like this:

So I’ve added one more layer to a research project, that is when you have enough actual progress, you can open up those materials to sell a real product for money and reputation. Reputation becomes the game’s real measure of victory, not money. It gives research projects a natural life cycle so there’s no need to clog up the play space with projects where all progress are real, and I can balance the game to give honest players appropriate rewards. I can also set up a reward for investigations that thematically makes sense – reputation – where exposing other researcher’s bad practices would earn you some reputation but falsified claims might actually give you a reputation penalty. That part of the diagram might be changed, to be honest, but I think I’d very likely keep the “release a product” part of the project life cycle – it completes the game in ways that the simple version simply cannot.
I have some other ideas such as having collaborating research partners (splitting funds and reputations), or special restrictions attached to specific projects, but the general idea is sound. The next phase of the project involves a bunch of heavy calculations to come up with an initial set of numbers attached to all the different components of the game. Math… I guess… I’ll do that next week. Yup!

Design Diary Monday: Brainstorming Solutions

Alright, so starting from this week there’s no more scripts for me to follow. I’ve arrived back at the point where I need to make changes to the game, and I’ll be spending the time on these posts actually working out problems instead of reporting results from the past.

The first order of business is to try and see if the pirates card game, in any form, is salvageable. I had a chance to watch some of the Pirates of the Caribbean movies over the past few weeks, and I was reminded of the things I wanted to portray:

  • Hunting for legendary treasure (Aztec gold, the compass, the heart, what have you)
  • Deals and betrayals
  • Satisfying broadsides making ships explode
I didn’t think I was successful in getting any of those points across. I’ve never come up with a convincing way to make players go after specific pieces or types of treasure; none of the versions ever got to a stage where temporary alliances made sense. The closest I’ve gotten were the ship battles, back when there were dice rolling… getting a good cannon roll and making ships explode on the spot felt good, but that was all the way back to the first version of the game and I don’t want the rules to ever get that complicated again.
Honestly, let’s just pretend I have the Pirates of the Caribbean license for a moment and think about how I can get the back and forth wheelin’ and dealin’ between all the characters work as game mechanics. In Dead Man’s Chest,
  • Jack needed the Dead Man’s Chest to avoid his fate of servitude
  • Will needed the Compass from Jack to secure Elizabeth’s Release
  • Elizabeth acquired the Letter of Marques but needed the Compass in return
  • Jack agreed to trade the compass for the chest…
Actually, this is clearly not as complicated as I remembered, is it? An easier way to describe the formula is,
  • Player 1 is after item A
  • Player 1 has B but for some reason cannot directly reach A
  • Player 2 is after item C, and he can trade B for C
  • Player 2 now has the option to get A so he can trade with Player 1 for B, or steal B from player 1, or negotiate with a player 3 directly for C instead…
Okay, the trading is getting Catan-ish. I can work with that. Ultimately, I think I’ll need to introduce secret objectives to the game: for simplicity’s sake, let’s say each player needs to acquire some unique item that won’t come up as a found treasure.
Secondly, there would be time limited opportunities that allows items to convert from one type to another. probably a set of cards that shows the item obtained with the item requirement in small print.
Thirdly, items randomly appear and the players have low influence on the items they can get their hands on. It sets up scenarios where two player can trade items that’d benefit each other. There needs to be justifiable reason for trade to make more sense instead of just killing or blowing up each other, which should be an option…
I guess this is how the game would proceed. Next week I can continue this work or try and fix the rock-paper-scissors combat!