Q:What sort of programming background/education do you have? Have you taught yourself how to program and make games or learned from a college/university? Which languages/libraries do you use primarily? Do you have any code that you've shared online?
Before I started making games, I had no formal education in programming. I taught myself how to program while I was working on my first game, The Man in the Cape. That was the project I cut my teeth on.
I have a GitHub page that I haven’t updated in a while. Various things I mess around with usually end up there.
Turnover - Progress Report: HUD, Line of Sight, & Minimap
Ever since the release of Turnover’s reveal trailer, I feel pretty invigorated. Work has been productive lately.
HUD & Minimap
After some tester feedback, I have added a minimap to the HUD.
Since level work is hitting the midway point, levels are becoming larger and more complex, so the player might become slightly lost when trying to figure their way around. Adding a minimap is a logical remedy, as it gives the player an idea where they are without revealing the entire floor to them. Since only walls and deco are shown in the minimap, the player can use it as a quick reference. Looking ahead and planning your movement are still a must.
You can also see from the shot above that I’m starting to group HUD elements together. The player can also choose their HUD opacity.
Improved Line of Sight
My play tester complained often about corner problems when a Rent a cop and a Sentinel would square off in a gun battle. I was finally able to reproduce the problem.
Originally, I depended on a higher-resolution (i.e. small tile size) grid map to check for obstacles. The obstacle map was the floor, split into a grid of tiles that indicated whether the tile had an obstacle occupying it. Using Bresenham’s line algorithm, I would check from the enemy’s view to his target. As I plotted the path, if a tile had an obstacle, he didn’t have LoS to his target. Simple, effective, yet problematic.
As you can see here, the Rent a cop and the Sentinel can see each other, thus will fire at each other. But, their bullets are striking the walls. That’s because the bullet collision is less forgiving (point precise) then the tile-based LoS. While the entities can see other, the bullet, on it’s straight path, will collide with the wall.
To remedy this problem, I have rewritten my Line of Sight code, moving away from the grid-based system to its own raycast routine. Now, the enemy will cast a line to its target, checking intersection with obstacles entities (broken into wall segments). This allows a much finer resolution of sight checking.
This LoS has a negligible increase in CPU time, but I gain far more accuracy and a reduction of memory usage, since I don’t have to store a LoS grid anymore.
Level work continues. The HUD is now draft-quality and no longer a work in progress. Some other neat things are currently a work in progress and hopefully I’ll get to show those off soon.
Turnover - Reveal Trailer
Took some time away from development to craft a trailer for Turnover that reveals some of the storyline and gameplay mechanics. This trailer cobbles together some pieces of the first fourth of the game. I’m pretty excited to show off a little bit of the work I have been doing.
Ok, time for a little technical stuff I’ve accomplished lately, since it’s been a while. Maybe I won’t feel so guilty about not getting down and dirty on this devblog.
I rewrote my sprite drawing pipeline. Right now, the engine outputs 2 “RenderTargets” during drawing operations.
The first is the game-space target, which is the cumulative of the entire ticked and drawn scene. The second is any overlay information, like the HUD and text. Keeping them separate allows me to apply a full-scene shader in the scene without it effecting the HUD or text elements.
One of my big motivators when it came to rewriting the drawing was my old method, which was “spill it all to the screen”. It had a lot of problems rendering correctly in Linux. It was one of my earliest written pieces of my engine, so finishing that off was a huge relief.
If you compare the trailer footage with an earlier screenshot, you can see the new look is a tad more filtered. Filtering the target resolved some scaling issues I had when marrying the game view with the rendered output.
So, Turnover’s engine has three discreet visual components:
* The game view - a hard coded camera. It sets what can be seen in a scene (I’m a poet and I didn’t even know it), as well as dictating what sprites in the world are immediately drawn or culled.
* The RenderTarger resolution, which will be exposed to the player as a “quality setting”. An old laptop plays Turnover just fine at optimal quality (1920x1080 target), so it’s there for really old systems.
* The window size, called display resolution.
Splitting all three up and keeping them independent gives me far more flexibility when it comes to applying shaders, tweaking GPU usage, and controlling sprite drawing.
Work continues in earnest. The engine is pretty much done and I now have the mood, story, flow, characters, et. al. established. I have an internal schedule that I’m going to do my damned best to stick to. Publically, I’ll say Turnover will be out “when it’s done”, but I feel confident it will see a beta in 2014.
Turnover - Progress Report: The Quarter Mark (& Linux Build)
I’ll take an opportunity this week to go over two things: what I have completed this past couple of weeks and where Turnover stands on the whole.
The majority of work that I have done recently is to make what I have completed so far feels like a mini-version of what Turnover will ultimately be. It feels important to me to make sure I get an idea of what the final product is going to be like. I’m making sure that I have a grounded style and gameplay snapshot that I can rely on as I continue on.
I’ve been adding some niceties and effects to entities to give them a little more life. The spotting and hearing icons for the Sentinels are now animated decals instead of static sprites.
Turnover is now successfully compiling and running just fine in Debian 7. So, Turnover will have a Windows and Linux binary upon release. I plan on doing some more testing in a couple other popular distros before release.
As a Whole
If I had to take a guess where Turnover stands right now in the cycle of development, I think it is hitting the 25% completion mark.
Here’s a rough breakdown of where things are:
- About a quarter of the levels are gameplay tested and gameplay complete. Of those levels, the majority are decorated.
- Art is ongoing, with more to be completed as level work progresses. Can’t really put a number or statistic on that one!
- The game engine is nearly feature complete, subsystem wise. Work continues on new enemies and their underlying gameplay factors.
- The HUD is roughly completed, to be revisited at a later date.
- The objective system is nearing completion. Objectives will be implemented later.
- No UI work is completed as of now. I will begin brainstorming that soon.
- The skeleton of the saving/loading system is complete.
- Linux build is up and running under Debian 7.
Everything is going great! Sometime during Spring, I’ll likely put together a feature video on how the game plays. Can’t wait to see what others think about it.
Turnover - Progress Report: Forward Momentum
Time for another update on Turnover.
Decorating & Art
I’ve been spending some time decorating the “finished” levels. A good amount of time is being spent creating new sprites to put into the world. I began Turnover having no experience with art, and I think I’m at a level now where things are looking pretty decent.
So far, I’m have 11 worlds started and 8 decorated decently. Now that I have been tighten up and locking down the finished versions of enemies, the pace of level work should start picking up. I’ve learned that I handle development better if I work on level in chunks of 2 or 3. If I get too far behind on decorating and game idea experimentation, I spend too much time playing catch up when I’m ready to move forward. Lesson learned.
In the game world, I’ve been putting in little additions here and there to aid the player and give the whole thing some visual cohesion.
Each Security System object now has a color coded glow to help the player know what Security Server controls what Security Subsystem. The game could be a little confusing trying to figure out what controls what, so this should help out.
Patrolling enemies also all have indicators to let the player know if they were heard or spotted, and whether or not a recruited NPC needs to stay alive to complete a floor escape.
Although the engine for Turnover is fairly complete, I find myself going back and refactoring code. In the heat of coding, I’m focused on just getting things working so I can move on to another task. So, when I go back and rewrite things, it will be to enforce a “best practice” or to correct something I overlooked. Optimization will come last, so I’m not worrying about that at this stage.
For example, my code relies on smart pointers to help with memory management. I use shared_ptrs since I need to assign around important object subsystems or pooled entities. Recently, I caught myself using shared_ptrs when passing them around in situations where I wasn’t assigning them. So, I ended up rewriting those instances to use raw pointers with .get() to avoid the internal reference count on a new copy/destroy. I want to be a better coder, so If I catch myself screwing up, I like to fix it and get in the habit of using the better code.
- Playing catch up on level work. 3 levels to decorate and a few more enemy experiments to finalize before I can continue level work.
- No more optimizing until there it is time to optimize, or a game breaker rears its ugly head,
- Been making steps towards getting a Linux build up and running. Still a decent amount of work to do on that front.
Turnover Update - Snipers, Shaders, and Stuff
The past couple weeks of development have been very fruitful for Turnover.
Turnover now has a new enemy called the Sniper. Snipers camp out areas and snipe at the player. The Snipers will likely get the most work out in open areas, where they can keep the player restless.
The Sniper might get more abilities as time goes on, so I’ll have to wait and see how things pan out.
Shader-altered pause screen background. (Pause screen here is a placeholder)
I’ve also begun using some fragment shaders to enhance the look of certain parts of the game. I used one on the windows to give them a bloomy, fuzzed out look and used another to give bullets a little motion blur. I’m still exploring the best places to use them without overdoing it.
So far, I made sure that the GLSL shaders were v110 compliant, giving Turnover a graphics requirement of OpenGL 2.0.
I redid the game HUD, consolidating icons down and making sure that it scales properly across a wide range of resolutions. One thing I did is completely removed the stamina bar and integrated it into the “stamina guy” icon itself. It felt redundant to have two indicators for stamina.
Regarding resolutions, the minimum resolution I can support before HUD elements start to become problematic is 720x480, so that will likely be the bare minimum. Tested up to 1080 works great. Even funky resolutions should be supported without any problems.
Next, I’ll be spending time planning and creating some more floors to help move development along. I’m still waiting for the feedback on the last 11 floors. Once I get that from my tester, I’ll revise and decorate those so I can start finishing those up.
All in all, things are humming along. I’ve finally busted some long standing bugs (the pathfinder being the biggest), so I’ll move onto the rest of the main offenders (Intel on-board, I’m looking at you). Once those are resolved, I can leave the engine alone until performance tuning.
I still don’t have a release plan set in stone for Turnover yet. I would really like to have the game enter the alpha stage sometime before summer. Spring is rapidly approaching and things have plenty of forward momentum, so I’m optimistic.
The Man in the Cape is now free.
I’ve put out The Man in the Cape as a free download. You can also optionally “purchase” a copy for $2.49 if you are feeling generous.
Creating a game from scratch had always been a dream for me. It was something I had always wanted to do since I was a little kid. As a kicker, I had always wanted to learn how to program. When I was young, I would play around with QBasic alot, and I think that may have planted a seed. Admittedly, I never had much patience in my youth, so the idea that I could create something as complex as a game was a complete pipe dream.
Fast forward to 2011. I’m a bit older and far more patient. Seeing as I always have some sort of DIY/creative project going on in my life, I came to the conclusion that if I wanted to make a game, I would have to just go for it. From 2011 until 2012, I made The Man in the Cape, teaching myself C++ as I went along.
The time I spent working on the game was equally joyful and horrifying. I don’t think I had the slightest idea of what was required to learn programming. Educationally, I have a decent foundation, but I wasn’t very prepared. So, I ended up spending many long nights overworking myself, reading books and learning the craft. But, when a piece of programming was finished and working, I felt a great sense of accomplishment that would propel me forward.
From development to release, working on The Man in the Cape has been an immense learning experience almost unlike anything else I have taken on in my life.
On release, the game sold a some copies and got a tiny bit of attention. For someone’s first game (that maybe has the quality level of a person’s first game), it was more than I could have asked for. So now, I’m putting it out as a free download.
The finished product is now one or two years removed from where I am now as a developer, so it feels less precious to me. Now, I just want people to have a chance to screw around with it. So, give it a whirl!
Turnover Update - Programming and NPC Work
I finally fixed a really stupid issue with my pathfinder. I was reading Amit’s excellent path finding article when I noticed that specific heuristics are best used in specific situations. I realized I was using a non-diagonal weighted heuristic against weighted diagonal movement tiles. So, I made them all jibe and 90% of my funky path results are now fixed.
I spent a little time smoothing out the NPCs, making sure their bullets hurt only bad guys, making a HUD indicator to note when you are being followed, and other various things.
Trying to get a Security Guard that is following me to be judicious with his weapon has been really fun. The Security Guards that you can beckon have a tighter line of vision than enemies, so you have to be smart about directing them. This means a head-on fight will 99.9% of the time result in the bad guys winning. So, the Security Guard needs to flank and ambush to be used effectively. I can definitely see super careful players clearing out entire floors if they can find a Security Guard.
I’ve completed 2 more floor (level) skeletons, bringing the total floor count to 10. Those have now been sent out for gameplay testing. The magic number I’m shooting for is 50 floors of gameplay, so I’m making slow but steady progress on that front.
I’ll finish up this post with some animated GIFs!
Clea hides from patrolling Sentinels. She waits patiently for her chance to slip past.
Clea alerts a Sentinel and gets mauled by an Attack Dog. Goes to show that running is not an effective strategy.
Clea is spotted by a Security Camera, alerting nearby Sentinels.
Turnover Update - A Little Help From Your Friends
This past week I have introduced a new gameplay scenario to Turnover — enlisting help from co-workers.
On some floors, you will need to enlist the help of your coworkers to continue on. I’m trying to keep interactions between these NPCs fairly simple, so it doesn’t feel like you are just babysitting an NPC.
The IT worker, for example, can help you activate locked servers on a floor. So you will need to find them and quietly usher them past Sentinels and other enemies so they can unlock the server for you so you can proceed.
Another co-worker you might run into is a Security Officer. This officer will risk life and limb to help you escape. Armed with a pistol, he will help you blast your way through enemies. He can be very useful if you find yourself outnumbered or need someone to take care of a bad guy.
Outside of the introduction of NPCs, level work pushes forward. I’ve completed the skeleton of 3 more floors and I continue to plan more. I still need to implement some new enemies, but that will come with time. Down the road, I’d also like to take another pass at all of the art to improve upon it.
I’ve been spending the majority of my time lately on the “game design” aspect of Turnover. I haven’t been doing much coding, which is fine because I’ll need to do a heck of a lot more down the road when I start work on cutscenes and other logic work. I anticipate that work from here on out will be slow and steady, with occasional bursts of creative energy.
Also, I’ve decided to not make another video until I have a nice chunk of the game completed. Maybe I’ll put another one together when I hit the halfway point.
Back to Business, Sort of.
For the holidays, I’ve been on a hiatus from work on Turnover. I needed a chance to step away and regain my focus on where I should take the game. The only thing I allowed myself to do over the last couple of weeks is brainstorm. I sketched up a number of world ideas and worked on some enemy ideas. I think I have a decent grasp on what is to come, but I have to be sure I allow myself some freedom to experiment and, if I’m lucky, catch some lightning in a bottle.
And now that I am returning back to development, it seems my time to do so is going to be restricted, because of things in my private life. I’ll still do my best to put out weekly/bi-weekly updates detailing what I have accomplished.
So, what’s next? More wordy blog posts for sure. Aside from that, I’ll press forward with creating more floors for Clea’s escape. I’ll probably work on 6 - 8 floor chunks and reevaluate the game at the end of each chunk. There are some gameplay mixups to throw in to keep everything interesting as well.
So, back to work.