I am as partial to graphics in my video games as the next guy, although the ability to draw escapes me. I have mentioned before that I was considering (still am) commissioning some good, high-quality art for the UI, menus, etc. for Space Mercs. Earlier, I was planning on using ASCII art (as seen in previous screens) as the main means of displaying the game, however.
After spending today goofing around in GIMP, I have started serious thinking about drawing some very retro art, instead. I don’t have the skills to produce really high-quality stuff, but what do you think about this? It might be a little bit more fun, right?
Space Mercs now has more complex, DnD-like melee combat. The prototype game has been featuring a simple, no-hit roll melee system that simply did damage between 1 and whatever your character’s strength happened to be. Now, characters make a d20 roll whenever a character attempts to melee attack. The d20 roll is modified by your character’s BattleLevel, which is a facet of the game’s unique character-level system.
Here is the code for melee:
An entity calls this method whenever it tries to move into a square occupied by an entity of another team (the teams are currently only Players and Mobs). Initially I was going to have multiple enemy factions that would battle with each other, but I found that monsters would end up killing each other if the PCs waited long enough. Believable, but not fun. Unless I can figure out a way around that, it’s out for now.
Because of the real-time nature of combat in Space Mercs, I had to make sure that missing in melee is implemented in the game, although I was originally planning on having no-miss combat. Without it, the game runs simply too dangerously.
The thing that I am most proud of when it comes to the map maker that I have developed for Space Mercs is the way that the computer is able to create and adapt the tiles that are made in a way that makes them connect in new and exciting ways each time. Unlike in a game like Carcassonne, the “tiles” that the computer uses are flexible. What is an out-of-the-way cupboard in one map might be the crossroads that connects a series of dungeon branches in another.
Here is an example of what I mean. This map tile is really just a few rooms and a connecting (albeit not perfectly straight) corridor that lies between them. When taken into consideration with the rest of the map, however, we can see how the room in the lower left, which might otherwise be taken as an out-of-the-way corner of the map, becomes a dangerous thoroughfare with a doorless hole in its south side, allowing enemies passing by to see into your hiding place. The north-western room, however, was generated with a door in its west wall, providing blocking cover and making the room much safer.
By combining even a relatively small tile set, the way my generator creates connections means that no two maps will ever be the same. Even the strategic and tactical significance of a particular tile can change depending on how and where it is connected to the rest of the map!
(Note: the beacon is the silver-grey ‘:’ two squares north of the player’s ‘@’.)
The thumper beacon is now working in Space Mercs. Success at Mercs is heavily dependent upon tactical, cautious play, and players will find that use of strategic tools such as the beacon will be essential to success. In the picture above, you can see how the thumper draws wandering monsters toward its location, allowing you to plan ambushes or buy time for a strategic “advance to the rear” (retreat).
What was difficult was finding the balance of how strongly beacons like the thumper and several others would influence unit AI. I think that the effect is currently well-balanced, but it will take a bit more work before I can say that conclusively.
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 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.