After a couple of evenings over the last couple days, I got skid marks working fairly well. I had considered it a fluff component, but I also knew in my gut that skid marks could fairly easily show the player where a vehicle came from and whether it is under control or not.
Generating mesh polygons on the fly in Unity was a new experience, but it wasn’t so bad. The odd thing is that I spent an unnecessary amount of time trolling the docs and forums for info on supporting quads, and whether I’d have to define things in strips and fans and all that. Instead Unity just asked for every triangle defined individually, and shared edges were not even an option. I guess it’s been a long time since I had to deal with individual polygons, and the graphics layer has become just that much more sophisticated. Does that make me a 90’s Voodoo/TNT relic?
Besides, I’m dealing with maybe 50-100 polygons here, so I’m hardly taxing the system…
As I am gainfully employed, my time working on AutoFire is mostly relegated to mornings before work plus weekends. I don’t have any pretty pictures for you from this past week because I’ve been ripping out the guts of the game, getting it into a smoother-running and more manageable shape.
In programming there is a phenomenon commonly referred to as “technical debt”. In short, it means if you take shortcuts and the “easy way” for quick results, you usually pay the price down the road. Those temporary fixes and band-aids that you applied in lieu of carefully planning and documenting your work gets built upon again and again… Eventually that foundation of toothpicks and dried spit can’t bear the weight, and you realize that your work cannot be maintained. You throw up your hands and say “This has to be completely redone!” This is the day your technical debt comes due.
In game development technical debt is common… Early in a project you want to prototype all the gameplay quickly to give everyone a sense of how something works. You try things, you iterate on an idea to make it better, you try to “fail quickly”… You do all those things that the best game companies hold up as their credo, which means you have to focus on speed and agility. Try that crazy new control scheme, add a strategy component to your FPS, see what all the goats look like with hats, or whatever the team comes up with. This behavior does not encourage proper architecture, and often involves what a programmer calls “a hack”.
BUUUUUT game making also is a business, and there is always pressure to move forward because the last problem is in the rear-view mirror… This comes from folks like producers and publishers, but isn’t just about the folks in ties and suits: a lot of people on the team can get antsy if they don’t see new things on a weekly basis, because morale is everything in a creative endeavor. Programmers get tremendous pressure to move on to the next big issue, and frequently they will warn the powers that be of the technical debt that is being accrued.
Of course, when the day comes that the debt must be paid off, it will involve days and days (sometimes weeks!) of time when nothing changes… in fact, the goal of this cleanup is that everything should work identically as when you started. It’s very hard for an outsider to understand… One day long ago I witnessed a manager straight-up ask “But can’t you just hack the entire game?” No… not if you want something that won’t fall apart when thousands of eyeballs and eager mouse clicks are set upon it.
Nonetheless, “hack the entire game” is precisely what the 7DRL is about… You need results now and you don’t apologize for it later. You’ve got 168 hours to get to the finish line and you don’t care if you trample over every “Write Smarter Code” author who ever was. And I certainly did that.
For AutoFire my control and world update system was my cross to bear… I piled my inputs and the control of my entities in Unity’s “Update” system, where each object gets called every frame. I cobbled together some bullshit traffic-cop system to move things in the right order, except Unity plays it pretty fast and loose… There isn’t really a great way to guarantee that, say, the function that tells a car where to go would run before the function that actually moves it. Frankly, I started to not fully understand how the damn thing worked at all.
I knew the debt was coming due… Players didn’t always feel their commands were registered. 10% of the time the smooth movement of an entity would inexplicably twitch. The enemy vehicles just spontaneously stopped working. But I knew fixing it would be a slog, which is why I procrastinated by working on some pretty terrain last weekend instead of doing what I should have been doing.
When you have to rewrite someone else’s code, you can get pretty grumpy about that person. But when you have to rewrite your own code, you decide that months-ago you was either an idiot or a complete dick. “What was I thinking?” gets uttered out loud several times, as well as “What the crap is this?” and the classic “How the hell did this ever work?!?”
But a week later and all is well. The code to control everything is about 25% of its original size. Everything is carefully managed. Your input is now queued up and doled out to your vehicle on demand. Now I can get back to the fun part of making things blow up.
More progress is being made on the terrain front. Lately I’ve been battling Unity’s terrain and placing detail objects. Their system wasn’t particularly well-documented but I’m finally wrasslin’ it into shape.
So the tile system that I use for indoors is still under there, influencing the heightmapped terrain… The tile type defines what terrain layer(s) I use, which then I apply with some smoothing and variation. The smaller details like grass and little rocks use Unity’s detail system, which is applied with a density indicated by the tile type as well. Finally, the larger objects like trees and large rocks are actually the tiles I use for cities, but without a floor component. These I can spawn and despawn as they come into view, as well as modify due to explosions and so on.
So I’m committed now… Auto Fire is a game I plan to go all the way on. For starters, it’s “Auto Fire”, not Autofire. You can find the home of the full game (as opposed to the 7DRL version) here.
I’ve been getting enthusiastic, putting regular work in Auto Fire on nights and weekends, and missed plum opportunities for blog posts. So much I could have talked about!
I took some time to convert the entire game to Isometric 3D and putting in entirely new world assets.
I’ve also completed phase 1 of getting in enemy AI cars to battle.
Then, after some urging by my friend Jim (Dungeonmans) Shepard, I cleaned up my code and started to get things rigged up to cross between multiple maps. Then I put some effort into learning more about Voronoi regions and Perlin noise to generate a basic overmap. It’s not gorgeous yet but I’m pretty excited about adding some more structure to the experience.
After that, I’m headed back into combat-land and working on both revising the input scheme and improving combat with enemy vehicles.
Stay tuned for more updates and when I might be able to wrangle my next release to you folks!
I hate that when you fail to move forward a square you ram things and take damage. So, I improved the vehicle motion when ramming or colliding with a wall. I also fixed some issues with trying to ram things diagonally… that was irritating. Finally you could previously take a lot of damage when ramming something inconsequential, but now you cannot take more damage than it takes to kill the opponent (and in the current configuration you only take half that damage… this will ultimately be adjustable based on your equipment).
As usual, check out the AutoFire page for the update.
It’s been a little under a week since the conclusion of the 7DRL and I’ve been excited that people have been pretty receptive to my entry, AutoFire. I had a lot of fun making it and people seem to be having fun with it too:
In the past week I’ve gotten some good feedback, some of which I’ve been able to act on. The first bit is that folks are excited about drifting and controlled skids in the game, and I realized that by allowing players to drop below zero grip (into the red) is really punishing… It’s very hard to regain traction without crashing. I updated the game to not allow the grip to drop below zero, so a moment of control will allow players to get control back… This makes it a little more about deliberately losing control and then regaining, Ridge Racer style. This is something I want to continuously refine, and supplement with skid marks and other speed feedback.
I also added a “preview” in the grip meter of how much grip you’d lose if you do a maneuver at that moment. It’s difficult to figure out the right type of feedback for a keyboard-driven game like a Roguelike. I wanted to keep the “one input, one turn advances” feel of a typical Roguelike, so it’s hard to give much information about what your next action will result in (without mouseover or two-step advancement) .
People also still have a little difficulty understanding the four weapon mounts and their individual cooldowns. I added a bit of information about the weapon that would be fired when showing a viable target. I will probably also show a prediction of the damage to be done and more on-map indications of the weapon to be fired… perhaps a change in the crosshair or displaying the weapon sprite.
Some others suggested that the game was too easy, which I won’t deny. I was pretty stingy with the drops early in development, but for the 7DRL release I worried that all the work on weapon upgrades I did wouldn’t be noticed, so it ended up pretty generous. The goal eventually is to create situations where you have to drive fast to get the extra attacks and stay alive, so it’s definitely a goal to balance things better. Once I get enemies obeying line-of-sight (haha) and reduce their hit chance firing at a high-speed target you’ll have more tools at your disposal and I can crank up the difficulty.
Some additional things to come:
World tiles that aren’t cobbled together from a number of sprite libraries (they were so damn ugly)
Competent world generation that feels like a place to drive.
Loot improvements such as armor patches that must be mounted on a single side, improved tires (grip) and improved engines (speed).
Enemy vehicles (At last! This was a painful cut for 7DRL but I ran out of time)
Not to mention an actual adventuring environment with areas to advance through, assassination contracts, vehicle gangs, and so on. So much to do!
Welp, the 7-Day Roguelike Challenge ended in a photo finish… Not only was I putting in stuff up to the very end, but I uploaded a build to my website and not a minute later I hear an EXPLOSION outside and the power goes out. There’s a transformer out on one side of us and a power line down in the other, so no more power today.
Luckily I have a nerd-huge phone and managed to use it to update my website and finish my entry into the challenge’s website. A few minutes later and all the hard work this week would have ended in a major disappointment. Instead I’m pretty happy with the results!
For 2016 I wanted to stray from the comfortable gameplay I did for my inaugural 7DRL with Huge. There were some systems for turn-based car combat that I’ve been tossing around for a while… But applied to the Roguelike mold.
Day 5 of the 7-Day Roguelike Challenge has completed now and I’ve finally got smooth vehicle movement in my Auto RL. I put some time into an improved UI that hopefully starts to convey the concept of “you get more actions when you go fast”. With this is the implementation of Grip, which drains from manuevers at high speeds so you can lose control It has hints of greatness but is hard to deliver satisfyingly on a grid in 7 days.
My remaining work on weapon pickups and types, some improved world generation and a weapon pickup inventory, and hopefully an opponent you’re stalking (I’m starting to regret throwing out my boss code from last year!)
Since I don’t have time for you to get out of the car and salvage, you just run over the equipment and I’ll prompt you to choose which of the four weapons you want to replace (or discard it).
My one regret is spending as much time as I did on the basic sprites on Sunday. Last year I was reasonably good about keeping the scale of Oryx’s sprites so that 24×24 was a standard tile, but this year I had to bring in graphics from a number of sources that varied from 16×16 to a car I found that was some weird rez like 56×108. Plus, I reduced the size of Oryx’s character sprites which implies a resolution of 32×32. In a way it probably would have been better in this case to stay representational and not cobble together a vague swipe at pretty, but it inspires me to work in an environment with visual flavor.
Check it out below… I apologize for the atrocious 20-minute sound hookup. 2 days left, wish me luck!