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 - Quake/Darkplaces was a bad idea - Part 1

This was a terrible idea

Late again with the blog post, ach, about 2 weeks out from moving to a new location. This part is a quick overview detailing all the fun to be had pointing out why Quake / Darkplaces was a terrible choice. A feeling that I had upon reaching spring 2018, having been working on battleMETAL since July 2016, was that of exhaustion. Any strengths that the Darkplaces engine might have offered turned out to not really offset the Technical Debt that was incurred by the requirements of the game.

A great example of this situation was level creation. For original Quake, the best way to make levels is to use one of a few tools specifically dedicated to this task. Tools like GTKRadiant, QUARK, or TrenchBroom. These tools facilitate level creation by providing a means for designers to create the terrain for a level, place objects such as lights, monsters, player start point, select textures for the levels, and modify lighting. The level building tool then compiles all this information into a .bsp file that Quake loads when entering a level. Mapping for Quake is a well documented process, the advantage of being a popular and easy-to-mod game from 1996. There was just one big hitch in the process - Quake can’t really do outdoor terrain, cue the record-scratch sound.

See, in 1996 - and even well into the late 90’s and very early 2000’s, outdoor terrain was hard to achieve. Computer power was more limited despite the advances since 1993’s DooM game. Many games achieved a feeling of outdoor space through camera tricks, data storage techniques, or even art / design aesthetics. The method that Quake uses for creating level terrain is called Binary Space Partition or BSP. We’re not going to go deep into that particular set of computer programming, rather here’s the gist: the game (Quake) creates walls, floors, doors, ceilings, ramps, stairs, etc out of chunks of 3d space called brushes. When the map is compiled, the compiler takes the interior space of these brushes and compiles them into one large mesh of vertices. For computers in the 90’s, this was a level format that was easy to render without killing frame rate.

The Quake level design tools allow the user to create, reshape, change size, change textures of all brushes in a map. However, as we’ve seen with these old 90’s games, the brush-based system of level making results in very….chunky world aesthetics. There are ways to generate ‘realistic’ terrain with this brush method, but it results in map files that take several minutes or hours to compile. For battleMETAL a work around was found, by treating the terrain mesh as 3d model like any other 3d model, the game now had a way for realistic terrain. The sacrifice was that this terrain model does not show up in the map editors available, leaving the user to guess where to place other objects on the map. By requiring more accurate terrain models for the game, battleMETAL lost the ability to leverage Quake level makers which is a large trade-off indeed. This next part of the blog series will be just as the subtitle describes; why that (choosing Quake / Darkplaces ) was a bad idea.

battleMETAL - Why Quake / Darkplaces - Part 4 - The Game Loop

...and looping through it
The core of any game is the ‘main loop’. There’s a reason why we developers throw around the word ‘engine’ when talking about games. The best analogy I use is a car engine. The car burns fuel, which moves pistons that turn a camshaft. That camshaft then turns a belt called the ‘timing’ belt. The timing belt is the clock of the car engine. A game engine is very close to this. The base code is setup to run through a series of functions in a specific order, and there’s a ‘timing belt’ that keeps internal time. In Quake that ‘timing belt’ is a variable nicely called time.

Entities, remember those little guys from earlier? also form the only true ‘object’ for the Quake C language. Quake C is a cut-down version of the C language, which is powerful but does not do ‘objects’ very well. Quake C gets around this but ever so slightly. There is only 1 type of entity and all extensions to that entity are given to every entity. What this means is, if there is a custom value, such as ‘weapon type’ for an entity, every entity will now have this variable regardless if it used by that entity. This design paradigm is a blessing and a curse. The blessing is that it means creating customized entities is as simple as just assigning values to the programmer’s desired variables. The curse is that it means the code will bloat-up really fast, leaving hundreds of entities with unused values.

When a player launches a game of Quake, after going through the menu system, and launching into a desired map; the engine creates a list of entities. Almost every object on-screen is an entity. Quake organizes its entities into a list, or more specifically in-code, an array. The wonky aspects begin here. This array of entities has a fixed limit, ie how many total entities the engine can have ever. Original Quake can only handle about 640….Darkplaces however upped this cap to 32,768. Quite an improvement, eh? However there’s still a quirk remaining. The array of entities in Quake is more like a slot-system. Each of those 32,000 places in the array is a slot with a number. When the code wants to create a new entity, it finds the next available slot to place the entity...based on where the slot counter is. It is never a guarantee that the next entity the code creates is right after the current entity the code is on.

This also kinda creates a problem with removing entities. Quake never technically ‘removes’ an entity from the array. Instead, it ‘zeroes out’ the entity’s variables, removing things such as any model assigned to it, and other variables. This is was an intentional design by iD Software. Although there’s a difficulty in determining if any given entity is ‘empty’, it allows the system to ruthlessly clean up ‘unused’ entities to keep system cost down. Darkplaces keeps this paradigm in place, allowing for a fast run through of all the entities in the main array.

Entities can be invoked with the spawn() which returns an entity, usually the code will load this entity into a variable for modification: local entity foo = spawn(). From there, the programmer then must assign the variables they want to go into the entity. If the programmer wants the entity to do something in the future, they would assign a .think() function. A think() function is any code that is executed every time that entity is activated in the entity array. There are several other ‘template’ functions that can be used for various parts of entity behavior. Want to have custom code run when one entity touches another? Give that entity a .touch() function.

A programmercan also create their own child functions for the parent entity, such as entity.thisFunction(). And thanks to the code being C-like; this specific function can be whichever function the coder wants to point to. This allows for neat tricks where a set of entities can have the same function, .thisFunction() but for each entity, the actual function is completely different, like this example:

  Entity A

     .myFunction() = fireWeapon_Type_1()

  Entity B

     .myFunction() = fireWeapon_Type_2()


So when the code calls .myFunction(), if the entity is A, then fireWeapon_Type_1 is called. There’s a bunch of other C language quirks that are leveraged in Quake C, but that’s drilling down into programming language design.
Despite some of the limitations with the programming language, I liked the straightforward approach to the code design. 

I figured I could apply higher level code principles to the Quake C language to get around some of its limitations - a fine example is using the Factory Pattern for entity creation. I don’t need to rewrite the same entity customization when making, say, a missile entity. Instead, I can invoke a makeMissile function that does it all for me. Entity cleanup is a bit trickier, and checking if an entity is truly ‘empty’ or ‘null’ (in code parlance) remains a problem that has to be accounted for. Writing interfaces was sort of out of the question, but I think the entity object in Quake C qualifies as an abstract class which is super helpful.

battleMETAL - Why Quake / Darkplaces - Part 2 - File management / File type loading

Files and their management; kind of important

This post was a bit late, things are getting a little busy around here.

One aspect about game coding that I like to pay attention to is file loading and management. Now this may seem like an obvious thing for any application, but one could be surprised at the variety of management strategies. Some games will hardcode data files to be loaded in a certain order. Other games may keep all their files compiled into the game itself. Quake uses what is called a Virtual File System, it sounds complicated but it boils down to this: When the game Quake runs, it treats its home folder like, say Windows, treats a folder. Quake knows how to dive into folders to get files, create new files. It has a set of file types that it can read and has loose preset folder structure.

Darkplaces really just extends the file types that Quake can load, mostly for modernization, but this also has an impact on other game aspects like graphics. Darkplaces allows for higher resolution images to be used, higher-poly models, and cleaner sound formats. Quake’s organizes these files pretty much for the programmer. Yes a programmer can extend the folder structure to their heart’s content, but that should only really be a last resort. An example of this automatic organization would be loading menu graphics.

/Quake/id1/gfx/

If we break this down, we see that id1 contains all of the game files that Quake needs to run, and that the menu graphics are then packed into the /gfx/ folder. This paradigm is also used for models with the /progs/ folder. An interesting note about the /id1/ folder, this is just for Quake’s game files. Modders wanting to make their own games and mods, can easily make their own separate folder such as /battleMETAL/ and then Quake / Darkplaces can switch between the two folders during runtime. This allows users to seamlessly switch between their favorite mods without too much interruption of gameplay. The caveat for my game, battleMETAL, however is that it's a total conversion which precludes compatibility between Quake’s settings and battleMETAL’s. So for my game, I stash everything in the id1 folder with the assertion that a user should not try to run both Quake and battleMETAL in the same install.

Why does this stuff matter? It makes management of dozens of game files easier and reduces to the amount of file loading that the programmer has to write themselves. Most game assets for Quake are loaded in the game code through the following functions precache_sound, precache_model, precache_pic. Even better, the textures for models are precached when their parent model object is, thus reducing the number of precache calls. This makes adding new content super easy as well. The built-in file loading code of Darkplaces knows how to process any of the files that are added through a precache call.

The final piece of this good feature is, we have all these files, how do we package them nicely for a release? Once again, Quake and Darkplaces have an easy answer. Within the game’s asset folder, Darkplaces can read and open .pk3 files. ‘Pak’ files are just a .zip file that has been renamed. This allows the developer to keep the release version of the asset folder clean. By naming pk3 files in successive numbers - PAK0.pk3, PAK1.pk3, the developer can actually split up game assets. Now, why would anyone want this? Think about it this way, if the developer splits game models into PAK1 and sound effects into PAK2, the developer can then patch the models by simply releasing a ‘new’ version of PAK1 with the new models. This siloing of resources is incredibly handy.

In conclusion, Quake / Darkplaces file-folder system implementation is clean and performant. It is useful at-scale, during development and is savvy in its organization for release. This is a strong reason to use Darkplaces as a game engine for simpler game making.

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

The Rundown

Got the first post out of the way, on to more concrete things and perhaps a posting schedule. I'm thinking of making this sanity check every week or so, on Sundays; seems like a good day for recapping. This second post will outline the blog forecast for the next month or so, detailing what I intend to cover but do note that the random post will still make it's way in here. This Sunday will just be outlining everything first and probably an intermediary post this week to setup the first topic I will cover.


Here's the list:
-Tabletop: ideas, future, games I like, stuff I'm working on
-Video Games: ideas, developing, opinions etc
-Artwork: comic projects, one-offs, stuff I've read
-Creative Process: my approach, cool stuff, misc(?)


It's going to be a more personal blog than most, more opinion and questions rather than something more formal like a news blog (there's already plenty). This is all mainly for record keeping and a bit of public eye; the norm is a blog rather than the small leather-bound journal of past eras. Again this structure will mainly be informal, not every post will conform rigidly to those 4 topics, and posts may fall outside of the months discussion mainly cause I will posting as these thoughts and ideas come around. I will try as time goes on to make sure that the posts themselves are more coherent in their message allowing for an easier read and digestion - nobody likes rants or the dreaded wall of text.
-Subject9x