battleMETAL - Why Quake / Darkplaces - Part 1 - The Devil you thought you knew well enough

The Devil you thought you knew well enough

Now we begin to get a bit more technical about why picking Darkplaces was a good idea. First let us begin with the software concept called a source port. This example, Darkplaces is a source port of Quake 1. Source ports allow software to be run on systems that are different than the original specs. In video games, most source ports merely allow the specific game to played on a newer system - like Quake 1 (circa 1996) to be played natively on Windows 10. However, Darkplaces is also a library of modifications to the Quake 1 software that expands functionality.

Darkplaces was developed by a user by the handle LordHavoc and you can find more about that over here. The biggest things that Darkplaces accomplished was a modernization of sorts for the Quake engine. Updates to the rendering software allows Darkplaces to draw higher resolution textures, real time lighting, higer polygon-count models, smoother animations. Not just rendering, Darkplaces also allows for higher quality sound effects and music. Finally, a big update was raising the memory capacity of the engine to handle large quantities of monsters, bullets, players, and other game objects in a level and even increasing the size of potential levels. In essence, the Quake 1 engine is a Virtual Machine geared towards running Quake, so upping memory capacity is a huge plus if one is looking to expand the Quake engine to be more than running Quake.

All of these features fit well enough into my understanding of modding Quake 1 and Quake 2 engines. The requirements of the engine, relative to more modern engines, is incredibly modest, and the engine runs well on almost anything. Actually modifying the engine is generally accomplished by changing the game code. Game code is in a ‘bastardized’ version of the C coding language. A lot of functionality has been stripped out or pared back to concerns only of the game engine. Plenty of tutorials and tutorial sites are at one’s fingertips as well, making question-answering fairly quick and easy. This is a benefit to an older game engine, a lot of the most basic questions have been answered somewhere and a lot of other people have tried something similar to what you are trying to do.

By choosing a Quake derivative like Darkplaces , I was also subscribing to Quake’s template of game creation. Most game engines define how to add levels, link levels together, manage player inventory, etc. Even if a game allows a ton of modding, it doesn’t make a whole lot of sense to rip out a game’s functionality completely and try to bash in something that doesn’t conceptually jive with the game. I knew battleMETAL would be an FPS, a mech FPS, but it still was an FPS, thus Quake aligned conceptually with that goal. I also knew that battleMETAL levels don’t need to be super complex or scripted, and again Quake aligns with this concept. So, I talked myself into downloading Darkplaces and took a look under the hood.

battleMETAL - The Dare - Part 2

(this one is a bit lengthy, some paragraphs are skippable :P)
How it all started
I had been doing the exercise of designing games since 2008, but those early efforts were plagued with poor planning and lack of knowledge. I give 2012 as a starting point because that was the year I sat down and said “I am going to make a video game.” No, this game wasn’t battleMETAL. This was Project Redshift, what became known as the game Zond. Zond is a top-down, Asteroids-like game built in Java. The player commanded any one of the classic Space Race era spacecraft in combat missions. I never really finished the game and you can learn more about it by going here.

Zond fizzled out for various reasons, both technical and non-technical, however I learned a lot about the process of game making. The project wasn’t large enough to bury a one-man team, but its features challenged me as a programmer. It also gave me a crash course into core game code design and some of the paradigms used commonly in game coding. After Zond, I cast about for a few years making other attempts at video games, most work was exploratory and mired in technical debt. It wasn’t until 2016 that I thought about making another ‘serious’ go of ‘it’.

When you are the Devil’s Advocate in a case against yourself

So here comes 2016, and I’ve been wondering what game to make. A long time ago I remember reading a quote that has stuck with me - “Make the games you want to play.” I can’t remember who said it, but it has become a mantra that I believe in. Make the games, you want to play, ignore the gaming zeitgeist and make what you want. What games do I like to play? Simulators….but not just any….mech simulators. Ever since I fired up Mechwarrior 2 back in the ancient past of 1996, Mech Games have been one of my all time favorite genres of game. There’s nothing cooler than stomping forward, deflecting a hail storm of cannon fire, in your armored leviathan. An avatar of war, a walking tank. To fight another mech is to engage in a knightly duel of old, or like two Aces in WW1 biplanes, or two prize fighters in boxing. I love the motifs of mech games, the themes, the spectacle. Sadly by 2016 the gaming zeitgeist had declared mech games to be very dead.

See, by 2016, Simulators are a kinda dead genre. No large company is really making them, for whatever reasons (I could get into that but its heavily opinionated salt). My only options as a gamer to get some mech action in the style of Mechwarrior was really only Mechwarrior: Online and that in my opinion is super depressing. Mechwarrior: Online is a pale shadow of what mech games can be and what Mechwarrior games used to be. That previous sentence was opinion, if you weren’t sure, but it's important to know that because that leads into the impetus for making battleMETAL. So I ask myself - what is stopping me from finally making a mech game? I’ve been kicking around ideas for a few years, along with talks with close friends about concepts and design for mech games.

The initial stopping point was technology. I tried working with Unreal 4 but at the time in 2015, I found the UI overwhelming for a single developer to really get traction. I thought about Unity but it looked like I’d face the same uphill challenges as Unreal, at the time, remember - hindsight is everything. Thinking about my options, I dredged up an idea from the past - what about Quake? To make a side story short, I was familiar with making Quake II maps back in 2002 / 2003 or so, and had read about a few source ports of the Quake 1 engine, namely Darkplaces. Quake 1 also had its own specific C-style language that was purpose built for modding Quake.

It sounded like Darkplaces was a good ‘my first 3d engine’ to really dive into, it felt approachable. Functionality was literal, not hidden behind splashy UI. Here’s an example: to get texture effects like light-reflection and bump mapping? Simply add 2 files - <your texture>_bump.tga, <your texture>_gloss.tga. Darkplaces had a built-in file system for loading and caching game files. Rendering was secondary, I’m not a graphical artist by trade so I was prepared to make a game that looked ‘ok’. Another plus for Darkplaces was that it had a network-layer built into the game as well as entity management. There’s a power to game engines where you can just start coding the fun stuff...and a danger.

Then came July 4th, 2016. Having just finished a barbecue with friends at our apartment, I sat down to do some really dumb tests with Darkplaces. In one evening, I replaced the Player model with an old mech model I had made in 2015, and I changed the weapon model to a cockpit mesh I made sometime in 2013 / 2014. Here were the results:

 These screen shots are Quake but I replaced the Player model with my own mech model and replaced the First-Person gun model with a cockpit.

And that was one evening! My head exploded with ideas, drawn in with a “well this doesn’t look so hard” mentality. As we’ll see over the next 1.5 years, that was the definition of short-term success hiding long-term pain. Eventually I fought through the ‘necro-tech’, realizing just how obsolete a game engine Darkplaces really is. Through it all, it still is one hell of an adventure into game design. battleMETAL is a case where I played Devil’s Advocate for myself, why not a mech game right now? Why not just ‘get it done? The mantra I’d end up using throughout the entire project as the months wore on became:


Perfect, is the enemy of good.

battleMETAL - The Dare - Part 1

Who am I
To be super brief - just some 30-something guy from New England, in the United States.

To be a bit more specific? Programmer, artist, historian, painter of miniatures, and game designer. I’m not going to try and recount my life story here but merely try and give some context to the person behind this entire project.

The threads winding their way through my life to get to this point would be longer than socially bearable to recount. Two events in my childhood, looking back now, I think, are what would end up altering my career path. These are more clear in hindsight, about 20 years later, but at the time and even into college I didn’t really think about it.

The first event was joining the ‘Computer Club’ in 5th grade. Now to be clear, this was a normal public school, in 1997, in more-rural-esque Connecticut. So, if you expected a guided experience with some old sweat coder….you are quite wrong. It was run by a well-meaning if a bit misguided teacher who wasn’t so great with computers. The club was mostly about using macs and the program called Hyperstudio to create super simple ‘programs.’ hilarious outdated link. Most of the things we made in that club could be charitably called ‘interactive Power Point presentations.’

The roots of the idea was there, though. The program showed how to create menus, do limited animation and sound. It was a ‘first’ step towards coding and computer game design for me if there ever was one. Up until this point I thought I wanted to go into Marine Biology.

I’ve wanted to be a game designer / maker since 8th grade. The reason I can remember it so clearly is because of the TI-86 graphing calculator ( https://en.wikipedia.org/wiki/TI-86 ). Every student at the time was required to get one in my school as we entered 8th grade in 2000. One of the discoveries we, students, made was that not only was the TI-86 super handy actual math...but it could also run games. In 2000, seven years before iPhones and ubiquitous mobile devices, being able to play games anywhere was still a bit of a luxury. Sure the GameBoy was around but you couldn’t exactly play that in class without getting it taken away at some point. The TI-86? Perfect camouflage.

By 9th grade, the start of high school, I had found you could indeed code your own games onto the calculator...and into the internet of the early 2000’s I went. I scrounged around for tutorials, how-to’s, anything I could get my hands on. I read up on printing characters to the screen using an X/Y coordinate system. I learned about interpreting user input, and the keycode number for every key on the calculator. I played around with writing simple little menus for my games.

 Early attempts were clones of projects I found online, printing out reams of code on paper for later reference. Although many of these projects existed on my family computer (I did buy the pc / calculator cable so that I could code on the pc), sadly all were lost in the subsequent years of hard drive failures. After this point, things were reliably on track for me through high school and into college.

Those early habits of scouring any and all knowledge for help in my own efforts has stayed with me. In a quirky twist, these skills also ignited a love of History that still burns today. As to how this relates to battleMETAL? In the coming posts you will see how the self-confidence of that young programmer would be challenged and reforged. How learning to sift through and collate disparate fonts of information would help in completing a (so-far) arduous task.

The cold rise from sleep...

5 years and a what feels like a life time...

I'm going to attempt to start this blog up again mostly to document the video game battleMETAL that I have been working since mid-2016. I had planned on doing a retrospective when the game was finished but decided a weekly or bi-weekly blog would make the task less daunting. 

Posts are going to range from general discussion of the development of battleMETAL to focusing on specific challenges or features of the project. 

<fumbles in pocket, pulling out wrinkled napkin>
 
I do have a rough outline for this series of posts, and I'll try to stay on-script as best I can. I will also try to make sure the posts happen in a regular fashion, as blog posting is not a habit of mine and for the longest time I personally felt it took time away from working on the actual project.

Some of these posts will also get a bit technical when discussing in-depth topics, if you find yourself struggling - feel free to skip that post, but I do encourage trying to muddle through.

The Dare 

•     Who am I
•     How it all started - when you are the Devil’s Advocate in a case against yourself

Why Quake / Darkplaces

•      Reasons for
•      The Devil you thought you knew well enough
•      File management
•      File type loading
•      3d renderer
•      Game loop
•      Networking layer
•      Menu layer
•      Input layer

Why that was a bad idea, a terrible idea

•      Everything discovered
•      Map pipeline
•      Model issues
•      AI
•      Collison system
•      Game Logic

And Yet, somehow, it works

•      Sanity is preserved in the console logging functions
•      Eventual map pipeline
•      Game Data systems
•      Flexible, but built in systems
•      Mech model implementation
•      AI implementation 1
•      AI implementation 2
•      The Mech Hud
•      Hud Impl 1
•    Sorta generic, entity based
•      Hud Impl 2
•     Generics, generics, generics
•      The CSQC Menu System
•      Overall design
•      Briefing menu
•      Text wrap
•      Mech hangar / arming
•      Deployment menu
•      The Menu.dat
•      Entities, callbacks, swtich cases, textfields, dragon drops
•      File Loading and folder layout
•      Animatic System

Aha! I actually found time to make another blog post…being on vacation with the family in Cape Cod. Since the last time I posted, I’ve had the privilege to play some new board games which are always a fun time. As of now, I want to do reviews for Zpocalypse, HeroClix, and Dungeon Command. I recognize that HeroClix is a Rules Engine that has various incarnations. I will review HeroClix based on the way I currently am using the system, which is with the Pacific Rim line (Giant robots and Godzilla monsters). If I go in order of acquisition for the list of games, Zpocalypse would be first.

Zpocalypse

Zpocalypse is produced by the game company Greenbrier Games.

http://www.greenbriergames.com/gbg/

 It was a kickstarter project that was quite a success. The kickstarter concluded before I became aware of it and therefore I was unable to contribute anything. I was however exposed to Zpocalypse all the way back in April of 2012 at the Pax East convention. I was perusing the board gaming section of the convention with some friends when the game’s booth caught our eye. We played a demo of the game….and then stuck around to play another round…and another. Flash forward to now, and I’ve had the opportunity to play the game at a few other conventions and finally purchased a copy of my own 2 months ago.

                               

The Setup

Zpocalypse is a 2-4 player zombie survival-horror board game. It blends tabletop combat with card-based mechanics to create a fun game of resource management and zombie killing. Each player controls a party of survivors dependent on the number of survivor cards the player has in their hand. The resources used are Food, Scrap, Ammo, and Medical. In order to fight zombies, each survivor in the party must be fed; ergo 1 Food card feeds 1 survivor. Scrap cards are used for building fortifications which I will get into in a moment. Ammo reloads gun item cards, and medical cards heal survivors.

Each player is provided with a player board of sorts for tracking a plethora of stats. The boards are of good manufacture; sturdy and cleanly cut. Even better, the boards outline the course of 1 full turn of gameplay so everyone can quickly figure out the flow of the game. The boards keep track of things like Health, Armor, Melee, and Firearm Skill, and Smarts. Health and Armor are straightforward, these are used during combat. Melee and FireArm Skills affect the combat aspect of the game, determining if special abilities can be used. Smarts are important for event cards.

The game also utilizes an Experience Point system. Surprisingly the game gives one a board with spaces marked 0-60 and little colored figures. This is how the Experience Points are tracked in the game. Zpocalypse calls them ‘Victory Points’ but coming from a tabletop wargaming background, it is not the right use of the term ‘Victory Points.’ Oddly though, the points earned on this board determine the winner as well…regardless, to me they’re Experience Points.

The Turn

A turn of Zpocalypse is broken up into 4 phases; Scavenge, Feed& Fortify, Something’s Happening, Combat. The turn itself represents a full day of survival. The game is designed to end at the end of Day 4 but can be played for longer. The Scavenge phase, each player pulls a Scavenge card. The Scavenge card outlines a scenario that the player’s survivor group goes through. There are things like raiding a candy store or inspecting the local police station. Each card makes the player roll a skill check. The skill is displayed on the card. If the player passes the check, they usually get good loot or survivors. A failure is not devastating but does make things more difficult. Each Scavenge outcome will make zombies spawn on the board.

After every player has executed their Scavenge card, the Feed & Fortify phase is next. Personally, this is part of what sold the game to me as a good game. Only survivors that are fed with Food cards can participate in the Combat phase later on. Players can trade with each other or hoard Food cards depending on their tastes in diplomacy. Next is the Fortify aspect, or where the strategy begins. This is the part where the players build things. Now in reality these objects are 2d counters placed on map tiles on the game board. However the gameplay mechanics make them neat. Players can expend survivor and scrap cards to build things like walls, gates, lookout towers, or traps. Each object has abilities that will help the players survive the night of combat and each object built nets the builder Experience Points.

Once all players have placed their structures on the board, they move to the next phase; ‘Something’s Happening.’ One of the player’s draws the card from the appropriate deck and reads the text aloud. The gist is that each card puts a modifier on the conditions for that Night’s Combat Phase. This is a cool way to make Combat rounds more unique and unpredictable. For example the last time I played the modifier was : a rain storm had rolled through miring everything in mud, this in turn hampered our Survivor’s movement, making maneuvering through the map more dicey.

Now that all the logistics have been taken care of, it is time to smash some zeds! The Combat Phase represents the rest of a Turn (Day). Players take turns moving their survivors about the map killing the zombies that had cropped up during the Scavenge and Something Happening phases. Players as a group also alternate with the Zombies taking turns. Zombies by default move towards the ‘bunker’ (a location on the map that represents the home base of all players) unless a survivor gets within 4 squares to lure them away….(or play the guitar as some sort of psychotic pied piper).

Once the players have killed all the zombies on the game board, a new Turn starts back with the Scavenge phase…or all the players are dead which means time to start a new game…or ragequit, heh.

Net Result?

The end result is a really fun game of zombie survival. There are enough Scavenge and Something’s Happening cards to keep the game fresh for quite a while. Players can even come up with their own scenarios in no time to expand on the basic formula. The Combat phase is fun and made even more exciting with the ability to affect the game board in some capacity with the construction of obstacles.

Game Mechanics that really stood out for me were as described above, the Fortify phase, and the use of a bit of RPG elements like Melee and FireArm skills. I also loved the use of an expanding game board. Overall play time is somewhere in the 2hr range easily. This may put people off but the best part is any give group does not have to play the full 4 days to enjoy the game. Even 1 or 2 Days (turns) are enough for a casual game night, and played this way slows the burn out rate of the game.

Price Point

So, Zpocalypse is a bit steep at 60$ which is the cost of an average video game. I only recommend getting this game if you have a group of regular gamer friends. The game operates best at max capacity with all 4 players present on the game board. Although the game is 60$, you get a good amount of stuff for 60$. There are 4 different types of starting area for the game board with all map tiles being printed double sided. The card art is a bit basic but fun, the text being the more important and fleshed out part. A bit of caution though, the card material felt thinner and flimsier than what I’m used too so try not to bang up the cards too much. The game also comes with specialized six-sided dice for making rolls. For miniatures, you get single-colored figures of the survivors (gray) and a bit of variety of zombie figures (dark green and neon green). The figures are decently detailed and pretty sturdy.

The box set also comes with full-colored rulebook that is about 20 pages. The rules are straightforward but the layout of the pages in the rulebook are bit a jumbled. There is a decent amount of information that the rulebook has to cover, and for me at least, I had a bit of trouble teasing information out of the rulebook due primarily to the page layouts and presentation of information. Fortunately the rules are easy to pick up. When it comes to rule books, I have begun looking at them as a programmer. Although flowery descriptions and layouts are nice to the eyes, I prefer bulleted lists and tables for the rules, with the whole If/Then/Else schtick

.

Final Thoughts

Zpocalypse is a good game. I’d give it 4/5 rating. It doesn’t rely solely on a single gimmick or two. It dabbles in a few types of interaction and does a good job of balancing card and tabletop play. The game has resources to manage, and combat to win. There are opportunities aplenty to screw over your fellow survivors for those precious Experience Points or pieces of loot. I’m much more of a team player though, and the team aspect really shines through when the game reaches Fortify phase where players put down strategic obstacles for added defense. The price point might be a bit steep for the casual gamer, but the game itself will not disappoint. It has quality components and a bit of dynamism thrown in as well.

Back of envelope notes

A good thing to keep in mind is that Greenbrier has moved to expand Zpocalypse in several ways. Each new pack adds a new element to the game for added variety. One modification adds the role of ‘Zombie Master’ who is able to control all the undead along with a group of new undead. This reminds me a lot of the ‘special infected’ from Left 4 Dead series of video games therefore I look forward to picking up a copy. Another game type removes the ‘bunker’ aspect and makes the players wander the wasteland, revealing game board tiles as they explore. It’s always good to see a company support their product and recognize that many veteran players want more of a game they like, but not always more of exactly the same. 

Was gone for too long.

    Yes, it has been over a year since I’ve made a post on this blog. I have not been idle however. Since the last post in here I have:

-        Created and released a video game with my cousin.

-        Moved to a new apartment.

-        Worked on my comic art and writing.

So although I’ve been absent, stuff has still been completed. This is a return post of sorts. I would love to promise a blog every two weeks, but as with most side-projects I usually fail to deliver on deadlines. A more optimistic approach would be to make one post a month until that becomes a habit and then try for one every two weeks. The subjects of this blog are still the same; discussing the development process of board, tabletop, and video games. Along with this, every now and then I will review a board game or tabletop game I have tried. Ok, I think I have enough of the formalities out of the way, on to subject matter.

MetroSiege:

    Ah MetroSiege, the on-again-off-again tabletop game I’ve been working on for the better part of a year. There have been large breaks in between development periods, so maybe more like a total of 4-6 months. I picked up the torch again over this April, testing stuff as usual. There have been some significant shakeups though.

Original Attack Mechanics:

    One major change is how one unit attacks another unit. Originally we were using a single D10 roll and the result was checked against a chart with varying degrees of success.

ROLL	1 WPN	2 WPN	3 WPN	4 WPN	Critical Hit
1	M*	M*	M*	M*	Critical Failure
2	M*	M*	M*	1-H	Shield Emitter
3	M*	M	1-H	1-H	Shield Generator
4	M	1-H	1-H	2-H	Weapon Destroyed
5	H	1-H	2-H	2-H	Weapon Destroyed
6	H	1-H	2-H	3-H	Leg Damage
7	H	1-H	2-H	3-H	Targeting and Tracking
8	H	2-H	3-H	4-H	Reactor
9	H	2-H	3-H	4-H	Capacitor
10	H	2-H	3-H	4-H	Critical Failure

This was a straightforward way to keep most information on one table. M = Miss, H = Hit, M* = miss, ammo expended. The number next to the H (i.e. 2-H) meant that two weapons have successfully hit the target. Depending on how many weapons were put into the group determined the odds of how many weapons were going to hit the target. The last column is determining which Critical Hit the unit has suffered. Critical Hits only occurred when all armor was destroyed and no shield tokens left to soak remaining damage.

    Original ruleset also included unit movement modifiers when either attacker or defender moved. If the Attacking Unit used the Cruise movement mode; it suffered a -1 to its D10 roll, -2 to the roll for Flanking. Also, if the Defending Unit used the Cruise movement mode, then an additional -1 was applied to the roll and -2 for Flanking.

    The net result was not very pretty. Of the handful of test games we played, the game devolved into stationary shootouts towards the middle and end of the game. Successfully hitting a Unit with one attack proved incredibly difficult. Even with attacking with 2-3 weapons, rarely would the Attacker score enough hits to do any last damage. Regenerating Shield tokens allowed the Defending Unit to literally undo the minor damage that did come through. So, this system had to be scrapped and we had to go back to the drawing board.

New Attack Mechanics:

    After a week of idle thought, I stumbled upon something that might work. I’m not going to claim that what I propose is at all completely brand new. There are only so many ways to roll D6’s. Oh, did I mention? Metrosiege is back to being a D6 game rather than D10; buckets of D6 ahoy! I have not finalized the complete set of new rules for attacking but I have a foundation that can be worked with. First was an update to the stats of Weapons. Every weapon has a ‘DMG’ stat which is short for Damage. Damage dealt by a weapon is still 1:1 to Shield and Armor tokens. The change now is, DMG also determines how many dice to roll. Therefore a Particle Beam Cannon has a DMG of 5, therefore the player using the Particle Beam would roll 5D6.

The second part of the equation now is the To-Hit number. Once the player rolls the requisite number of dice, each roll result must meet or exceed a given number. Going with our Particle Cannon example, the player rolls 5D6 for the attack. The results are a 3,1,4,2,3. The ‘To-Hit’ of the Particle Cannon is 3+, so out of the 5 dice rolled 3 dice count as hits. Therefore the amount damage dealt by this particular attack is 3. The intent of these changes is to make damage dealing easier to accomplish. Metrosiege is a game that should be able to be completed in under an hour, hence units should be able to constantly throw damage at each other. Fast and Fun are the pillars.

Energy/Shield Dynamic:

Original ruling on Recharging shields was the following. At the start of the turn, before rolling for initiative and after regaining the amount of Energy tokens equal to a Unit’s Recharge stat the player may choose to spend Energy tokens regaining Shield Tokens. This allows a Unit with depleted Shield tokens to regenerate spent tokens up to their max amount. The Original ratio was 2 Energy tokens to regain 1 Shield token. I have decided to change this ratio to 1 Energy token to 1 Shield token. This makes recharging Shield tokens easier but may come at a cost to game speed as Unit become more difficult to bring down.

Models:

Creating official resin or plastic models for the game is still a design goal of this project. Currently the scale I’m aiming for is 40mm base size for most mechs, maybe smaller bases for vehicles. A solution that I have explored recently was using Lego pieces to construct Units. It took a week to assemble some examples but the net result is pretty cool looking. A benefit of going the lego route is making assembly instruction and the cheap availability of parts. Still another advantage to using Lego pieces is they help enforce the WYSIWYG mantra of most tabletop games. WYSIWYG = What You See Is What You Get, if an item or model is not present in your army then you cannot have the particular item. Likewise if a model is holding a certain weapon, then unless otherwise specified, that weapon on the model is what the rules say it is.

Planned:

-More games, this is crucial. I plan on playing at least 10-12 games with the current ruleset.

-updated Vehicle Info Cards.

-New sketches for units.

-Explore new game mechanics like Electronic Warfare.

-Create a table of lego parts and their corresponding description.

Reactor Online. Sensors Online. Weapons Online. All systems, nominal.

After quite a hiatus, I will be posting on this blog again, details coming soon.