Interplay‘s Wasteland has been mentioned on this blog before as a reference that I use when considering which game concepts will be brought forward into the large RPG project I am planning to tackle after the Space Mercs roguelike has been completed. This post will be a brief overview of the things that I like about the game and want to bring forward.
The idea of an overland, go-anywhere map seems to have really hit its stride with Wasteland. Like in its spiritual successor, Fallout, the player is not artificially limited to a small section of the country at the beginning of the game. The only thing stopping you from testing the very boundaries of the irradiated, post-WWIII southwest is an infinite army of grump, leather-clad muties.
This sensation of freedom was also present in the Elder Scrolls games, at least until Oblivion was released. With the fourth addition to the series, the developers went a little insane and decided to level the opponents to your character, essentially committing the gravest crime of good, fair game design–you would never meet a challenge too tough, and would never outgrow a challenge, either. A wolf at level one is challenging, but not deadly. That same wolf is just as challenging when you are level 5. It is the most grievous example of DM-ly handholding visible in most modern RPGs, and it will not be repeated in my RPG.
Shopping and NPC interaction in Wasteland is simple and fairly dense. It is difficult to figure out how to speak with an NPC, how to trade items between your party members, and how to manipulate your own equipment. The game features an admirable level of depth and sophistication, but it is hidden behind an overly complicated control scheme and a lack of clearly laid out buttons.
Simplicity of input aids depth of interaction, which is a concept that I am already exploring in the inventory and tactical combative aspects of Space Mercs.
Finally, combat. Wasteland featured a text- and menu-driven combat scheme that evokes other games from the developer, such as Bard’s Tale. When looking at it from a game designer’s perspective, it is excellent–it features distance, multiple enemies, and dangerous combat that makes a player really consider his next move, lest he die. I want to bring all of these things into both Space Mercs and my RPG project. I will, however, be doing so in a manner more fitting with modern, spatial conceptions of gaming.
I would love to make a really classic-style RPG one day, but I think that my time right now is better spent learning from the ideas of games like Wasteland and then figuring out what made those games great, so I can bring them into the modern era.
Games like these were made by teams of 2 or 3 men (sometimes more, but nothing like the scores-strong development teams of today). That they could do so with nothing more than the primitive programming languages of the past and veritable oodles of chutzpah gives me hope that my own projects will stand a chance, if I am willing to put in the blood, sweat, and tears that a project like one of these would require.
Keep checking back!
I have had a working ranged combat system for a little while now, but no effective means of showing the player which enemy unit they are targeting. Now, the targeted enemy will switch to the player’s color while it is in the player’s sights. It is simple, immediately visible, and quite effective. Here is a picture of it in action. I realize that it shows an adjacent enemy. The targeting will only be used for ranged combat; melee combat will still be run using the traditional step-and-bash method.
I have finally resolved the inventory stutter Space Mercs suffered from! As you can see in the below picture, the game recognizes the use of an item (such as a potion) and prevents itself from repeating the message a thousand times–success! What happened was that I had failed to correctly do a check for current key while ensuring that the key had previously NOT been held down.
I was under the impression that my code had corrected for this possibility without the need to actually check each keystroke against the previous stroke, but I guess that I had missed something somewhere. Adding in an explicit check like this takes almost no time or effort, however, and it works well enough that I don’t regret adding it in.
I have been playing the classic CRPG Wasteland recently, and it has been a great inspiration for me when it comes to game development. The game is ~23 years old (and developed by the minds behind the pen and paper RPG Tunnels and Trolls) and yet still contains a lot of great ideas.
The game engine I am developing for Space Mercs is serving double purpose for the roguelike and as practice/thesis for a full-blown RPG engine to be used sometime over summer or later this year. I am studying the things that Wasteland does right–and the things it does wrong–with a critical eye.
I just won my first Hardcore game in Blendo Games’s Atom Zombie Smasher! The final score can be seen below.
- Fully Loaded
- Party Wagon
- Buy Llama Bombs
- 20,000 points
Admittedly, it was made easier by a lot of the settings, but it was hard enough at the beginning! I was winning from about the 7,000 point and onward.
I have added primitive item functionality to the game using a technique derived from the same system of plug-in code as the entity AI. Potions (the only item implemented so far) can be picked up, occupy an item slot, and can be used to restore health up to a variable maximum. Using them removes them from your inventory.
I have also begun sketching rough versions of the UI I want for the game, which will feature an ASCII map as roguelike tradition dictates, but will also feature a graphical menu and character screen. I hope to be able to commission an artist to make it relatively cheaply, since I’m broke and this is a fan project. I think it will add considerably to the look of the game, however.
Today’s work has left me with a working inventory system! Space Mercs is going to have an–as far as I can tell–entirely unique system of inventory management that will be integrated with the strategic nature of the game’s real-time combat. None of that is in yet. What we do have, however, is limited inventory slots, a system that checks to see whether the character has room to pick up an item before doing so, and one that rejects the Get behavior if the character is overburdened.
Things are coming along! I want to add item functionality tomorrow (although I have already started to integrate it into the Item class by linking it with a separate class called GameEffects that will manage healing, monster attacks, etc.
Here’s a pic of the @ picking up a key. There is one little bug where picking up an item works correctly, only updating the first status line. When you fail to pick up an item, however, it turns EVERY status line into a “You don’t have room for this” message. If anyone could give me some tips about how or why this is going on, I’d appreciate it.
If anyone knows C# and is willing to help out, here’s the code. The UpdateStatus(string) method turns the first status line into the referred string, then bumps each remaining string down one (if you’re curious and think it would help). Click to embiggen.