Wednesday, May 30, 2018
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.
Monday, May 21, 2018
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:
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.
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.
Monday, May 14, 2018
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.
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.
Wednesday, May 9, 2018
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
Why Quake / Darkplaces
Why that was a bad idea, a terrible idea
And Yet, somehow, it works
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
Subscribe to:
Posts (Atom)