Everyone remembers Zafehouse, don’t they? The free zombie survival horror simulator I coded in seven days? Well, turns out it was by far the most popular of the three titles that came out of the Game A Week feature, and there were plenty of people who submitted fixes and tweaks. I found myself with some spare time on the weekend, and decided to put together a version 1.5, incorporating the feedback I’d had on the game.

Originally, I just wanted to streamline encounters by removing the “next round” button and having things tick over automatically. But then I got another idea, and then another, and soon I found myself with a big list of changes, improvements and bug fixes.

I’ve included a complete rundown after the jump, but here’s a summary if you can’t wait:

* Buildings produce more resources, while raiding brings in less.
* Encounters streamlined, instant resolution button
* Zombie numbers increased.
* More shortcut keys.
* New scoring formula.
* New perk, and original perks improved.
* New building, the Church, which produces survivors.
* GUI improvements
* Numerous bug fixes (no more whipping from inside buildings)

Download and enjoy!

Download Zafehouse v1.5 binaries.
Download Zafehouse v1.5 VB .NET source code.

Zafehouse V1.5

-Major patch: Game more difficult, buildings are a lot more important, raiding made more reliable, encounters are faster, game is shorter, mass attack added to end-game, more shortcuts, score more consistent, House is now Church and produces survivors, new perk “Home advantage”.

-Encounters now tick their events automatically. Next round button changed to instant resolution button

-Fortification levels of buildings shown with #s on the building GUI

-Pressing “0″ unloads ammo from weapon of selected survivor

-Pressing “Shift” quick equips – selects best weapon and gives it to selected survivor

-Pressing “Ctrl” quick removes weapon from selected survivor

-Changed raid chances (1-70, 71-90, 91-100) (70%, 20%, 10%). This should result in raiders getting what they want a lot more often

-Changed raid priorities (ammo & supplies, water & medicine) to provide better synergy

-Increased the amount of zombies encountered outside during the night by 50-100%

-Increased the amount of zombies encountered during a raid by 33%

-Chance to be attacked outside during the night changed from ZMI to fixed 45% chance

-ZombieMassMinimum variable added, increased minimum ZombieMass from 12 to 16

-Reduced number of hours from 72 to 60.

-New scoring formula:
50 per survivor, 100 per building, 2 per survivor hour, 1 per zombie killed
-25 per survivor killed, -35 per survivor turned, -5 per alive survivor infected
If a survivor is turned, they are removed from the survivor killed count
If the game is lost, all survivors still alive are added to survivors lost instead

-Added zombie mass attack during final hour. ZombieParty for outside attack determined by the number of buildings held. More buildings equals less zombies.

-Edited some descriptive text for Attacked_Outside and fixed a typo with the Attacked_Outside resolution text

-Most building resource counts have been increased, and in most cases doubled: Factory from 3 to 5 ammo, warehouse from 3 to 5 supplies and store from 2 to 4 water. Hospital remains at 2 med kits. This should make them more attractive to hold. Subsequently, resources from raiding have been reduced: Supplies from 12 to 8, ammo from 12 to 4, water from 10 to 4 and meds from 3 to 1.

-Added RaidBonus_x and BuildingBonus_x variables. All resource bonuses are controlled from Game.vb

-Raid weights changed: weapons > people, ammo = supplies, water > meds

-Starting resources reduced: Water from 22 to 16, supplies from 10 to 5

-Bite chance increased from 50 to 60 percent

-Grizzled perk bite chance reduction increased from 5 to 10%, Sharp Eye percent bonus increased from 1 to 2%

-Fixed a bug that would report infected survivors incorrectly during Win/Lose screen

-Survivors wielding weapons with no ammo now have the same chance to be bitten as a survivor with a melee weapon (50%)

-Added Special bonuses (disabled for now):
Secure all buildings – gain +1 production to water, ammo, supplies or meds at random

-Survivors gain perks at levels 8, 16 and 24, down from 9, 18 and 27.

-Player starts with one additional survivor, armed with a bat

-House renamed Church, attracts one survivor every other turn

-Help/main menu screen resized

-Added new level 3 perk: “Home advantage”. Reduces the number of zombies during a building attack by 1, stacks

-Added more descriptive barricade info during combat

Blockshooter is a combination of Breakout and Space Invaders. It’s your job to pilot a little ship, shooting at coloured blocks that come your way. Shooting multiple blocks of the same colour will award you a point multiplier. Destroying entire segments will drop a “piece”, which can be collected and added to your ship. You lose points by getting hit or allowing blocks to slip past you.

That’s the nuts and bolts of it. If you’d like to give it a go, hit the jump for a download link and developer’s diary.

PS. Yes, this has come out on Monday instead of Friday. I’ve decided to shift the Game A Week schedule by two days, so I can have the weekend to playtest and debug. Don’t worry, I’m sticking with the whole “seven days to code” requirement.Download Blockshooter V1.0.

If you’re running Vista, you’re 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.

Blockshooter was by far the most painful game to develop. Not only did I have gameplay issues, but technical ones as well.

In the perfect world of game design, one should be able to come up with a concept and be able to implement it without having to worry if it can actually be programmed. Case in point: I wanted to code a shoot em’ up that combined Breakout with Space Invaders, but at the same time, not use graphics.

Impossible, right?

Fortunately, I had a solution – I would use controls in place of sprites. If you’re not familiar with the term “control”, it simply refers to any element of a Windows “form”. This can be a button, picture box, text box, label, etc. All you have to do is set a background colour, manipulate the control’s position during runtime and bang – you have graphics… of a kind.

The trouble is, controls aren’t really supposed to move during runtime, so I had significant performance issues. Even on a dual-core 1.8GHz PC with 2GB of RAM, early prototypes would slow to a crawl if more than 16 blocks were moving on screen. I had to find a way to either a) optimise the movement of blocks or b) reduce the amount of blocks. In the end, I placed blocks inside group panels, and just moved the panels instead of individual blocks. Of course, this broke the collision detection code, and I had to make a custom control to fix it.

Sadly, Blockshooter became a collection of these “hacks” to make the Windows GDI a gaming platform. As you can see by playing, it all works, but I get a little sick in my stomach when I look at the code.

I’m also not happy with the shipbuilding interface. It could be a lot more user friendly. I’m hoping everyone gets the hang of it, but I’m not expecting them to. I had to rush it, thanks to the technical issues I had with the GDI. I might do a revamp in the next few days, but I’m really keen on my next game, which I’ll tell you about soon.

Long story short – don’t use controls as sprites. It’s messy.

If you’d like the source, just hit me with an email.

Download Blockshooter V1.0.

Departing from the simulation and turn-based genres I’ve explored in the last two weeks, I’ve decided to code a shoot em’ up. It’s pretty conceptual at the moment, but the basic idea is that you fire lasers at blocks and collect the goodies from inside. You can then “build” those goodies onto your ship to make it better. It’s like a combination of Breakout, Space Invaders and MacGyver. Or Spore.

You’ll be free to create ugly ships that have ten super guns, or sleek, sexy creations with less firepower but more grace.

Friday again is my deadline. Wish me luck!

If you missed the previous Game A Week releases, Zafehouse and Wizkill, be sure to give them a play!

Game A Week 2 is done. Done I say! Zafehouse is ready to be played by all.

As I said earlier in the week, this thing almost killed me. I had an idea that just exploded. I think the end result is quite awesome. Zafehouse has strategy, survival horror and, best of all, zombies. I love shufflers, I just love them to death, and I’m glad I got to put them into a completed game.

I have yet more plans for a version 2, which I’ll release when it’s done. For now, I have to get started on Game A Week 3. If you’d like to check out Game A Week 1, Wizkill, hit up this post.

Hit the jump for a development breakdown, hints and tips and unimplemented features, or download the game and give it a spin.Update: If you’re running Vista, you’re 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 2: Small bug with the raiding code’s been fixed. Please download the game again to get the updated executable!

Update 3: New version, v1.2. Here’s the info:

-Clarified help rules on buildings and resources
-Reduced the amount of meds found in a raid from 4 to 3
-Fixed the “Hours since.”.. label on the GUI so its value is never hidden
-Pressing “~” while a person is selected will heal them

Zafehouse began as a random name generator. I wanted to make something different to Wizkill, which involved one character (you), into a strategy game that had many. They needed a little personality, so I started by entering about 100 first names and 50 last names into two arrays.

Zombies had to be in there as well. I’m a fan of games that demand you manage tight resources and make important decisions on a minute-by-minute basis, and these concepts turned into the idea of holding off a bunch of zombies for days on end until help arrives.

Coding began mostly with the interface. A good UI was very important. Players would need to be able to assess resources at a glance, assign weapons and ammunition easily, and move survivors around quickly. I tinkered with about ten different designs, until I came up with the one in the picture above. The graphical resource counters were added last night.

About a day into the proceedings, I realised 120 days was too much. I reduced it to 72, which gives a good balance of longevity, and allows the gamplay to “develop”. Shortly after this change was made, I found I didn’t like the idea of days, as the intensity wasn’t there. So I changed it to hours.

The game is turn-based, with the actions of each hour affecting the encounters you have. I made a risky moving forcing the player to watch the results of their planning rather than being able to directly affect combat and raiding. It puts more weight on making good decisions beforehand, and makes your mouse hover over the “Advance one hour” button in tense contemplation.

Gameplay involves raiding for supplies, securing buildings for cover and resource bonuses and allocating weapons, barricades and ammo in an intelligent fashion. It seems basic at face value, but as the game progresses you’ll find yourself keeping careful check of who has your only shotgun, or if David has enough ammo to last the hour.

The amount of zombies you encounter and the chances of encountering them is determined by something I like to call the “Zombie Mass Index”. The ZMI is increased by two every hour, and reduced by one every time you win a fight. This way it regulates itself, and puts pressure on the player to be offensive. Sure, you can hold up in the House with two guys, but eventually you’ll have 50 zombies banging at your door.

A late addition was the “promotion” system. I wanted to give the player more control, and make them assign importance to some survivors over others. So, for every 9, 18 and 27 hours a survivor lives, they can take a bonus, such as more damage or lower ammo usage.

I almost put in a “goal” system, but the promotion system overtook it. Essentially it would let you trade resources for permanent bonuses, such as a few hours off your rescue time and higher resource generation from certain buildings.

Some other features that didn’t go in due to time were grenades, reclaiming weapons, a morale mechanic and zombie culling as a raid priority. While these would enhance the game, it’s very fun and playable without them. If I could implement one right now into the version here, it’d be zombie culling, as it gives you more control over events in the planning stage.

If you’re having trouble surviving, try only to hold onto one or two buildings during the day, focusing on those that give you resources you’re in need of. At night, don’t spread yourself out if you don’t have to. I’ve found the Mansion and the Warehouse are a good choice, as the former can hold six people (more guns means more downed zombies) and the Warehouse (a constant stream of supplies during the night means you can reinforce your buildings).

Again, if you want the source, drop me an email. Otherwise, give it a go and post your scores!

Don’t forget to check out Wizkill, the game from week 1, and make suggestions for other games I can make.

I’d say I’m about 15% done at this point, so a lot of work to do before Friday.

Start thinking of game ideas guys! I still have a few ones I’d like to try, but I’m keen to see what you can come up with. Remember – seven days of development time only!

Update: I didn’t even notice the game’s random name generator had spat out “John Romero” for this particular run-through. To put this in perspective, there’s a 1 in 4418 chance of this happening.

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!