Issue #1: Hatching of a webgame

Intro

Good afternoon, oddly tilted monsters!

The dwarfling archivists suggested me to produce some documents regarding the history and the current developments of Ork Manager, and I’ve finally decided to indulge them.

What is Ork Manager?

In short, Ork Manager is a universe where anthropomorphic monsters brawl following the tactics set by their Master: you.

The amusing setting of this management Game comes from long ago: I was looking for a way to practice game design, and developed this “mini-game”, played by a few dozen users.

This was only an embryonic test of this universe, which I knew had so many possibilities of growing into something bigger. After years spent building up coding experience working for other projects, I finally got the chance to come back to work on my own project… Ork Manager: Coal and Top hats was born.

Devlog structure

On this devlog I’ll mix stories of the past, still very useful to understand some design choices, briefings of the present developments, and glimpses of the future.

Let’s start from the beginning!

Hatching of a webgame

It was 2006, the Internet was a teenager, and some webgames were starting to pop-up.

“What is a webgame?”, asks the young goblin.

It is a videogame built entirely with ordinary "website" technology, behaving like a website with pages, links, buttons, forms, etc.

This is different from traditional/common video games, which follow another approach: they are self-contained entities, with entirely custom interfaces and controls.

Thus, "flash games" couldn't be considered webgames, despite the fact that they were usually played through a browser.

Diving into this new universe, I was intrigued by the first few popular ones; there was a lot of potential for future developments, waiting to be tapped and forged into new amazing worlds!

So, I decided to try to build and improve over what was currently available. Here’s what I came out with.

The obnoxious Night Alarms

The structure of some games required, in order to play optimally, to set up alarms at specific times of the day or night, in order to react to some events.

As this wasn’t terribly convenient, I decided to try and improve that.

Back then I was also playing “long turn Civilization”, which is a FreeCiv server (a Civilization 2 clone) configured so that a single turn lasted about 25h: every user thus had a whole day to connect and commit his turn, and could do that at any time of the day. It still wasn’t optimal, but it was of inspiration.

I structured the Game so that there was a Match every 4 days; every Match required Users to set up their Teams once every 2 days, thus allowing them to connect at any time during that 2-day period.

The paradox of the Noob Protection

Some games allowed full freedom to go anywhere and to attack anyone: this meant that if a veteran player wanted, he could easily raze to the ground a newbie, with no real effort, and no repercussions.

Creating a barrier to entry for new players, this was clearly a problem, so they introduced “noob protection” mechanics, that prevented a new player from being attacked altogether from veterans.

My thought was that freedom is good, symmetry can be good, but this problem was real and needed to be addressed… so I decided to tackle it in a different way.

Teams were assigned a rank at the end of every season, and were subsequently arranged in Divisions based on their rank.

This ensured that Teams of similar strength were evenly matched, and newbies would face other newbies, or the weakest veterans available.

The oddity of the Out-of-game Rules

Due to their popularity, some games code couldn’t keep up with an evolving community, requiring to adapt and fix the rules they considered to be broken… what happened is that some servers set up a few “out-of-game” rules, meaning that the game technically allowed you to do something (like “attacking a specific player three times in a row”), but if you did it, the admins banned you.

I actively participated in my Game, and listened to the Users’ feedback, adjusting the engine accordingly. The rule I imposed myself to follow was “if the game allows you to do something [and it's clearly not a bug :P], then you are allowed to do it”.

The entanglement of the Multiple Servers

The structure of some games was reminiscent of that of board-games: a match starts, it evolves, after a while there’s a winner, and the game ends.

While this may be desirable in some cases, it might sound odd or annoying in others: say that you and a friend of yours want to play together… you’d have to start a game on the same universe, otherwise you won’t be able to interact with each other.

I took care to avoid this, having a single persistent world, organised so that there would never have been an unbeatable “winner”, and that anyone could pop-in at any moment.

This was partly accomplished by having multiple Leagues in every Division, using a custom algorithm called “diamond-shape tournament”, crafted to scale well with any number of Teams.

Design

It wasn’t easy to design all of these improvements, but starting from scratch (as opposed to fixing something that already exists) helped a lot.

I resisted the temptation to jump in and start coding, and wrote everything down before, instead. On paper, for some reason. It was a mess. This was my first attempt at creating a Game, so it took a lot of refinement before I could be satisfied with the result.

But eventually I was.

I created a design, solving all of the points above in a reasonable way, and the Game appeared to be solid.

There still was a lot of work to do… the development commenced!