Mechanical Review: You can't go home again.

This post is an addendum to the fantastic blog post here:
       "Don’t remake an old game" by Eamonn McHugh-Roohr

Ask yourself honestly, what is the remake for your Old Favorite Game?

Is it a graphical bump? expanded player abilities? re-balanced item stats?

Regardless of your choice; you are not remaking a game. In fact, you have begun to make a new game. This new game might look like Old Favorite Game but, there is no possible way to actually remake this game.

The passage of time on game technology

The Old Favorite Game was beholden to incredibly contemporaneous things like:

• processor clock speeds.
• GPU clock speeds.
• Memory caps.
• Built-from-scratch movement and physics code.
• Item stats either not refined enough, or balanced to clockspeed-influenced gameplay.

The Old Favorite Game upon final compile and shipment is sealed in stone. A result of decisions and code made for its time. This is an important perspective, because it plays into the next part: game-feel.

You will not be able to actually recreate Old Favorite Game's game-feel. This will happen in both explicit and subtle ways. The explicit comes from simply using a newer engine. The new engine will have different clock speeds, update cycles, memory management. Trying to achieve a straight port of Old Favorite Game to this new engine will. not. work.

The advancement of technology will also play into many design decisions you and/or your team will make; some subtle changes may be required because to do otherwise would be making work harder on yourself.

 

A short exposition on Game-Feel

Obligatory wikipedia entry: Game Feel

"the intangible, tactile sensation experienced when interacting with video games."

Big emphasis on intangible. What you experienced when playing Old Favorite Game is part of this Game-Feel. You can't adequately describe, neither can I, and worse still - you and I could potentially have a sharp divide in what we believe the Game-Feel is for this Old Favorite Game. 

A preliminary diagnosis of The Remakes fatal team dynamics

Already the vision of remaking Old Favorite Game has fractured. We haven't even reached the design decisions! Even if you assemble a team of mostly unpaid game fans to remake the Old Favorite Game, and big if you get them to mostly agree on the Game Feel, we run straight into the design brick wall. It gets a bit meta here, but its important for understanding the overall point I want to make.

The moment you or the team decide to alter Old Favorite Game's stats, game environment, or say move to a new engine - you've fundamentally altered the game.

You will not be able to actually recreate Old Favorite Game's game-feel. This will happen in both explicit and subtle ways. The explicit comes from simply using a newer engine. The new engine will have different clock speeds, update cycles, memory management. Trying to achieve a straight port of Old Favorite Game to this new engine will. not. work.

The subtle changes will come from you or the team. In the energetic frenzy of development, you will say "Why don't we 'fix' this?" or another goes "I always believe that the game should have done that". Whether you are willing to admit this or not; these questions are in fact creating a new game. This new game may look very similar to Old Favorite Game, but it will never be the same. The new game will offer new ideas to implement, new translations of mechanics to gameplay. Further and further you will wander from the narrow vision of remake Old Favorite Game.

This sounds sort of obvious right? It does, and it is, so why mention it? I am looking to help you - given the above likely scenario you should leave behind the notion of remaking the Old Favorite Game. This is a notion similar to an iceberg, small on the surface, but incredibly deep. The phrase itself is an attempt to check that all parties in the conversation merely agree with your idea of the game-feel of Old Favorite Game.

Instead of willingly becoming Sisyphus, the mortal doomed to forever push a single boulder up a hill - only for the boulder to roll back down again. You should start with what are the defining things you like about the game-feel of Old Favorite Game. What moments stand out? what aspects of the play-by-play kindle fond memories for you? Capture those. From these ideas will spring a new game.

Maybe the new game is a sequel in a franchise, maybe a fan game, but for pure pragmatism it should be your own creation. You will own this wonderful project, reaping a bunch of benefits including creative control.

A summary:

It is mostly impossible to simply remake Old Favorite Game. 

The process to do so would either be pointless, ie the amount of effort required to remake is equivalent with just making a new game .
Or
The new game will diverge sharply over development time from Old Favorite Game so much as to basically be a brand new game that may appear similar to the old.

best case: you make a fun, fresh, new game inspired-by the old 

worst case: you've wasted your time fighting heat-death itself to recreate something that never really existed concretely. You will be constantly disappointed as each build of the remake fails to spark your joy of playing Old Favorite Game.

 

Why narrow your game design vision so ruthlessly right at the critical start point! Would you claim that Old Favorite Game is the unassailable example of any game? You know the Old Favorite Game isn't even halfway perfect, you'll admit this readily. Don't use Old Favorite Game's perceived infallibility as a shield against new ideas, or interpretations.

 

A parting note: enjoy your memories of your old game and replay this old game if possible! 

it was a lot fun to play, after all!

But disabuse yourself of the notion that remaking this Old Favorite Game will ever bring those feelings back. They were special and unique for you, and functionally impossible to adequately recreate or experience. Instead, look to the future, bring forward what you loved about those games into your efforts.

Mechancial Review: Leg-destruction in Mechwarrior-style video games.

(a  BL-6-KNT Black Knight engages a EXC-B2 Excalibur in desperate melee, circa 2780...)


This post was started off a conversation I participated in on one of the mechwarrior discords, when the subject turned to balancing the Mechwarrior experience to that of the Battletech tabletop game, and to 'legging' an opponent (that is; destroying one or both of a target's legs in the Mechwarrior games).

I asked:
should legging matter?  
Is legging in a PvP game fun? is it fun to win via legging?
Is it ok to lose because of legging?
I don't think it is. Try applying legging to most other FPS action games, and it gets annoying, quick.
If a player is accurate enough to target someone's legs, then making the target even slower is just feeding a run-away-winner scenario.

and one of the responses really stood out:

You’re comparing quite different genres there. Those are FPS games, this is a vehicular combat simulation game.
Stop thinking like an MLG and start thinking like a hardcore simmer :wink:
Also, using that logic, maybe we should remove arm destruction and weapon critical hits since if things like that were put in most action FPS games, it’s get annoying Quick
So would the heat mechanic,
But, I think you get the point
You can’t use those kinds of games as a comparison to MechWarrior as a basis against mechanics such as leg destruction
They play very differently, and therefore the mechanic might work great in one genre, but bad in the other
Could you imagine having section-based damage on TitanFall?
Or an FPS-style, aggressive cone-of-fire mechanic in MechWarrior?
It just wouldn’t work
But section-based damage readings work well in MechWarrior
And the cone of fire system, if done right, works quite nicely in games like Call of Duty, Battlefield, etc.

Which then led me to write up this response:

It's not exactly 'MLG or not', this (Mechwarrior)being a game it's all about players and the decisions they can make , or incentivized to make.

Also, Mechwarrior is not as sim-like as we want to believe.

Mechwarrior exists in a game genre like any other game does, open to criticism as well as evolution and experimentation.

re: Titanfall section-based damage, why not try it?

re: Cone of fire, this is actually more sim-like than Mechwarrior's pin-point accuracy. no targeting computer based on hard-scifi could compensate for the the source gun changing shooting position every split second of a mech's walk-cycle. The positional height difference would be insane, not to mention the pilot being shaken like paint in a can.

Originally I had a longer post about genre conventions and simulations, wanting to say that yes mecha-sims are a 'sim' but they handwave away of massive amounts of realism to make sure the experience is fun.

take it this way: you ever play World of Tanks? it's a great example of unfun simulation. It gets all rivet-counter on shot penetration and deflection mechanics, but somehow your invisible crew can jump out to repair a blown track while under fire...but wait there's more!

if you are hit again in the tracks, your repair meter is reset allowing opponents to functionally immobilize you after a single hit to your tracks. Sim-like? a little, but is it fun? god no. Player experience becomes sitting there, waiting to be eliminated.

re: "make legging more like tabletop" , that has some interesting stuff - like your speed and stability degrading over time as your legs are damaged, but do you really want to sit there in a hex, on your mechs stomach, immobilized for the next 20min? Players do not like it when game scenarios escape their control, and this effect needs to be managed (note: I didn't say removed).

End of the day, I'm saying that certain mechanics should be gamed out to their logical conclusion, assessed, and then adjusted to make sure the player has fun, or that most of the players have fun.

Limping along a giant map for even 5min with a busted leg isn't fun. If the player is playing a campaign, they will probably save-scum at that point, merely restarting the mission.

In multiplayer? might as well just slap the respawn button because functionally their vehicle is dead-in-the-water.

As it exists today: legging is a shallow mechanic that feeds into the run away winner problem. You either leg someone, then control the rest of the fight completely from there - to wit, you've already 'won' by this point. or you don't leg someone, and they don't leg you, and both of
yous are playing as if legging doesn't exist.

so what's the answer? honestly I don't know. I think we'll need a bunch of new mech games to take up the challenge to explore these trickier aspects of Mechwarrior style gameplay, and I look forward to playing them!

battleMETAL - And Yet, Somehow it all works - part 5 - Arming Menu

Load and lock…


On the heels of talking about the Deployment Menu, there’s another menu that I had a lot of fun building and consider a technical achievement: the Arming Menu. This menu is a staple of old vehicle combat games, and mech games in particular like in Battletech, it's called the ‘Mech Lab’. This is the menu where the player gets to exercise a level of creativity, creating a loadout of weapons and equipment that they are most comfortable with. In battleMETAL, every playable ‘Metal (mech) has a set of Equipment Slots. These slots may contain Weapons or Equipment but limited to a set of factors such as item size and the type of item. Here’s a few examples from old school games to showcase what my starting ideas were.

Mech Lab as seen in Mechwarrior 4: Mercenaries

Weapon Menu as seen in Earthsiege 2

These menus can be fairly daunting for a newer player or someone not used to this genre of game. A ton of information is thrown at the player all-at-once, and many decisions here will directly impact the player’s experience when they actually deploy to the game space. However, this is a menu that the game will return to many times, and Players are encouraged to spend all the time they want here testing out ideas. To that end, I tried to make the Arming Menu as straightforward as possible given the limited UI tools at hand.

Proof of Concept Arming Menu ~2016

...Ok, we can do a little better than that, heh. This image was the very first take on the Arming Menu. Although it lacks a lot of graphical icons, one can see the roots of the menu are here. Weapons and Equipment have a UID or unique ID that the game uses when looking up data for the item. When the Arming Menu is called, it grabs all relevant data for each UID, and the data is stored in separate .item files. These .item files are text files renamed to be better understood, and contain a JSON-style data language.



Add in data loaded for every mech in the game and the end result is a wonderful menu that looks like this:




Now this is looking pretty good. We can see the list of available equipment for the Player. We can see the hardpoints that the chosen mech possesses. There’s some other important panels here as well: the ‘Weapon Group’ panel in the lower left allows the Player to set their fire groups. A fire group is a collection of weapons bound to a single fire key. Next to this panel, is the ‘Energy Drain’ panel. This important panel ties into battleMETAL’s Player resource mechanics. In addition to health, Players must be aware of how much Energy their ‘Metal currently has. Energy is used to power weapons, shields (a rechargeable health pool), and sprinting. This panel tells the player how much energy their Weapon Groups are going to draw when used. This is helpful to Player if they’re trying to balance their equipment selections.


In the middle-right of the screen is a very important set of panels, the Weapon Info panels. The top one shows the statistics for the Weapon that a Player has chosen in the menu. The bottom panel is for the Weapon in the selected hardpoint. They’re over/under so that Players can compare directly, the stats of 2 different weapons before mounting any weapon to a hardpoint.


Now for some neat code notes. Every mech has a list of Hardpoints that can hold a piece of Equipment. The data for this is stored in a text file with a custom .unit extension. When the Player selects a mech in the Hangar Menu, that data is loaded into a set of global vars. These vars are not static, if the Player chooses a different mech, the globals are updated with the data of the next mech the Player chose. Part of the data loaded are the hardpoints, Quake C being more primitive means that hardpoint data is loaded into a series of Arrays[] dedicated to each data point. The index of the array is used as the UID of the Hardpoint:

float MECH_DATA_H_TYPE[10];denotes the allowable Types of equipment for the Hardpoint.

float MECH_DATA_H_SIZE[10]; maximum Size of the Equipment.

vector MECH_DATA_H_ARM[10];

vector MECH_DATA_H_HNG[10];


The two vector arrays are specifically for the UI. Currently, I hardcoded the screen-position of the Hardpoints when the Arming Menu needs to draw these on-screen. The Arming Menu code loops through all the hardpoints (game maximum of 9 possible hardpoints) and pulls the position for each Hardpoint from those vector arrays. When the Player clicks the mouse, the code checks to see if the mouse position is within the area near of each vector to determine if the Player has clicked on a Hardpoint. If the Player has, the code uses the UID of the Equipment in the Hardpoint to load the .item data file for that Equipment.


Another great feature I implemented recently was the ability for the Player to save up to 6 different configurations per ‘Metal. I realized that Players would prefer to be able to save their changes to the mechs for later use. Well if we’re going through the trouble of saving something once, then we now have the functionality to save anytime (isn’t programming grand?). The save feature is autonomic and triggered by natural Player interaction with the Arming Menu. Things like tabbing between configs, or switching from different menus and the Arming Menu. The save files are then stored in folders labelled via ‘Metal UID, and then their own number. The save files itself is a plaintext file, and is loaded on-demand. This means that savvy Players can noodle around with just the text file and have it load by simply changing configs in-game. I did put in some validations though, so no breaking a ‘Metal’s Hardpoint values by putting in larger-than-allowed weapons or such.


Finally, once the Player has tweaked the ‘Metal to their liking, they proceed to the Deployment Menu. When the Player hits the ‘Launch’ button, the CSQC takes all their selection data and pushes it up to the Server for parsing. The Player’s chosen mech UID is sent, along with Hardpoint data and Weapon Group options, the server than takes this data and builds the Player’s entity into that mech. Overall, this was a really fun feature to build for battleMETAL, and fairly radical for any Quake mod at all.

battleMETAL - And Yet, Somehow it all works - part 4 - Deployment Menu

Prepare for drop!

Checking my post timeline and realized that this blog series has now been running for a year, huzzah! Also, core coding of battleMETAL appears complete. The last few months have been cleaning up the map pipeline (don’t worry friends, we’ll get there…) which indicates that the main coding is stable! It does feel a little anticlimactic, so many weekends spent hammering this game together in a cave with a box of scraps….


Anyhoo, this article is about one of the in-mission menus. These menus are located in the CSQC module which is run exclusively client side. As described in a previous post about CSCQ, this menu system is brought up with the tab key (default key) after the player has connected to the server. One of these menus is the Deployment menu.


The design scope for the Deployment menu went something like this - Originally I wanted the player to be able to pick from a few different spawn points on any given mission. Previous mech games either lacked this feature or featured it loosely. 2 main impulses pushed me to implement such a feature in battleMETAL with the first being multiplayer. Originally I believed it was possible to make battleMETAL work in multiplayer as well as it did in singleplayer. Unfortunately due to engine limitations across multiple features, this was discovered to not be feasible given the time and manpower limits of myself (I’ll do a post eventually on what happened to multiplayer).


The second impetus came from adapting the multiplayer idea. I considered the Player’s ability to pick their spawn point to be a nice layer of tactical control to give the player in lieu of trying something like an open map or semi-open world. The spawn point selection also allows for levels to contain more than 1 scenario setup - the mission briefing can give clues to the player about the combat conditions at any of the spawn points. Once the player chooses their spawn point, they press the [launch] button, become the mech they chose in the Hangar menu and begin play.


So, how did the code get there? As seen in a previous article, a battleMETAL CSQC menu can be quickly spun up from the functional map. The file acts like a pseudo class where the primary menu functions for the desired menu are kept. I’ll cover the most interesting tidbit which are the deploy points.

Pictured is the Deployment menu with Deploy Points depicted as (A), (B), ( C).


To begin, when the Player connects to the Server, there’s a function call;

client_push_mapobjects()

This queries all the entities on the server that have the FL_NODE flag in their .flags member variable. When such entities are found, their data is piped to the Client via client_send_deployPoint() which bundles the relevant deploy point info into a SVC_TEMPENTITY game packet. The client then receives this data, checking its own global DEPLOY_POINTS_ACTIVE[]. This global array maps its array index to the Deploy Point Id of deploy point entities on the server. The game has an artificial limit of 32 total deploy point entities because of this (not sure if any given map needs more than 32 deploy points).


The ‘important info’ that the server sends to the client is the following:
        Deploy id - float, the assigned id number for the node ( this is not the same as the entity id)

         isActive - boolean, 1 or 0. Players can only see and use ‘isActive == true’ deploy points.

        Origin - the server-side location of the entity in game space as a vector, 'X Y Z'


Quick side note, deploy points can be given an .faction member var. The server only sends deploy points whose faction value matches the specified Player’s faction value. This is a holdover from the multiplayer functionality where originally PvP was going to be a thing.


Once the client has the list of deploy points, the next step is how to render them. I really wanted a clean and programmatic way to render any deploy points anywhere on the given map space. Other considerations included the fact the player in a singleplayer-context only really ever sees the Deployment Menu once per map (even if they die, the map just restarts). Due to this, there wasn’t a need to constantly send live updates of deploy point data to the client. Knowing this, drawing the deploy points onto the menu screen was fairly straightforward.


Of the few things that CSQC gets ‘for free’ from the framework is data about the world entity. I can’t remember in the C-code all of the vars in world that are sent over, but there’s one important set - .mins and .maxs. These two variables contain the size of world’s total bounding box, just like other entities have bounding boxes. Knowing the bounding box of the world allows us to compare entity locations to some sort of pseudo-constant for game space. Using this info, I created an algorithm for projecting a map coordinate onto a 2D UI panel.

1. Find the map’s total size
1. Take the mins value as a positive number and add the maxs value
2. Find the center of this new size
2. Take the mins value as a positive number, then divide it over the total size
1. This returns a percentage value ( see where I’m going here?)
3. Apply the percentage to the UI panel’s screen size
4. profit.

This algorithm allows us to display any game coordinates onto any-sized 2D space and you can see this functionality on the Briefing menu as well. Nav Points are player guide posts for navigating around the map and the same algorithm renders these points onto the Briefing menu just like the Deployment menu. Now that the Player can see where on the map a Deploy Point will place them, the next part is spawning the Player at the point they have chosen. When the player clicks the Launch button in the upper right-hand corner, the CSQC fires off a message back to the server. This message contains the player’s chosen mech, the mech’s equipment id’s, and the Deploy Point to spawn at.


When the Server receives this message, it goes and looks for the desired Deploy Point, and if it finds the point, will then move the Player to that point. The fallback scenario is that the Deploy Point is not found, so the code defaults to the map object Info Player Start which every map needs regardless of usage. That’s all I have for this post, an interesting small feature that was fun to implement and fairly unique for Quake mods. There’s probably some refactoring that could be done on the algorithm but I figure its low-cost enough to stay as it is.

battleMETAL - Quick update 4/15/2019

Where the hell have you been? 

I know I know, I'm really bad at maintaining a blog. So I've been busy with a slice of life, some major tech fighting with battleMETAL (oh we'll get into it soon), and starting a new job soon. I do want to return to the 'METAL Monday formula, its just that blog writing was cut from the schedule because it was something that could be sacrificed. I'll return to blog posts on May 6th, 2019 and we'll keep diving into the bucket of fun that is battleMETAL. 

In the mean time, the game itself is pretty much feature complete and I've moved onto level generation. I have a tentative Beta release date of Q3 2019, and then we'll see how things look from there. Stand fast, DEAD HANDS, your activation is pending.

 

battleMETAL - And Yet, Somehow it all works - part 3 - Animatics

Quite an animated conversation

One of the feature’s I wanted to exist in battleMETAL was that of ‘animatics.’ For background, an ‘animatic’ is like a glorified slideshow. These are usually defined as a series of static images displayed in a sequenced order - like a super slow animation. Why would battleMETAL need these exactly? Why for character transmissions of course. I wanted characters to be able to talk at the player, or about the player to other characters in a way that player could visually see and understand. Radio transmissions that don’t show some sort of image are hard to follow in the ebb/flow of a video game. The concept of a ‘radio operator character’ for players to interact with is also a long-established mechanic in gaming.


Part of the original scope of battleMETAL was that the player won’t do any interacting with characters outside of combat. This was mainly due to time and resource constraints, but also because of the story and who the player is in this world. However, the player still needs some things to go off of when playing the game, so I felt that I could implement workable animatics to cover this gap. The system I finished is ‘good enough’ but probably could use some refactoring to make it ‘best’.


I started with CSQC, the animatics being an entirely client-side event, in my mind. I created a short set of api functions to handle the flow of the animatic system. The overall design is something along the lines of:
 
    Receive event from server
    Load animation file
    Validate file
    Setup playback variables
    Render frame 1 
    Render next frame
    End playback


The kick off is the server sending a command to the client to begin an animatic event. Quake was designed from ground up as a client-server game even in single player. Single Player in vanilla Quake is just a local game server with a max player count of 1. So even though battleMETAL only has 1 player in its server, the code still treats that player like any other remote-connect client in the code, which I think is a good thing. On the server, I created a custom map object, event_animatic that can be triggered by player touch or by other map objects, which sends a command to the target client to begin the animatic.


When the player’s CSQC receives the command, in this case changing the player’s “state” variable to _ANIMATIC, the CSQC begins the playback of the animatic. First step is loading the file. I decided that storing animatics in plaintext files was super handy both for readability and performance. The game engine doesn’t need to keep possibly dozens of animatic scripts in memory during gameplay, and because animatics are a low-delta event with no read/write commands, having the game load them from text files seemed like a good approach. I’ve always enjoyed the JSON syntax for data storage, considering it a better alternative to XML. Leveraging the Darkplaces source port’s ability to parse text files, I whipped up a crude JSON-style parsing function. Besides, its always fun making your file extensions.

So in test.anim we see the following:

{
  'music' : ,
  'nomusic' : 0,
  'backimg' : ,
  'trans' : ,
}

The first { } is always the ‘metadata’ tags for the animatic file. Music is which sound you want to play when the entire animatic starts up, and this will play until the end of the animatic. NoMusic will shut off any CD music playing in the background ( don’t worry, it’ll resume the stopped music when the animatic finishes). BackImg is if you want 1 background image to be rendered beneath all subsequent image frames. Finally, Trans is for ‘transparency’, setting the global alpha value of the animatic during playback. These values are then stored in a 1-dimensional string array labelled simply named ANM_META_DATA. Once the metadata is loaded the text parser expects frame data to come next. Frames are defined by { } as well, and there’s no true limit, for the sake of brevity I imposed a 20 frame max (do you really need moar?).


{
  'image' : gfx/hud/target_box.png,
   'pos' : 0.79 0.225,
   'size' : 0.05 0.05,
   'sound' : sound/anim/t1m4_lineb.ogg,
   'text' : ,
   'alpha' : 0.85,
   'color' : 1 0 0,
   'text_color' : 0 0 0,
   'time' : 3,
}

Image is which image you want this frame to display, and you can set it to null / empty.

Pos is ‘screen position’ important: this is done in percentage of screen to make sure that the coordinates are screen-size agnostic.

Size is the size of the image. important: this is done in percentage of screen to make sure that the coordinates are screen-size agnostic.

Sound is the sound file you want to play on this frame. Its non-looping, and is not clipped by any sound on the next frame, so playback overlap is a risk here.

Text is any text you want rendered, I have this hardcoded to be rendered at the bottom of the screen and centered.

Alpha is the transparency of the frame.

Color is the color-tint you want to apply to the frame image and text. RGB values are in vector format between 0.001 - 1.0 for each color.

Text_color same as Color but overrides the color for the text.

Time how many seconds to render the frame for.


In addition to these tags, the code automatically does a fade-in/fade-out effect for each frame but I’m still on the fence if this is necessary or not. When the text parser reads these tags into the code, the frame reference number is used as the primary key for a series of arrays. I’m not particularly happy with this solution but I’ve chalked it up to the roughness of Quake C more than anything else….

string ANM_FRAME_IMG[20];
string ANM_FRAME_SND[20];
float ANM_FRAME_TIM[20];
vector ANM_FRAME_POS[20];
vector ANM_FRAME_SIZE[20];
string ANM_FRAME_MSG[20];
float ANM_FRAME_ALPHA[20];
vector ANM_FRAME_COLOR[20];
vector ANM_FRAME_TXT_CLR[20];


Did I mention that any sort of collections are non-existent in Quake C?

The outcome for all this is a simple but working system for achieving cutscenes and character transmissions for battleMETAL. There’s still some refinement to be had mostly due to a lack of use and testing of the code, but as it stands I’ve tested that the code works at all.

battleMETAL - And Yet, Somehow it all works - part 2 - HUD

Heads up!?

Now that we’re sort of familiar with CSQC and what its about, we can take a look at the HUD for battleMETAL. There were 2 distinct phases to arriving at the HUD code that is now in the game. The first step was expanding the GUI functions I had created for the in-game menus that we saw in last the article. battleMETAL’s DNA is western mech sims of the 90’s, and that genre of games loved its HUD mechanics.


a HUD from Earthsiege 2

It seems in hindsight that mastery of reading a mech’s HUD was integral to the overall gameplay experience of a mech sim, given how much information is being sent to the player. One of my opinions as to why mech games lost market share over time was their built-in complexity that scares away newcomers, much like how Starcraft II today.

My first attempt at a HUD system was to take the generic GUI functions I had made, and craft a single HUD for each mech. The entry point for the HUD system was and is a single function call in CSQC_update_view(). I pass the player unit type to the client, and if that unit type is ‘mech’ then it runs the hud_frame() function. In the first system, I created HUDs as entity objects in CSQC, believing it to be the easiest way to hold data and functions for each HUD. You can kinda see the madness here on this github link to the battleMETAL project. Each HUD object implemented the same ‘soft’ interface of each hud element function, along with an initializer function that setup each object.

Now, in a more modern engine or code base, this isn’t exactly a bad idea. A proper class object for each HUD would be a fine way of rendering the HUD. Over in Quake C land, I was not so fortunate - there’s only 1 object close to being a class, the entity, and we all know now they’re not really the same. This attempt ended up repeating a ton of boiler plate code, and overall was too unwieldy. Tacitly, I had made some out-of-scope assumptions about what the HUD should be able to accomplish as a system. It was good that I coded it in a direction towards a robust UI system, one should always code for universality. I realized later that the HUD didn’t need this universality, it didn’t need an open system for rendering layered UI graphics...it needed to be bespoke. Quake C’s limitations have a tendency to hone your design instincts to one-off solutions for each module.

The next step in coding the HUD system was to disabuse myself of trying to make an object-based, layered HUD system. Rather, I decided to reorient the design to being built up from simple functions. I realized that each mech HUD doesn’t really have unique functionality that would ever really differ from another HUD. That is to say, mech HUDs all contain the same information where the only differences are slight variety in presentation and position on-screen of the HUD elements.

It took about a weekend, but I refactored every single piece of HUD code. Rebuilt from the original pieces, I ended up with unique functions for specific pieces of the HUD. A few examples to explain what I’m getting at:

hud_renderEnergyMeter()

Each only deals with rendering a single type of HUD component. The method arguments for each also varies only by the information that each component needs for rendering. The responsibility for drawing the total HUD then shifts up to the main HUD function. This main function is named for the mech that it is supposed to go to, and I used a switch-case statement to determine which HUD is supposed to be drawn. When the player enters their mech, the server sends the mech’s id number to the client, and the switch-case statement selects the function by mech id.

Therefore, any given HUD main function becomes a short list of HUD component functions, the only important data that matters is the on-screen location of the HUD elements and the player data. This approach even allows a little bit of flexibility. To make more unique HUD elements, the code can either encapsulate the component in just the desired HUD or add it to the HUD function library which would then allow any HUD to use it if desired. I applied this principle at least once with the renderWeapon functions.

hud_renderWeapon1

hud_renderWeapon2

Both functions take the same information but render this information in a slightly different way. We can see that each weapon is rendered atomically this way which then also allows the designer to use both styles in the same HUD. In keeping with the modular approach, this entire set of code is only called by a single entry function renderHUDFrame() which keeps coupling between the main functionality and the HUD system loose. This reduces headaches in adding new features to either system, or when changing large pieces of either system. I had a decent amount of fun bringing the HUD system to life for battleMETAL, and I think the code reflects it. Adding new HUDs is straightforward and maintainable while troubleshooting existing HUDs wont outright break too much else.

battleMETAL - And Yet, Somehow it all works - part 1 - CSQC

CSQ-what?

It's hard to go into complete detail about this powerful module for Darkplaces (though I feel obligated to say this module is not exclusive to Darkplaces, and is available in other modern source ports of Quake such as FTE).

I probably already mentioned this earlier in the series, Client-Side Quake C, that is. Recall that Quake C compiles to file of bytecode called progs.dat. This file contains all of the custom game code that the Quake engine runs when the player starts up the game. Client-side Quake C (hereafter referred to as CSQC ) takes this concept and applies it to the client code during gameplay. What this means is that the programmer gets the full power of Quake C - spawning entities, File I/O, player state, player input and more; on the client-side. Want to load custom UI data but don’t want to have to broadcast over the network? CSQC. Custom sound effects played only for the specific client? CSQC. You get the idea.

One of the most powerful features CSQC has is the ability to draw images on the player’s Heads up display, or HUD. Like most features of the source ports of Quake, this is a series of api hooks that rely on the programmer to leverage effectively. The design ambiguity offers freedom however. Using the basic image draw calls, and some input tracking code, I was able to implement a basic Graphical User Interface (GUI) that runs during gameplay. I was also able to make a wonderful mech-style HUD that shows the player most of the information they’ll need to know when piloting the big stompy robots. This post deals mostly with implementing the in-game GUI which ironically is different from the Main Menu system.

CSQC has the following methods that define the skeleton of the system -

    CSQC_Init()

    CSQC_InputEvent()

    CSQC_UpdateView()

    CSQC_Parse_StuffCmd()

There are a few more, but these are outside the scope of this post. A quick breakdown of these functions. _init() is the first function called, specifically once the client connects to the server. Its when the CSQC context begins, semantically it's a great place to put any code you want to be initialized as soon as possible. The InputEvent() handles all player input during gameplay. It returns a boolean where TRUE means the input event was handled by CSQC and thus does not need to be passed onto the server. UpdateView() is the big one, this is where all render calls for custom GUI / HUD / anything else you want drawn get placed. You can also modify the view angles, location, and Field of View for the client as well. Lastly, StuffCmd() is used for handling text-based console commands that come from the server.

I built the in-game menus off a few basic presumptions: tracking player mouse input, the on-screen location of the mouse, a modest set of UI functions, and some variables to track the state of the menu. The trickiest implementations were the modest set of ui functions - end result wasn’t so modest. I was able to get things like lists to work; you can see examples in the Mech Hangar and Arming menus. However I never got ‘scrolling’ lists to work especially due to not feeling the feature was needed in the first place. I was able to ensure that the UI scaled to the player’s display resolution...though my approach was hacky.

I chose a resolution, 1240 x 960, and created all the UI’s to this scale including their screen coordinates. Next, I converted the size or location value into a percentage of (x / 1240), (y / 960). Then, these percentages are applied to the player’s screen resolution. Therefore, a UI element that is 75% of the total screen width will always be 75% of the total screen width regardless of the actual number that screen width is. Its brute-force, but it worked solidly enough to base a menu system on.

The core of any given menu is a set of functions that in a real language would be an ‘interface’, a contract of functions that each menu object would have to implement. Each menu has a _DrawFrame(), _Listener() functions. The menu system uses a switch() control and a global variable MENU_CHOICE to determine which _DrawFrame and Listener function to call. Let’s use the hangar example, we see mechHangarDrawFrame() and mechHangarListener(). Inside each of these functions, we put all the UI elements we’d like to draw for that menu; mechHangarDrawFrame() ends up looking like

     mechHangarDrawFrame(){

         local vector topleftroot;
         topleftroot = VIEW_ORG;

        drawpic(topleftroot, UI_DEF_BOX_512, VIEW_MAX, CLR_DEF_UI_HANGAR, 1,0);

        menu_hangar_MechDisplay(topleftroot + gui_percentToPixelRawVec('0 24'));
        menu_hangar_MechList(topleftroot + gui_percentToPixelRawVec('0 24'));
        menu_hangar_MechInfo(topleftroot);

         menu_hangar_MechFluff(topleftroot);

         menu_hangar_MechHPoints(topleftroot);

     }


drawPic() is a CSQC function for drawing 2D images onto the player’s screen. The other functions are made by me, and each renders a different part of the Mech Hangar GUI so that the end result looks like:
 

The second part is reading player input when the menu is active. For each menu, there’s a distinct function, and in our example its mechHangarListener(). This function contains all the input-related behavior that the code will call when the player inputs something.

     mechHangarListener(){
         mechSelectListener()
     }

Where mechSelectListener() is ‘listens’ for player input on a specific UI element. Quake C is fairly rudimentary, so the means for capturing player input in-context of a GUI was crude. For starters, the code I wrote breaks the screen up into rectangles. The specific Listener function will give the coordinates for the rectangle. When the player clicks the mouse, the listener code then checks to see if the mouse’s screen location is inside the rectangle that it defined. If the mouse is inside the rectangle, it returns the TRUE value, and again it's up to the listener function to handle this result. For lists of objects, such as the list of playable mechs, the ListListener function actually returns the index number of the item on the list. So if the player chose the second Light Mech, then the listener return value would be 2.

There are some drawbacks to such a simple menu setup; the biggest being items cannot be layered on top of each other. Each menu is only ever 1 ‘layer’ of UI elements deep. Another one is scrolling lists, I’m sure with some extra effort, getting the scrolling lists wouldn't be too bad. Finally, there is no way to drag-and-drop items (because there aren’t any ‘layer’ of menu). If I had more time for polish, I would have added some drag-and-drop functionality, especially for the Arming menu.

battleMETAL - And Yet, Somehow it all works!

And Yet it moves…

       So the last set of blog posts laid out some of the daunting challenges that I faced over the course of the project. Darkplaces / Quake when the project started in mid-2016 was fairly old, but only when working through battleMETAL did I realize how old. 

      However, all is not doom and gloom! In this next sections I will talk about the cool success stories. We will get into neat things like the various iterations of the player’s Heads-Up Display, or the game save system. Overall I’d say that in many ways, Quake gives you enough rope to trip yourself with...over a cliff...into the ravine. It's a shoddy metaphor but it is sort of true. Compared to modern game design sensibilities, Quake is clearly lacking but because it starts out so empty you end up with an odd freedom of action to implement your own stuff.

       I’m not going to say it was entirely smooth sailing, but I’d like to believe that because of the inherent freedom of the code base, I was able to get a lot of mileage out of such an old engine. I would also like to credit the folks over at insideqc. They have created a great repository of go-to examples and an extensive forum post history that answers most of the straightforward questions you might have about Quake C. If I ran into a situation where I couldn’t find an answer to my question online, I’d go to the fallback - reading Darkplaces source code over on github

So onto the showcase of features that I bashed into an engine whose core is 22 23 years old! (its 2019 now...d'oh)

battleMETAL - Why that was a bad idea, a terrible idea - Part 6 - Game Logic

A series of events;
 
    An important part of any game is level design and the game play loop of the level. One of the reasons I chose Quake / Darkplaces is because of how mod-friendly the map making process is...and how well documented it is. Back in my high school days, before learning to code, I had dabbled with making maps for Quake II. iD Tech games all generally used a tool called GTKRadiant for level creation, this was an all-in-one map maker for their games. The tool allowed users to created the full 3D spaces of a Quake level, place map objects like weapons, monsters, and player start zones. It also is where the logic of a map was created. These logic map objects were under sections called trigger_ and func_. They are responsible for making doors that move, elevators, changing maps, etc.

    There’s an old joke about iD games using the map design called a ‘monster closet.’ A monster closet is a part of the map where, behind a seemingly normal piece of wall, a monster or two is just sitting there. When the player gets close, or triggers a specific event, the wall opens up surprising the player and dropping monsters on them. This is a joke because if you look at the wall, it doesn’t look like it should logically have any space behind it and what exactly were the monsters doing behind the wall? Taking a smoke break?

    For this article, let’s focus on the how of the monster closet. The user in GTKRadiant would create a space behind the wall. They would place monster entities into that space. Next they’d turn the ‘normal’ wall piece into a door. The door, like the monsters, is another entity. Rather than relying on a specified model though, the door entity uses the map geometry its assigned as its model. Then the map designer would create another map object; trigger_once, point it to the ‘wall’. The Quake C would then say, “when the player entity touches trigger_once, open the door.” In this regard, we can say that the map file holds a lot of the game state and logic. 

    I believed that at least for map design and creation, Quake was a good move. Creating custom entities that the editor can place was fairly straightforward. GTKRadiant uses a text file to define all the possible map entities that can be placed before compiling the map into a format that Quake can read. By adding my own battleMETAL objects to this text file, I found it was easier to create maps specifically for battleMETAL - including the really cool aspects like Nav Points and Objectives ( we’ll get to those in a bit). Unlike AI which I covered previously, the map logic schema for Quake is surprisingly flexible. The map editor GTKRadiant uses a series of ‘definition’ files containing text, usually called entities.def. This file contains the definitions for entities to be placed on the map.

    The definitions must link to function names in the Quake C code. For example, the definition for an enemy AI looks like this in the .def file:
   
/*QUAKED unit_human_mech_sniper (1 0 0) (-14 -14 -20) (14 14 20) <spawn flags>
        <description text here>
    */
   
    The “QUAKED” is the head tag for an entity definition, the next piece is the function name “unit_human_mech_sniper” which should be defined in the Quake C code exactly the same wording. From what I can tell, the map compiles the entities and converts the function name either to a reference or compares the function name to all the functions in the code to find a match. Once the game finds the right function, it creates an entity and then calls this function on that entity. Whatever code is written in unit_human_mech_sniper is then run immediately.

    The next series of arguments are as follows: color in GTKRadiant, and the bounding box size. The color is for color coding the entity in the map editor, making it easier to tell entities apart from each other. As for bounding box size, that is also shown in the editor, but will also be passed to the engine when the entity is spawned. Quake C code can override the bounding boxes if it is needed. Spawnflags are an important piece of data for both the editor and the engine. Flags are a data storage concept used in general coding. They hold a series of “yes or no” sets in a single variable usually by using binary math. For our purposes here, every entity has a spawnflags field which can set up certain “yes or no” choices when the entity is created. The exact wording is up to the coder, so one entity might have DROP_TO_FLOOR for a spawnflag while another has START_INACTIVE.  The map editor will render these as checkboxes.

    Finally there’s a the descriptor section, it is here that normal text will be rendered in the map editor but has no relation to code in the game. This section is for any relevant info about creating, placing , and using a map entity. Altogether this system is fairly easy to understand and extend for modding. Debugging is nice as well, if engine can’t parse the entity from the map, it simply removes the entry and logs the result into the console.

    Now that we have context for the maps, we can do quick overview of the game logic itself. Every gameplay instance in Quake takes place on one of these maps files. The map is loaded up when the server switches to the desired map file. In Quake C this before  the Main() function is run, the main is the entry function for the Quake C. StartFrame() is any code you want to run before the engine runs all other code in that slice of server time. From here the game instance if open-ended, where the ‘end’ of a map can be determined in a few different ways. Vanilla Quake used round timers, kill counts, and map entities to end a game instance and load the next map. For battleMETAL I needed something a bit more sophisticated, seeing as how the game is descended from different DNA.

    battleMETAL is inspired by mech sims, in which part of the simulation was of more authentic military scenarios. This meant that the player is given a set number of ‘objectives’ to achieve before the scenario is ended. The objectives sometimes were destroying things, but other times it was just visiting a location on the map or protecting a base of buildings from an attacking enemy. So, to achieve a similar setup as I created some custom map objects - the Objective, and the Nav Point. I also extended the game engine to load in a text file called a “mission file.” The world map entity would have a variable that pointed to a specified mission file that was loaded to the player’s view when they connect to a map. The code I wrote also sends a unique objective ID for each objective on the map. This is linked to a list of objectives in the mission file. Together, they communicate objectives to the player both during the briefing and game play.

    Of all the things I found to be difficult with battleMETAL, this was surprisingly not one of those things. The configuration of GTKRadiant is fairly well documented and extending the functionality of making maps for my specific game turned out to not be a lovecraftian nightmare, unlike other parts of the project….well except for those 3D terrain meshes…<sigh>.

battleMETAL - Why that was a bad idea, a terrible idea - Part 5 - AI deux

Ah, that army...well played.

    Now that we have some context about how the Quake AI code works, we can look into why it was a no-go for battleMETAL. The first hiccup is how battleMETAL builds its AI entities. Like the player, AI entities are built using the same factory pattern code. The entity is actually a bunch of entities strung together - things like torsos, arms….legs. battleMETAL units are not animated as a complete distinct model. Because they are collection of parts, each part has its own animation. This breaks the original Quake C architecture and its reliance on the frame macros (as was explained in the last post).

    The unit piece with the most animation was the leg entity for mechs. However, the animations for the legs are not authoritative to other entity states. Therefore most code hooked up to leg frame animations is not decisive, but rather cosmetic; reacting to game events as they happen. Just having this one attached entity threw off the need for using Quake frame macros. A different solution was needed, and that was using a state machine. State machines are abstract computer designs that describe a series of ‘states’ for an arbitrary object. An AI object is a good candidate for state machines, where the state in the state machine could be a set of behavior or actions that the AI performs.

    Mind you, this was after a few other attempts to split the difference with Quake’s original AI implementation. The original code also had a set of generic AI behaviors that most monsters would invoke in about the same sequence. There existed functions like ai_walk, ai_run and so on, these were called on a per-frame basis and packed into a frame macro for the monsters. Additionally, other functions were used by the AI during gameplay to assist in calculating attacks, spotting the player, and moving around defined node entities.

    All of this existing functionality was put off to the side, to be reworked into the new AI design. Using a state machine, I broke down almost all the possible actions that an AI could take into 2 categories - states, and actions. I then declared a state to be a collection of actions. I credit my cousin Eamonn with the idea of making actions were atomic as possible ie each action as a function call would only do 1 specific thing. For example, the walk state would be the following actions:
    Scan for enemy
    Move to patrol node
 
And that would be just the walk state. If the AI spotted a valid target in Scan For Enemy, the the AI would transition to the Run state. The code marks each state with an integer, 0 = Walk, 1 = Run. Each entity then has a series of member function pointers to each state like mech.st_walk(). When the AI is created, the code tells the AI which version of of st_walk to use. In the case of mech units, they’d be assigned the mech_walk() function. 

    Then, the AI keeps track of which state it is in by having a variable called .attack_state, when the AI executes its code every frame it looks up which function to run by using its state variable. Once this paradigm was implemented, I took the idea to the next step - organizing collections of states into ‘behaviors’ or ‘unit types’. Tanks and Mechs would clearly need their own sets of state functions because of how different these units are. Using this approach I found it was easy to implement even more unit types like turrets and non-combat vehicles. Each behavior set, although using the same list of actions has their own logical flow for states, and changing the state they are on. The result is a fairly flexible and open-ended design for adding AI and its behavior.

    There are still some limits due to the foundation of this code being on Quake. A big one is AI movement. The Quake C uses an engine function to actually execute the movement of bots and no physics operations are carried out, this results in stiff movement of bots that doesn’t really look natural. This also results in bots running more slowly during gameplay, their per-frame updates are less because of how proportionally expensive it is for the game engine to move bots. In the end I’m ok with the outcome of the AI, despite its limitations I was able to add a few diverse unit types to the game. This diversity helped make the game more fun and engaging to play.

battleMETAL - Why that was a bad idea, a terrible idea - Part 4 - AI

Oh yeah? You and what army?
Another tarpit that consumed many months of dev time during this project was the AI. Quake was never known for its AI, which was only ever serviceable. The problem was thinking that the AI was extensible for the needs of battleMETAL. Quake AI is good enough for ‘basic’ FPS games. The code available allows for AI that can follow defined paths, attack and ‘fight’ with the player, and some limited hunting routines. All of this code is laid out in a few generic functions available to all AI and any monster-specific code is defined in that monster’s code file. Quake monsters are fairly capable of engaging the player in the tighter, more confined environments that Quake uses (big surprise). However I estimated that expanding level geometry size would not have had a great impact on the AI code, not realizing just how tightly engineered the AI code was.

The first wrinkle encountered was one part of how the AI code is implemented in Quake itself. Quake C functionality sits atop the C code of the engine, with limited access to engine-level code (by design). This equates to the Quake C doing the bulk of the AI work here. This means that AI execution is a tad slower due to the nature of Quake C being a parsed language versus running straight C code. I accepted these limitations due to lack of foresight and with the mistaken assumption that I could reuse a lot of the original code.

First hurdle turned out to be understanding the way the AI code was written. For example, in the m_grunt we see the following function:
                   void() army_stand1 [ $stand1, army_stand2 ] { ai_stand(); };

For me, that looked really wierd, and I had not encountered similar code in the project other than some simple animations for sprites. Let’s break this one down; what we’re looking at is a code macro. Code macros are like syntactic sugar, which is lingo for ‘shorthand’. Much like other abstract languages, such as math, have shorthand notations when writing large segments and code can also have shorthand. Most of the code shorthand is usually already baked into the language syntax itself, such as var foo = a_value. This is shorthand for the computer assigning the value a_value to the variable foo.

But what if you found yourself writing the same code many times, and would rather reduce this code to a simpler syntax? This is where macros come in. Macros can be user-defined, and customized according to the needs of the programmer. For Quake C, iD created the macro I mentioned earlier, for use with animations being synchronized to game code. Originally the animation frame rate was tied to the game’s frame rate, mostly because computing power was very limited back in 1996. It didn’t matter that the animation was tied to the game’s update rate because usually that update rate didn’t surpass 20FPS on most systems. The second part was tying game code to the animations themselves; what should happen when the Frame X of the animation is played?

So looking back to the example macro, this is what it means

        Army_stand1 is a function definition.

         The [ and ] are part of the Frame macro, this has 2 arguments, the frame number of the current frame and the next function to go to.

         $stand1 is the frame number of the first frame of the ‘stand’ animation.

         Army_stand2 is the name of the function that should be executed next after this function( army_stand1 )
 
        The { and } then define the function body for army_stand1, what code should be executed on this frame.

When dealing with models that have dozens of frames and multiple sets of animations, this is a clever way of organizing the overall flow of the entity’s animation and code. Knowing the schema for the macro, you can now read through a model’s game logic quickly and easily. There is a cost however.

The macro is more rigid than writing the code out yourself every time. What I mean by this is that the frame macro is laser-focused on solving the animation / code synchronization issue. What happens when I don’t need any code to run on a frame of animation? I still need to define the macro for that frame. This creates a problem at-scale when model animations start reaching the dozens or hundreds of frames. That was the main reason why I, once understanding what the macro does, ditched it in favor of my own approach.

I won’t go into super detail about all the attempts to bring the AI to life - there were 9 major runs of work to arrive at the solution I went with, spread across 3 distinct solutions. The 3rd solution was what ended up working, and even then I have ways it could have been improved. This topic will continue into at least a second post so I can discuss the working solution...

battleMETAL - Why that was a bad idea, a terrible idea - Part 3 - Collision Systems

About those multi-part models

Collision systems a core part of any video game engine. From the first version of Pong up to the latest games on any platform, these systems are responsible for processing impacts between game objects in the game space. In general, like most computer code, collision systems have to be built at some point because a computer does not intrinsically know when two ‘objects’ have hit each other. The complexity of these systems can vary wildly depending on how detailed the game wants to get for collisions and how complicated the game itself is. Quake’s collision system is fairly simple for a 3D FPS.

The collision system for Quake starts with a series of boxes, or specifically, axis-aligned bounding boxes (AABB). Woah there’s some jargon, AABB simply means that the collision model for a game object is a box (technically a rectangle because box proportions can be altered). The axis-aligned part means that this bounding box does not rotate. The model can change angles all it wants, but in the eyes of the collision system, it never rotates - this is an important distinction.

Here we see Quake Guy and his AABB. Whenever Quake Guy hits another entity, or is hit by entity, the game doesn’t check the Quake Guy model for this collision. Instead, the game sees if Quake Guy’s AABB was contacted; which is mathematically simpler and therefore a faster calculation. The downsides to simple AABB is the lack of detail in collision detection, this can be best seen when Quake Guy is standing on a staircase or slope. Notice how only a few corners of the AABB are touching the ground?

Let’s make one quick jump back to the previous post about models, specifically the models that make up a mech in battleMETAL. These entities use a move type called movetype_follow which tells the game to always keep the entity’s center as an offset from a code-defined center in game space. There’s one important detail here, entities with movetype_follow cannot have a collision AABB. As a restriction, this exists because the use-case for movetype_follow is for cosmetic models put on the parent entity - weapons, clothes, etc. For battleMETAL, this means that the various mech parts that are seen on-screen don’t actually have a link to the collision system. Hm, but battleMETAL requires a feature where mechs various parts can be blown off the mech.

The solution implemented is a bit obtuse to manages to satisfy the requirement and still work. The player seen on screen is a heavy composite of several code pieces and models. To start, the player doesn’t actually have a model bound to its entity structure. Rather, the visual components - the mech piece models - are all separate entities using the movetype_follow functionality to appear in the correct location during gameplay. From the perspective of the collisions system however, these pieces are ‘wrapped’ inside the player’s main AABB. When a player is struck by a weapon, the following is executed in the code:

1. Determine the gamespace location of the hit, this is a 3D vector of X Y Z
2. Query the gamespace location of every mech piece that the player-being-hit owns.
3. Find the closest mech piece to the hit origin.
4. Closest mech piece becomes the area that is ‘hit’.

More modern game engines can execute what is called Per-Poly collision where the gamepsace location of a collision between objects can be focused on the smallest parts of the models themselves. Quake is much more primitive as we have seen. The solution that battleMETAL uses is not the most precise for players, but works surprisingly well in-action. The majority of hits against a target are applied to the correct piece of the mech (if the target is a mech) and battleMETAL uses this multi-part collision detection only in very limited cases. Every weapon strike is a short loop through all the mech parts of the mech target, which can get computationally expensive if a lot of mechs are on screen.

There are some quirks to the written algorithm as well.

1. Ignores the volume of each model piece on the mech
2. An imprecision thats hard to detect
3. Effects on mech design
   

In the end, this was deemed acceptable if it allowed players to destroy components of mech models in the game. There are several other problems with the collision system being so primitive - such as interactions between moving objects and the terrain models. The 4-point ground detection code can get a bit cagey when trying to detect collisions with a terrain piece that changes its slope too quickly- something like a really bumpy road or rocky area. This necessitated keeping terrain features more simple in their mesh complexity.

battleMETAL - Why that was a bad idea, a terrible idea - Part 2 - Model Mishaps

Compromises were made
Models are a good enough place to start about things that went awry. The most complicated models so far in battleMETAL are the star units themselves, the metals. The game requires that certain game units have multiple hit locations that can be destroyed before the entire unit is killed. In the case of the mechs, the locations are the center torso, left and right torsos, left and right arms, and the legs. 5 locations total for every mech unit. To better communicate damage to players, it was decided that arms and torsos should be ‘blown off’ when the health of those areas reach zero. This translates to each mech piece its own disconnect mesh, like a lego piece.

Most FPS games don’t deal with complex vehicles, they are scaled to people-sized players and monsters fighting. The models for each of this units is usually 1 solid, animated mesh. Despite complexity of the model, the fact that model is 1 contiguous piece of geometry makes working with them fairly easy. Having five sub-models that make up one complete mech model gets heavy very quickly. It increases the number of files per game unit, makes coding for game units a bit more complex. More modern game engines can handle this complication using techniques like bone-based modeling. Quake was made slightly before skeletal animation became an industry standard. Half-Life is credited with bringing skeletal animation to the mainstream and Half-Life’s engine is a heavily modified version of the Quake 1 engine.

Darkplaces does allow for skeletal animation but it comes with some severe catches. The quake c code for Darkplaces can utilize bones but only on the client-side. Now why is this a problem? I think I mentioned client-side prediction as an issue in previous posts. The snag with this approach is that the bones are only rendered on the client’s side of the game code. If the bones are only on the client then the location in game-space of those bones becomes an issue due to discrepancies between server and client game states. If Darkplaces came with out-of-the-box client-side prediction for programmers to work with, then this might be less technical debt. As it stands, client-side prediction was left up to the individual coder for some...reason...and not every programmer is up to the task of solving a such a complex issue.

The other possible option for skeletal animation is found in the Quake 3 model format called md3. This model format was made for Quake 3, itself a multiplayer-centric, fast-paced, arena FPS from late 1999. Quake 3 also made an attempt to fix client-side issues of skeletal animation but John Carmack went about it in his own unique way. MD3 models can be given little ‘tag’ triangles (a triangle being made up of 3 vertices in the model). Each ‘tag’ would then be given a unique name within the model for later reference. The technical debt of this approach is how tags are organized. When making a model, the tags have to be made, pointing in the desired direction of orientation for the mesh that will be attached there. The tags themselves are not saved when the model is exported to md3, thus any subsequent work on the mesh will require remaking the tags in their specific location.

For Quake 3 models that only ever had 1 or 2 tags per model, the ‘tag’ method was an ok solution. battleMETAL however, breaks this through complexity of the models in the game. The solution I settled on isn’t exactly performant for multiplayer gaming (thankfully battleMETAL is more a single-player game), but it does work. Remember how every model is an entity in quake c? Entities can be given specified ‘movement’ types to reflect, in the engine, how the entity is supposed to move. Player entities have MOVETYPE_WALK which is for handling player movement and physics. Darkplaces expands this functionality by adding a new MOVETYPE_FOLLOW. This movement mode is for objects that cannot collide with anything, and is for entities that, well, follow another entity.

General use-case for movetype_follow in the context of Quake is things like, having the gun model that a player is holding reflected externally by having a gun entity set to movetype_follow. Using this, battleMETAL treats all mech model pieces as separate entities with the movetype_follow. The locations of the pieces are set in relation to the controlling player’s origin point. In this way, the requirement of having hit locations, and visible damage have been satisfied without resorting to time consuming or costly programming quirks. The code uses the Factory Pattern to turn a mech data file into a mech, including the construction of the model component entities.

battleMETAL was able to use some animation for the mech models in the end. The leg models for every mech are animated in the model creation program and exported to the md3 format when animations are complete. The quake c code then controls the playback of those animations. Although this means animations are comparatively ‘stiff’ when put next to modern games, they are sufficient for the project.