Well, I actually hadn't intended to start a development log, mostly because I felt like development is going so slowly (but steadily and awesome) that I wouldn't have much of anything interesting that I could update the thread with from day to day.

But then, I encountered... the most bizarre bug I've ever seen.

I figured I'd come on here (I love you guys) and complain/brain-dump about it, and -- what the hell -- use it as a jumping-off point for a devlog.

The game is called Acronia. It's a run-'n'-gun platformer. I alternately go back and forth between describing it as "you know, just like Contra!" to, "It's like if you took Rise of the Triad or Doom and made them a sidescroller." 2D action, emphasis on violence, an unscrupulous military contractor genetically engineering killer mutants that get loose and wreck everybody's shit... you know, the standard stuff. There are five playable characters, and I'm not yet sure how the player will switch between them. I've narrowed it down to a choice between Super Mario Bros 2-style (choose when you die, or at the beginning of a level), or TMNT-for-NES style (swap out at will). But that's for another post later on in the devlog. :-)

I originally started the project three years ago. After five years of development, I had decided that Adventure in Rulon (my JRPG project) was way out of my scope as a programmer, and shelved it. It's not dead; it's been my pet project for literally 20 years now, so it's not going away any time soon. I just decided that I wasn't the programmer I wanted to be at that stage yet, and that the best thing to do was to work on a simpler project. "Make a platformer," I said.

Yeah. Well. Now it's three years on. But I don't regret anything. Working on this project for the last few years has made me a much better programmer than I ever could have imagined. It has also made me realize that the learning never stops. I am an absolute shit coder compared to what I'll be five years from now... and that's the awesomest thing in the world.

I started the project in FreeBASIC, just like Adventure in Rulon, and I got pretty far. Within a year, I had the basic engine going, including weapons, and had a rudimentary map editor going. But I started to feel like I was hitting a wall. The official FreeBASIC forums were depressingly slow, as was development on the language and compiler. The promised inheritance (and eventually polymorphism) features were slow in coming, and were looking increasingly like they were never going to happen. And of course, FB being such a young, niche language, there were very few good libraries to rely on. So, I made the monumental decision to finally quit stalling and start learning C++.

Turns out I made the switch at exactly the right time. Within a couple of months after I made the switch, C++11 was released into the wild. That was a great opportunity for me, as I was able to learn C++ the right way, rather than relying on years-old tutorials and books written for C++98 and C++03, while everybody else was moving the hell on. The source code to Doom 3 was also released around the same time. It's really not a great example of C++ code (it's more like C with classes), but it's clean and organized as hell, and gave me a solid idea of just what can be done with C++. That and it's just a fun read, if you enjoy having no friends, like I do.

I began porting my FreeBASIC codebase to C++. That involved lots of learning, lots of re-writing, and lots of running into bugs. And it wasn't without its stumbling blocks. Probably the biggest was the fact that, coming from a language that didn't have much in the way of libraries, I suffered from a hideous case of "not invented here" syndrome. I didn't trust the standard library, and re-invented every wheel you could think of. I've since gotten over that delusion, and purged most of the mess that I had left in my wake. I still cringe at smart pointers and prefer to manage memory myself, but overall I've learned to trust the language and the libraries. The game is better for it.

The porting process took about a year, and the ensuing year has been spent improving the engine and developing the editor. Well, that and working at pesky day jobs. I hate those things; they cut into valuable hours that could be better spent not-getting-paid-for-game-development.

TL;DR: A "simple" project, intended to get a game out the door quickly, has turned into a huge behemoth. Natch.

The Bug,
or:
The Day I Went, "What the Fuck?" And Had Literally No Clue How To Un-Fuck the Problem.

A lot of weird things can pop up when you've spent the past year only ever running your game by hitting "Run" from the IDE. You wind up never really testing the game in the same kind of environment that the user will be playing it in. For example, I rarely run the game by clicking a shortcut. Or by directly double-clicking the .exe in Explorer. Or by clicking a pinned Taskbar icon.

Yeeeaaah... the taskbar. Weirdness ensues.

Out of curiosity last night, I decided to move my current build into a separate folder on my computer, isolated from my source code and other development materials, and try running the game the same way a user would. Everything went great. Except when I tried to pin the game to the Taskbar. Oh, it pins, all right. And it runs. But when it runs... I only get audio out of the left speaker. But it's not like the right channel is getting cut out. It actually plays all of the game's audio, in mono, out of the left speaker. I tested it by firing a projectile off to the right, and listening for the impact. If it were only playing the left channel, I wouldn't have heard the impact at all; instead, I heard it perfectly clearly.

This weirdness doesn't happen with any other method of running the game.
Directly from Code::Blocks? Fine.
Double-clicked in Explorer? Fine.
Run from a menu? Fine.
Run from a pinned Taskbar icon? Audio takes a shit.

What makes it even weirder is that it only happens if the program is compiled as a GUI application. If I compile it with a console window... no problem. It's the damnedest thing I've ever seen. (I'm sure I'll see even more-damned things the more experience I get... all in good time, Christopher.)

Here are the specifics:

OS: Windows 7 64-bit
Compiler: MinGW 4.8.1 32-bit
Audio library: SFML 2.1
IDE: Code::Blocks 12.11 (fail to see how the IDE would make a difference, but what the hell)

I know it's not much to go on, but does anybody have any idea why a program would behave differently when launched from a pinned Taskbar icon as opposed to any other method?

I'm stumped. I don't even know how to research the problem. My Google-fu is weak. I'll probably wind up asking about it on the SFML forums, but I thought I'd go ahead and see if you folks might have any ideas I could try out._________________Dev log - Adventure in RulonDev log - Acronia

http://i.imgur.com/0xoVjv3.png
I just blasted a rocket into a bad guy's face. Dynamic lighting and gibs ensue.
...the programmer art, and sprites stolen borrowed from Abuse and Doom, really make this shot, I think. >_>

http://i.imgur.com/OLnkUXr.png
Teleporter ambush? Break out the flamethrower.
Lots of clustered, bright lights really show off the limitations of the tile-based lighting system. It looks way better than this in actual motion.

I just looked at those screenshots on the Mac I use at work. I never before gave much thought to the way my game might look on different monitors. It's actually quite a bit darker than what I see on my monitor at home. Thing is, the lighting effects look a lot better that way.

(Except for the flamethrower. The tiling in the lighting system was obvious enough on my PC; on the iMac at work, it's just insane. Maybe I could stand to turn the intensity down a bit...)

I want to see it in action, man. You can't do justice to a flamethrower with just a picture. :)

Does running an application from the taskbar just basically point to an executable's location, just like a standard desktop shortcut would? I don't know if I've pinned to taskbar in windows before or not. Seems like it would work that way. I wonder if the volume controller thing in the taskbar is somehow interfering. Maybe you could... if you're brave enough, anyway, you could try removing the volume control from your task bar. I'm sure you can put it right back, maybe?

Probably not much help, but that's what little I have as far as theories go._________________The end of the game, yes, is pretty much getting the weapon and killing off the population.mashup games . com | Finally! - A Lode Runner Story

Thanks :) Obviously everything will be original art by the time the game is done. But if I'm going to gank another game's art for placeholders, I might as well use the best! :D_________________Dev log - Adventure in RulonDev log - Acronia

I rewatched the video more than once, and I confirmed that when you first land on the ground, you already have a bad guy lying on the ground. Did you cook him already on a previous visit to the area, or did you kill him at the top and his body ended up falling all the way down there? You know what would be great, you have the elevator that goes down, but the walls are "spiky." You roast some bad guys, and the gale forces of the flamethrower not only barbecue the bad guys, but send them careening down the pit. Unfortunately for them, the pit has all of those spiky edges, so many of their corpses become impaled upon those spikes, some of them remain cooking. It works out really well because it's a dark ride down, all the lights are out, but their burning impaled lifeless bodies offer you a belyingly calm and peaceful candlelight as you descend into the next area, almost like a posthumous apology for their mortal transgressions.

Also, I would love to see special AI for a weapon like the flamethrower. Once you start firing it at the bad guys, one of them could yell, "Oh no! He's got a flamethrower!" Some of them would panic and run away from you in terror, and you would get bonus points if you caught them before they jumped down a spiky pit in order to escape your flamethrower's vengeance.

I don't think I've ever heard of Abuse, on the record. I'll have to do some searching on it._________________The end of the game, yes, is pretty much getting the weapon and killing off the population.mashup games . com | Finally! - A Lode Runner Story

Yeah, the dead baddie was killed on my first trip through. I wouldn't have been able to kill him from where the switch is, because the tile I was standing on is a one-way platform. Solid from the top, pass-through from below.

I love the scenario you propose. It's grisly -- just the way I like it :D It'll take a few features that aren't in the engine yet, but have planned for (a specific "burning" type death... spikes... etc).

Even better, have a vortex weapon that will pull enemies right up to you. Use that, then swap to flamethrower to light them up while chucking them back where they came from. :]_________________loomsoft :]

The vortex gun sounds great! But, there should also be tougher enemies that wear heavy boots, so you can't drag them with the vortex gun. You have to shoot a grenade under their feet to pop them up into the air, at which points their boots aren't useful because they're not standing on anything, allowing you to reel them in for dinner!_________________The end of the game, yes, is pretty much getting the weapon and killing off the population.mashup games . com | Finally! - A Lode Runner Story

Random idea: I'm thinking of making the pistol about half the strength it currently is, but giving it infinite ammo. Currently, the only "fallback" weapons the player has for when he runs out of ammo, are both melee weapons -- the fist and the chainsaw. It'd be cool to have something long-range you can use. But if I do that, it should be relatively weak. A pea shooter.

Rolling Thunder tackled that by making your pistol functional after you run out of ammo, but at a greatly reduced firing rate. If you had ammo, I think you were limited to 3-4 bullets on screen at once (quite enough given the bullet speed), but if you were out of ammo, only one shot at a time._________________NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)

It's not often I get an entire feature implemented in a single (4-hour) night. I did that last night. The player can now grab onto ledges and haul herself up, a la Prince of Persia.

The implementation is really rather simple. The game doesn't bother to interpolate the player's position along the ledge while climbing. When the player grabs a ledge, I halt their movement and fix their position against the wall for as long as they're hanging. When the player presses the appropriate action key, the "climbing" animation will play, giving the illusion of climbing up the ledge. When the animation is complete, I simply snap the player into the new position atop the ledge. It's pretty seamless.

While hanging and climbing, the player is invulnerable. There are two reasons for that: one, making the player hittable while climbing would expose the fact that her visual location and her actual location aren't the same. Two, while climbing, the player is basically a sitting (hanging?) duck. I like challenging games, but that would just be unfair.

Interesting videos! :) If I saw that correctly, you position the camera according to the platform the player is (/was last) on, is that right? Because when you turned on fly-mode, the camera stopped moving until you hit a platform again.

How is that camera working out for you? I also considered doing it like that but then didn't because I wanted more flexibility.

The grabbing and pulling up is looking solid, I hope you can get away with making the player invincible during this time. :)_________________My current project: Hook'd