The Road to Golden Mage

Ed: this post was written a few months ago, and subsequently forgotten. Here it is!

Once upon a time I discovered Hearthstone. It was pretty fun – I’d just bought a Surface, so I had a blast using the pen and touch screen to fling Fireballs into my enemies’ faces. It was straightforward, warm and welcoming.

I miss those days.

In time, I grew tired of playing minions, only to watch them get blown up. Removal is absurdly prevalent in Hearthstone, so much so that there are decks that revolve around it. There seemed to be very little respect for a player’s dominance over the field. Why bother setting up a strong board presence when, come turn 5, your opponent tosses out a Brawl and wipes it?

I once heard someone complain about the Silence mechanic – their main issue was that it was boring. I’m inclined to agree, but Silence is but a slice of the problem pie.

I think one of Hearthstone’s biggest issues is persistence.

Why Fight When You Can Flamestrike?

After my aforementioned falling out with minions, I looked to the classes to try and find a new way. It’ll be no surprise that I chose the class that balances board control with powerful spells, high-value class minions and an affinity for magic.

Yep, I went with Mage! Once I saw spells like Pyroblast and Ice Block, I was sold.

Over a long experimental period, I tried to run Mage in various directions; spell damage was the most accessible choice at first, but thanks to general board disrespect and a frustrating lack of survivability, my spell damage minions far too often died before I could capitalise on them.

From that point I assembled what would probably be called either a “balanced” or “unfocused” hybrid between classic Rush and Freeze Mage. A big turning point in my Hearthstone deckbuilding was when I went to a tournament in Wynyard, and lost 1-2 to a golden Rogue. They asked me postgame what kind of Mage I was running: “Is that Freeze or Rush? I couldn’t tell.”

I responded that it was sort of a mix of the two. I don’t remember what they said after that, but it was an exciting question – I didn’t know they were the two popular decks until then! From that point, the seeds of Rush Mage had been planted.

Faster Decks Means Faster Wins… Hopefully

It never occurred to me that another way of ignoring removal was to simply win before any comes out. As such, I threw together a Rush Mage, filled with wonders such as pre-nerf Leper Gnome, Wolfrider and, of course, Mana Wyrm.

I’ve always loved how earlygame Mage has the potential to snowball out of control, or fall flat on its face. Mana Wyrm is crucial to tearing through that 30 health fast enough. On the off chance that you go second, get two and a decent set of cheap spells, there’s a very good chance you’ll win by turn 4.

That said, I had limited success with Rush Mage. I don’t think Mage’s rush potential is as dependable as, say, Hunter’s.

Slow And Steady Wins The Race

After my stint with Rush Mage I took some time to re-evaluate. I’d acquired some more cards by this point, so I set out to make the Mage deck that would take me most of the way to 500 ranked wins.

Others might have been quick to simply label it another Freeze Mage, but they would be quite mistaken.

This deck, bless its soul, was lovingly named Secret Control.

The deck started off with a simple idea – if you can hit them for a total of 30 damage (give or take healing) and not die in the process, you win!

To that end, Version 1 of Secret Control was stocked with the finest stalling cards in the game. Unsurprisingly there was Ice Block, Ice Barrier and Frost Nova, but there were cards like Polymorph, Flamestrike and Fireball, too.

Minion-wise I ran Sorcerer’s Apprentice, Mana Wyrm and a couple of draw cards like Loot Hoarder and Acolyte of Pain.

The most notable part of this deck were three cards: Pyroblast, Ice Block and the incredible Alexstrasza! I was fortunate enough to receive a Golden King Mukla, who lived roughly long enough for me to screenshot him then navigate to Disenchant. His spirit lives on in the biggest carry dragon in the game.

I’m sure I don’t need to spell this out (huge pun), but for brevity I will. The deck stalls until turn 9, drawing cards and freezing/killing enemies with spells, until it can play Alexstrasza and drop them to 15. The following turn, it throws as much damage at their face as possible, throwing down an Ice Block if one wasn’t already up. Ideally they go down to less than 10, trigger the Ice Block, then die to a Pyroblast.

I have heard numerous complaints about this playstyle, citing it as “not fun”. My response? If the game wasn’t so flooded with removal and nonsense, I would have taken minions seriously. Give a man a Flamestrike and he will wipe your board.

Ice Block in particular is a card that impresses me to this day. It was good in Secret Control Version 1, but something happened that gave birth to my most loved deck in my entire Hearthstone playtime – a deck in which Ice Block is even more valuable.

It’s A Secret To Everybody

Some more time passed. I’d experimented with other classes, but none of them felt as right as Mage.

Expansions had been released (Naxx, GvG and The Grand Tournament), and we were all drowning under Dr. Boom and his friend, Mech Mage. I refused to play Mech Mage, since I did not care for that playstyle anymore.

Instead I looked around and found some incredibly powerful options for Secret Control Version 2. I’ll go into detail here, because these cards are worth it.

Illuminator was the key element that let me do away with a lot of other minions. It’s a 2/4 for 3 that heals you for 4 at the end of your turn if you control a secret. It’s pretty hard to kill someone if they’re healing for 4 (or more!) a turn, especially if that secret was a Counterspell and you just wasted an Assassinate on it!

Duplicate is a wonderful secret that gives you two copies of a minion when it dies. Of course it only works on your opponent’s turn, but there’s just so much potential. Throw it down with Illuminator and all of a sudden you have years and years of sustain. Use it on Alezstrasza and get two dragons back!

Ethereal Arcanist was a surprising find, since he’d existed for a while. I never realised how good this guy was until I saw what happens when people don’t kill him right away. The synergy with Ice Block and Counterspell is insane.

Mad Scientist was the card this deck needed to help make the earlygame bearable. Having a Duplicate and Counterspell on the board at the end of turn 3 is a pretty solid lead into Ethereal Arcanist.

Doomsayer took over the role of board clear with the help of Frost Nova! It sure is hard to kill a single minion when all of yours are frozen.

Suddenly I had a really dynamic, powerful and flexible early/midgame. I could do goofy plays like throw out a Doomsayer and Illuminator out on turn 5 with Counterspell in play. At turn 7 I could wipe the board with Flamestrike, or I could drop an Illuminator and an Arcanist and force them to choose.

I loved the new and improved Secret Control. It took me all the way to 500 ranked wins, and to this day I have not played a deck I’ve enjoyed more.

What lies ahead for me? Only time will tell.


Fun with Prefabs! – A Musing on ECS Prefab Practices

This is some cool but awfully specific artemis-odb stuff, be warned.

It’s possible to simulate prefabs by creating a BaseSystem that deals entirely in creating an Archetype object matching the desired component pattern of your output object. For argument’s sake, let’s say you have a prefab called PlantPrefab. It might consist of position, velocity and render components, so you’d set up your archetype to have all of them. Easy!

Next you’d write a function like so:

Delightful! Now external sources can create your prefab with a bunch of customisable parameters, that directly set data in the instance’s components.

But why would we stop there? >:3

What if we wanted to specify some default values? Or load some values from a string, perhaps?

Suddenly you’d have…

This is starting to become cumbersome, not to mention awfully implementation-heavy for each prefab.

At this point I realised I needed a common way to allow external files to instantiate prefabs with create(String).

Up until this point each prefab had been subclassing BaseSystem, which worked fine for my needs. However, I can improve this with a bit of OOP elegance šŸ™‚

Instead of:Ā BaseSystem -> SomePrefab

I am now using:Ā BaseSystem -> Prefab -> SomePrefab

Prefab does a couple of things. First of all, it simplifies the archetype construction process by asking for a single function to be implemented by children:

This allows me to define a very simple array containing all the components the archetype uses. Since we’re only dealing with prefabs (pre-assembled collections of components), there’s no need to allow the archetype to be constructed by children – every prefab’s archetype will consist of a single add() call to an ArchetypeBuilder object, with a single argument: the array containing all required components.

If we were building archetypes on the fly (for instance, calling ArchetypeBuilder.remove()), it’d be reasonable to hand off this responsibility to children, but it’s simply not necessary here!

Hiding archetype construction and use aside, the Prefab middleclass also helps in requiring each child to implement a create(String) method. This is helpful, as it allows us to know with certainty that every prefab can be instantiated with a String[] set of arguments.

The end result looks something like this:


At the moment I’m going through and ensuring all my existing prefabs comply with their new superclasses… and wow does that sound fascist.

Anyway! It’s lovely and I’m really glad I had the thought to do things this way šŸ˜€


‘ket’ alphabet – An alternative to English!

I was in a lecture yesterday and came up with a neat idea for an alphabet analogous to English. Here’s the sketch I came up with.

ket draft

I realised that if each character used the central “stalk” and featured 1-6 of the other strokes, I’d have enough room for 63 characters! With that in mind I drew up 26 of the full six-stroke symbol, then subtracted lines to form each character.Ā Without further ado, I present “ket“, my first alternate alphabet!


I created the above in Hexels, since I needed a way to maintain the angles of each character and didn’t feel like using a vector program.

Some features of the language:

  • Each character is designed to be quick to draw. At most, a character takes fourĀ strokes: one down the middle and one at each of top, middle and bottom. I’m not sure how this plays out in practice, but I’d love to try it sometime!
  • Vowel characters do not have middle strokes.
  • Characters have a quantity of strokes (1-5) loosely determined by letter frequency in the English alphabet (seeĀ, to make more frequent letters easier to draw!

I’m moderately sure there’s no duplicate characters, but if there are, let me know and I’ll correct it!

I’m not sure if I’ll use it, or what I’ll use it for. It’d be pretty suitable for puzzle or adventure games. Who knows, it may turn up in one of my future games! Keep an eye out šŸ˜‰


Announcing JTask!

Hello again! Today I’m annoucingĀ JTask, a lightweight todo manager written in Java.


It’s a solution to keeping track of the myriad of tasks we inevitably find ourselves burdened with. There are many solutions like it out there (Wunderlist, for instance), though I’ve never quite found one whose features and functionality haveĀ quite met my needs.

So, I decided to make one for myself!

Presently it’s in a functional state – you can make tasks, assign them to categories, hide completed tasks, sort by any of the columns and even filter tasks with the search bar! It also autosaves/loads, so you don’t have to worry šŸ™‚

I’ll make a download page once it’s a little more polished!


Entity – Mechanics Concept

Hello again! Today I’m going to talk a little about my game Entity, and its core gameplay mechanic, theĀ Entity Component System.

Entity Component System (ECS) is actually a programming concept, whereby you avoid a lot of pitfalls of object-oriented by destroying inheritance and instead dealing with components (dumb data bags) attached to entities. Your entities are nothing more than a unique identifier and a collection of components. They can’t do anything by themselves, but instead areĀ acted upon by the systems in your code. Systems will only perform actions on entities if theyĀ match certain component criteria – for instance, a Gravity system may require an entity to possess Velocity and Gravity components before it will do anything to that entity.

This is a fantastic way of programming that I’ve been slowly coming to appreciate, but you may find yourself asking, “what does this have to do with videogames, and in particular, Entity?”

Entity’s main mechanic involves manipulating the ECS through player actions. The main form of this is the player’s ability toĀ toggle components on and off. Here’s what the interface looks like at the moment.


Each of those icons up the top right corresponds to a certain kind of component that the player possesses. Throughout the game, the player will acquire more kinds of components, which will show up here once equipped. Players can toggle components on and off, which willĀ change the way systems process the player entity.

Let’s look at a simple example. Entities require a Collision componentĀ to be able to interact with walls. Toggling your personal Collision component off will allow you to “noclip” through walls.

It’s a pretty simple and intuitive system! I’m going to do some obfuscation so that players can’t immediately break the game (such as the aforementioned noclipping), but I’ll gradually grant them more and more powerful options as the game progresses.

I’ve got a lot planned for this game, so expect a more in-depth look at some of the other components in the future!


New site!

Hi everyone! I’m Archmage, and this is my new site, A Site by Archmage. This is a test post to make sure layouts and things are working.

If you’re new to the site, check out all the games under Byteland. Each one is a part of a major project I’m working on. Check back in the future for more info!