So this week is the last week of features for the Pre-alpha epic of dev for Charge. I've been working hard to make sure that the build is relatively stable, and in good enough shape for me to send some builds off to a few friends and walk through a game with them.
The few features I added were all quality of life ones, minus a fun little set of camera pans as a kickoff for the deployment phase of the game. One thing that's come to light working on this is how much more of a traditional program Charge is vs my previous titles. It also highlights how green I am when it comes to code architecture and performance. Last week's blog post goes into that in detail, but the long and short of it is that I'm not a great programmer. (thats ok, it's just something that hit me again this week)
As for bugs, well at this point in the proceedings there's a lot of little ones, but first a story: A couple years back I was working in a digital agency making educational games for kids. We playtested one game at a high school, but against the youngest cohort of kids there. At the end of the session we did a little Q&A where the kids got to ask me questions about game development. One kid, probably about twelve years old asked "What are bugs and why do developers put them into games", I stifled laughing because it was such an honest and great question. In case you're also curious: the short answer is that a bug is a mistake that isn't fixed before sending the build out to players.
The longer answer is that at least for me, they're issues that more often incorrect assumptions about how some code should work with the rest of the codebase than a mistyped variable. For example, there was one bug I fixed this week where when ordering a leader to move, they'd turn around to some random direction, rather than facing towards their destination. Under the hood I've got a little invisible GameObject that looks directly at their destination, and sits at their position that only exists when ordering leaders around (as they're the only unit that can pivot and move in one go). This worked a charm, no issues. About a month after implementing that I added a function to show a direction indicator on the standard unit movement indicator. Turns out when I added that indicator I accidentally removed the positional code for the lookat object. Making units copy the rotation from the lookat object that was sitting in a completely different spot in the world. Most bugs are dumb like this, and usually relatively easy to fix (at least... on my scale of game)
There were a couple other things that made a difference this week. Adding sound effects is always a great boost to the "finishedness" of a game, and I wanted a couple of those in before shipping out to any players. Nothing too crazy, but I did some foley for button clicks, and some freesound mixing for units. Also put in a rudimentary music track for the game that's all warhorns and drums. The second ever piece of music I've ever written and placed into a game!
One other thing worth chatting about this week is.. well another prototype. I actually started it last week, but it's in a better state now. I'm not sure if this'll go anywhere, but I've gotten very excited about it. For now it's called Exoloper, an incredibly dumb take on Interloper, but I just love it too much. Imagine Interloper, but make it a 'mech game in the vein of the Mechwarrior series, more of a simulator than an action game, but more accessible than the aforementioned series.
Also how freaking cool is camerashake?
(07/04/2023)
(06/04/2023)
(05/04/2023)
(04/04/2023)
(03/04/2023)