This little guy is called Wizkill. It’s a roguelike, which means it’s nothing but ASCII graphics, letter-shaped monsters, gold and dungeons. Roguelikes are traditionally quite hard and have a steep learning curve. I’ve tried to minimise the latter by limiting the number of keys, removing classes and providing a single goal (killing monsters), but who knows, it might still take a while to come to grips with.

There’s a score component, calculated when you die or hit level 25. Feel free to post your highest score in the comments for this post. Oh, and if you notice any bugs or want to suggest some changes, add them here as well. If there are enough, I’ll make the appropriate tweaks and release a “final” version on Monday.

If you’d like to start playing, you can download the game after the jump. I’ve also included a write-up on the design and development process, and what I’ll be taking across to my next Game A Week project.Click here to download Wizkill. If you’re running Windows Vista, you ready to go. If you’re running Windows XP, or get the error “App failed to initialize properly (0xc0000135)”, you will need to download the .NET Framework 2.0.

Update: Uploaded a new version to fix a small bug in the dungeon generation code and to make sure the player isn’t surrounded when they enter a new level.

This is the Visual Studio 2005 Integrated Development Environment. Wizkill was written entirely using this IDE, and I plan on writing all subsequent Game A Week projects in Visual Basic .NET. Make fun of it if you will, but it’s the language I’m most comfortable with and, as you can see, quite capable of producing simple games.

I’ve always loved roguelikes. I started writing my first one in QBASIC back in high school. Unfortunately my abilities were limited back then and I could never code anything I was totally happy with. These days, my programming “habits” are much improved, as are the IDEs.

My familiarity with roguelikes is why I chose to make one for the first Game A Week. I had a good idea of all the basic elements a roguelike needs:

- ASCII graphics
- Monsters to kill
- Random dungeons
- Mystery
- Character advancement

Originally, Wizkill was going to be about ascending a tower to kill a wizard, hence the name. There would be only a few levels, but players would have a large number of customisation choices in the form of character generation, items and abilities. After a few hours of coding, I realised such a game would be difficult to balance and playtest in seven days, let alone the implementation of the meat and bones.

It would also be hard to play out a titanic end battle between the player and wizard, seeing as you’d just stand next to him hitting the appropriate direction button to attack. I think it would have been discouraging for the player to spend all this time getting to the wizard, only to die, and would negatively impact the desire to replay.

So I ended up with the current design – 25 levels of random dungeons filled with monsters, and a score component to rate your progress. This way, even if you die, you still have something to show for it. I had thought 50 levels would be a good number, but after playtesting, I found it hard just to get to level 10!

I finished what I like to call “version 1″ after two or so days. It included monsters, weapons, armour, healing rations and a store where you could spend gold to upgrade yourself. It was fun, but I felt there wasn’t enough mystery. Sure, finding new monsters could be surprising, but there was no “gambling” mechanic that makes games such as MMOs so addictive.

That’s when I decided to stick in amulets, prayers and perks, and “version 2″ was born. Amulets have a small chance of dropping from any monster in the game, and each one has a powerful effect that can be used once per level. Prayers are available to the player starting from level 1, and grant a random bonus every time they’re used. Like amulets, you’re limited to one per level, unless you take the “One man, many gods” perk.

And that leads us to perks. Character development is a key draw card for any RPG, as it allows us to watch our avatar become stronger and overcome obstacles that were once daunting. I had the upgrade store implemented, but it wasn’t enough. So, every five levels the player can select a perk. There are six available, and if you manage to make it to the end of the game, you should have four of these. Perks were hard to design, as they had to provide a benefit no matter what stage of the game the player is at. For the most part, this is accomplished, but there are definitely some perks that are better for late game than others. A novice player, for instance, might take the perks related to scrolls of fortitude early on, especially if they’re struggling to stay alive. However, gold is the key to character enchancement, so an experienced player would see the benefit of taking the gold-boosting perks earlier to reap the maximum amount of gold.

The “sell your stories” feature came out of a loot-selling thing I’d stuck in but wasn’t happy with. I liked the idea of the player benefitting by holding out somehow, and stories seemed thematically correct. Careful story selling is integral to winning the game, and savvy players will quickly realise maximising the gains from this feature is very important.

Developing the game was the easy part, believe it or not. About 1/2 of the development time was spent playtesting and balancing. Monster strength and the rate at which the player acquires gold proved the major influences on difficulty, and I spent hours tweaking values, sometimes by a single digit, to see their effects. After a while, you come up with “rules” in your head. Instead of thinking “this monster should have this much attack power” it’s “monsters should take, on average, two hits to kill at this level”. Once you have some design rules, balancing is easier… but not easy. My biggest regret is hand-making most of the game’s monsters. There are three varieties per level, making for 60 or so templates. The better way would have been to make “profiles” for hard, medium and easy monsters, and balancing them using a formula derivied from the depth. It removes some “personality” from the game, but from a data perspective, it’s one less can of worms.

Overall, I’ve tuned the game to be harder, rather than easier, and I’m not sure if it was the best choice. But we’ll see how we go.

The random dungeon generator was a “last-minute” addition (I put it in about two days ago). Before that, I’d hand made maps, but I wasn’t happy with the result. I thought a random generator would be a headache to debug, but I programmed defensively, and that helped a great deal.

If you’d like a copy of the source code, email loganATkotakuDOTcomDOTau and I’ll send it to you. If I get enough requests, I’ll upload it to Kotaku AU.

Now go play the game!

Above is a screenshot of Wizkill, a roguelike I started writing in the early hours of Monday morning. I often get distracted writing small games like this, with the sad part being that I either never finish them, or they sit unplayed by anyone but me, rotting in cyber oblivion.

No longer! At least for the next few weeks. Starting from this Friday (when I’ll upload Wizkill), I’m going to try and code a new game every week. Depending on how popular this feature turns out to be, I’ll keep going until I run out of ideas, or it breaks me.

If you’d like to hear more, or feel you can contribute, hit the jump!For our purposes, the “week” will be Monday to Sunday (so I can post the results on a weekday). So I’ll upload Wizkill on Friday, and hope to heck I’ve ironed out most of the bugs. You guys can give it a good play-through over the weekend, and shoot some feedback on Monday. I plan to have each game include a score component, so people can post their final scores in the upload posts.

If you’d like to help, start posting ideas for games you think could be coded in a week. As a rough guide, I spent about two days coding Wizkill, and yesterday play testing, debugging and balancing – something I plan on doing until the end of the week. So the idea can’t take more than two and half days to implement, tops.

I’ve set myself the following guidelines:

1) No amazing graphics, they take too much time and I’m really arse at art.
2) Must have a score component, so you guys can show off your gaming mettle.
3) Must be complete and reasonably bug free.
4) Game must have an ending.
5) All games will be coded in Visual Basic .NET 2005. Probably the worst language to code a game in, but you’d be surprised at what you can do.
6) Game must be playable on most machines, so no 3D API use. Plus, I don’t know the first thing about Direct3D or OpenGL.
7) Each game must be coded within the seven days between releases.
8) All code must be original.

That’s all I have, but I may add to it as we go. Now, let me know what you think!