Anthony's Development Blog

Developer of Turnover and The Man in the Cape. I'm currently working on a new title. Long Division LLC / Twitter

[anthonydev]

Gamedev Progress Report: 01/29/2018

A new year, a new devlog post. Just something quick.

..::The New Game::..

Screen Templates

I’ve begun adding some template screens so the game can be navigated. I’ve completed templates for the main menu, options, binds, game over, and pause. They still need to be stylized, which will be taken care of in the future. The real fun will be implementing the final main game HUD and the pause/inventory screen. They are more complex and will be tougher for me to block out.

As you can see, there are also HUD key/controller hints implemented.

Engine Progress

I’ve added a Borderless window mode to the new game, much like Turnover has right now. I also spent a good amount of time ensuring 16:9, 16:10, and 21:9 resolutions have proper screen scaling and support.

The new game now makes greater use of vertex buffers for rendering most everything (like Turnover now as well). This gave the game a good speedup and should go towards improving performance for lower end systems.

Completed a lot of back-end usability stuff, just to make development go a little smoother and quicker. This included how levels are made/loaded.

A lot of optimizations and fixes. A lot of refactoring to ensure stability.

Game Progress

The core of the game design, which includes the weapon system, gameplay, and objectives are now established and planned. Now, just to get them done...

A full prototype of the player’s weapon setup is complete and in-game. Refinement is on-going.

Completed draft versions of a few new enemies, as well as a couple more minibosses.

Roughly 60% of the game world is “draft complete”, including art. Still, much work to go.

Current work is focused on newly planned gameplay elements. Once I have a few successful tests of those, then back to level work.

So the major sections of the game to get draft ready are as follows: “objective sections”, the game world, and the minibosses. Once those are drafted, I can then link them together and have the first full playthrough of the game. A pre-alpha, that’s what I’m working towards currently.

Depending how much I have “show off ready”, I think Summer might be a good time to reveal the game and the concept behind it. We’ll see as it gets a little closer.

Recent GIFs

Some test minibosses in a test room.

..::Turnover::..

Turnover has recently been updated. The new build brings some nice improvements.

SFML has incorporated vertex buffer support into their library. I’ve rewritten Turnover to accommodate them. This should give a nice performance bump, particularly to anyone with a lower end GPU.

I added a separate option for music and sound volume, instead of one master volume.

I knocked out a few 21:9 scaling issues in the menus. Some text was too large and positioning was out of whack. It wasn’t game breaking, just a little annoying.

A handful of fixes to general issues I’ve run into while testing out the recent changes.

Also, Turnover is now available for a new, lower price of $4.99 USD.

[anthonydev]

Taking a punch.

[anthonydev]

Jump around.

[anthonydev]

Gamedev Progress Report: 10/23/2017

Now that I have multiple projects going at the same time, I’ll blog about all of them at once in my progress reports. Seems like a good way keep what I’ve been working on together in one post.

> The Man in the Cape

The Man in the Cape: Special Edition is now live on Steam. I’ll be keeping an eye on feedback and will do my best to continue promoting the game via social media and other channels.

I’ve joked with others that I consider The Man in the Cape to be in my “budget series” of games. It’s very reasonably priced for what you can get out of it. I’m happy to have it live next to Turnover among my released titles.

> Turnover

I recently pushed an update to Turnover to address an issue a player was having.

The player was running the game in a multi-monitor setup and the normal full screen mode of the game was having display issues. I used to run a multi monitor setup years ago and had encountered similar issues in other games. I found that running a game in a borderless full screen mode often fixed many problems, so I implemented a borderless full screen mode for Turnover.

If you run a multi-monitor setup and/or need quick alt-tabbing while gaming, I recommend that you give the borderless fulls creen mode a shot.

> New Game

Been a few months since I posted about my new game, so it’s time for an update.

Progress

Since I was focusing on The Man in the Cape in September/Early October, the new game spent a little time on the backburner. I think this was for the best, because it gave me some breathing room to experiment on some new things, as well as evaluate the entire project and decide how to progress.

Initially, this new game was planned as two games in one (each with distinct gameplay). After some careful consideration, I have decided to nix “the second game”.  I never really connected with the second part of the game and I also feel like what I was doing was a little too ambitious for me, personally. It was a neat concept, but worth axing.

The current plan is to build upon the “first game” and make that the game. I have some ideas on how to build it out and keep it interesting. As always, a ton of work and experimentation lies ahead.

GIFS

Been posting some GIFs of the new game. These are all a work in progress and may change, even significantly, before I reveal the game.

These are all in-game GIFs and should give a decent idea of what the style will end up being. I’ll continue to post some new ones every few weeks leading up to whenever I feel the game is ready to announce.

Progress

So, what has been going on over the last few months?

Decorated a large number of levels. Basically, been using them as a sandbox to experiment with art, mechanics, etc.

Prototyped a few new enemies. Still need to create the draft art for some.

Prototyped a new miniboss. Needs a lot of work.

Began experimenting on how menu interaction will look/feel.

Added some more player animations.

Shored up a lot of the platforming mechanics. Platforming that “feels right” is really important going forward.

Brainstormed more gameplay elements/setups. These should be a lot of fun to implement. (That’s half sarcasm).

“Completed” another section of the game.Roughly 50% of the main, explorable area of the game is now at least “draft complete”.

[anthonydev]

The Man in the Cape: Special Edition is out now!

[anthonydev]

Win a Steam Key! Support the Thunderclap!

Support The Man in the Cape's Thunderclap for a chance to win a Steam key!

[anthonydev]

Fighting off hordes of NanoBugs in The Man in the Cape: Special Edition. Coming Oct. 17th. http://store.steampowered.com/app/706480/The_Man_in_the_Cape_Special_Edition/

[anthonydev]

Slicing up eyeballs.

[anthonydev]

The Man in the Cape: Special Edition is Coming Soon!

The Man in the Cape: Special Edition is coming to Steam on October 17th! Since this is a devblog, I can post a little bit of how the game came to be.

Development

When I first got into solo game development, I did it to teach myself how to program and how to create an engine. I decided that I needed a game project to develop these skills. What was started as a few test levels of a twin stick shooter quickly developed into a full game concept.

I conceptualized what this shooter game would be about: a stick figure superhero who would become trapped in superhero elimination dungeon. The art style would be simple enough for me to bang out assets quickly, while creating dungeon rooms would keep in spirit with the SmashTV inspired gameplay concept I had originally created. Full development began sometime in 2010.

Developing the game sort of became an obsession for me. I was at a point in my life where I had nothing going on, and I felt like I needed to create and accomplish something. Years before 2010, I was in game development, then quit out for a few years. I had always loved gamedev, so I felt compelled to pursue that avenue again, for better or for worse.

The Man in the Cape took, more or less, about 2 years to finish and it was released on October 15th, 2012. I sold it independently on a website for a while, but I was inexperienced when it came to getting the word out and handling the release. About 6 months later, I began to develop Turnover, and The Man in the Cape was relegated to a backup disc somewhere. It became like an estranged family member that I no longer mentioned.

Revisiting

Turnover has been out now for almost 2 years, and I have moved onto the development of my next game. A couple of months back, I became a little introspective and felt like delving into some of my game development archives. I had frequently saw the latest build of The Man in the Cape in my backups, but I never allowed myself to give it a thought. A little later, I was looking through my files again and stumbled into the most recent project and development files for The Man in the Cape.

I had looked back negatively on the game. Turnover is a serious game with a serious tone. The Man in the Cape is a weird, surreal, silly game with an odd, lighthearted tone. As I pulled the latest build of Capeman out of my archives, I kind of began to accept the fact that these project all represent facets of my personality. I felt ready to jump in and cringe.

So, I started the executable and had issues. I could run it in Windows XP compatibility mode, but it would crash frequently. I then opened up the old project files and converted them to my newest development environment, updating libraries and recoding things to fix issues from 5 years of library changes. It only took about a day of serious work to get Capeman up and running decently. So, I dove in.

And you know what? I was really having fun and laughing a lot. As I played through Capeman, I started to feel a little guilty that I didn’t gave it the support that I should have. While playing, I really cringe, I was proud of it.

It was 4 or so years since my last playthrough, so I was able to see things with a fresh perspective. Using the experience I gained working on Turnover, I rebalanced the game as I played through it, fixing enemy issues, lifting the difficulty in some rooms, making it a little tougher in others. Also, I added things I felt the game needed to have: better controller support, with XInput support and a default Steam controller template, support for 16:9 resolution above 1080p, and higher frame rate (lifting the cap from 60 to 240). I also spent some time reprogramming the game loop to eliminate a stuttering issue the original version had.

Special Edition

As silly as the game is, I’m proud of The Man in the Cape. It‘s a fun twin stick shooter with a surreal atmosphere and some weird writing. I was happy I reunited with it, and I have accepted it back into my game development family.

The Man in the Cape: Special Edition will be available for a low price upon release. So, check it out!

[anthonydev]

Dashing and slashing.

[anthonydev]

Progress Report: New Game 08/03/2017

Even though I had something in my private life eat up a couple of weeks at the end of July, things seem to be back on track. Overall, June and July have been fruitful months and the new game is making quick progress.

The game, tentatively, will have 5 major world areas, with another group of levels in addition. As of now, I have the layout and draft graphical assets finished for 2 of the 5 world areas. Barring any personal or professional roadblocks, I anticipate I’ll have the draft versions of 2 more areas finished by the end of the year.

Most of the work lately has been on area 2, creating art assets and giving the area life. I’ve added a number of new enemies, and have also started on a new miniboss as well. As I get a bite on the feel and look, work seems to speed on by.

Aside from creating a bunch of background, foreground, enemy, and effects sprites, here are some other things accomplished since the last devblog update.

Draft art for pickups are in. As the weapon system evolves, more pickups will need to be created.

Menu navigation has been improved, just to make testing a little more user friendly.

Added some planned power ups to the game. The functions will evolve over time.

Rewrote how the HUD is rendered, giving a consistent look/experience across resolutions.

Added HUD Hints, so context hints can be sent to the HUD.

Improved collision for platforms that the player can jump down from. Much less “ground snapping” going on.

Balanced a number of enemies regarding movement/projectile speed.

Work on new player weapon and gameplay associated with it.

Added a bind screen so player can set kb/m controller binds.

New room to room transition effect.

Created the volume damage system, to set up environmental damage areas like spikes, acid, etc.

Created a placeable generator class for spawning sprite effects.

Fixed a bug with enemy sprites and their associated hitshapes lining up incorrectly

Better ground collision for a few enemies. This results in their movement looking much cleaner and allows for better platform edge detection.

For the addition levels, I created infinitely scrollable parallax backgrounds. This should reduce the art placement burden, as well as increase performance. I may get a change to write a blog post on how I accomplished this down the road.

Next

The test build of this new area has been handed off to my tester. Work moves onto Area 3, as well as continued game play brainstorming.

[anthonydev]

Steam Summer Sale: Turnover is 75% Off!

For the Steam Summer Sale, Turnover is 75% off!

[anthonydev]

DevBlog: New Game  06/05/2017

Last month, the gameplay composite was sent to my tester and feedback was gathered.

The feedback I received led us to a fruitful discussion on the direction of the game. I think it’s safe to say that I have a solid mental picture of how everything may end up, and I’m pleased with it. Before the composite test, I felt there was a little too much uncertainty regarding the direction of the game. I don’t feel that way anymore.

The feedback session sparked an initiative to lock down the conventions of the game regarding movement, the weapon system, and difficultly. I have begun to set a lot of that in stone. The next demo that gets passed off for testing should be a crucial one, as it should test the potential finality of gameplay systems.

Aside from completing the game composite and its first test session, here’s what I accomplished over the last month:

Wrote the Music Manager so music can be played.

Wrote the Save Manager. The game can now be successfully saved and loaded.

Worked on temporary pause, main menu, and option screens. I set up the code and the interaction, so all I need to do is design the UI.

Fixed some screen HUD/overlay issues, as well as improving scaling for lower resolutions.

Fixed pausing so some effects/projectiles will stop correctly until the game is resumed.

Fixed issues regarding feedback from the composite. This consisted of rebalancing enemies and fixing bugs. This work will be on going after each game test session.

Worked on more draft art and new weapons and other conventions.

Next

My development routine will likely now consist of pulling off two things at once. First, I’ll continue working on new levels, art, and enemies to keep development propelling forward. Second, I’ll continue to refine all of the core gameplay systems using the composite demo. I’ll regularly generate builds to hand off to my tester for feedback.

[anthonydev]

DevBlog: New Game  05/02/2017

Composite

For this new game, I’m approaching development differently than I did for Turnover. 

With Turnover, I just completed work as it came along. I would write systems, only to scrap them later. I would implement changes that would require every level to be edited. I think that was a result of inexperience as a solo dev. Now that I have been through the development cycle of a few solo games, I’ve revamped my workflow. For this new game, I’m experimenting with a composite system.

First, I prototyped the gameplay of the new game and it met my approval. From there, I’ve been developing the prototype out into what I’m calling a game composite. The composite is about 20% of the full game in draft form. I have a few goals in mind:

Establish the core gameplay structure early to avoid major changes later.

Establish the look, theme, tone, and art style early so they can all influence enemy and art designs as the game is built.

Allow early composite testing. I plan to have a short period where the composite is sent for feedback.

With a completed composite, conventions will be fully established and vetted, which will in turn hopefully allow accelerated development of the rest of the game.

One downside is that development seems to be slow at the moment, just because I am attempting to establish and refine so much so early. I hope this pays off down the line with a sped up development cycle.

Right now, I would say that the composite is about 70% complete. There are about 4 or 5 major things I need to knock out. From there, I hand it to my tester for some brainstorming and feedback. Then, I move on to full development. At that point, I should have an idea of whether creating a composite was a good idea at all. We’ll see.

With that said, here’s what I’ve been up to over the last month:

Art/Enemies/Levels

Enemies for the composite are now, more or less, finished. All of their movement and attack routines are in place. Everything is working as it should.

I’ve added a few quality of life things regarding enemies. For example, enemies will now briefly flash before they go into their fire or attack routine. This should help the player time movements so they don’t go jumping into firing enemies.

I’ve been running tests on some boss enemies as well. Need to tie them into greater gameplay, but things are looking good so far.

Composite levels are nearly finished. Things just need to be tied together nicely (level transitions, things like that).

HUD

Spent some time creating the game HUD. It should evolve as things progress, but everything is up and running.

Items

Implemented the item drop system. Enemies drop pickups so the player can regain health/ammo. Got that in.

Draft versions of player upgrades are in, tested, and working.

Next

Still a number of things to knock out before the composite is ready for testing:

Music handler / way to send music events

A basic save manager that can save state

A means in which for the player to save their game (ie a save room)

Various signal sounds (”enemy is invincible to this attack”, etc)

Should be wrapped up this month. Then, onto all the rest.

[anthonydev]

DevBlog: New Game 04/07/2017

Continuing the monthly progress reports.

Effects/Animation

Spent a good amount of time laying the groundwork for sprite effects in the new engine. I added the ability to attach effects to anchors specified within an actor. This allows me to do things like attach muzzle flashes to weapons and have them follow their attachments.

I moved effects that were projectile related over to the sprite effects system. Now things like destructive debris no longer have to worry about collision and things that. Those things were not needed for these type of effects, anyway.

HUD

I set up the HUD back end to load the sprite resources and send update values to the HUD (health, ammo, etc). I have a mock HUD up and running. It works and looks OK. Like everything else, it’ll need refinement down the road.

Sprite Work

This game, as of now, is made up of roughly 5 different world sections. I’m centering my engine world around the very first section of the game. Once everything is looking good and I have established everything, I can quickly move onto the other sections at a (hopefully) accelerated pace.

I’ve been doing a lot of sprite work lately, laying out backgrounds/parallaxes, draft enemies, and the like. A “look” of the game is starting to emerge. The game is going to have a pixel art style. It’ll be stark and the use of lighting and brightness will be key to establishing the look and detail. We’ll see how it turns out. Tonally, it’s similar to Turnover. I guess colorful, vibrant worlds are just not in my wheelhouse.

XInput, Controllers, OS

I rewrote the input system for the engine and it now uses KB/M and XInput only. Since there is only a Windows build for the time being, I figured I would keep controller support to just one API and not worry about anything else. If someone is not using an XInput controller, I don’t think it is unreasonable to ask them to use something like x360ce. If I consider a Linux/OS X port in the future, there are Xbox360 controller emulators out there to handle the controller aspect.

I’ll revisit any porting plans after the game is released. I felt Turnover was polished and in a good state when I released it. But, looking back, it was more like a beta version compared to how it is now. Having learned all I have, I think it would be best for me to focus on just one OS, one API, etc., to keep things simple. Once the game is out, had a few patches, and is bringing in some sales, I’ll look into porting it to other OSes.

C++11 Work

In my down time, I’ve been re-reading Bjarne Stroustrup’s The C++ Programming Language to bone up on my C++11 standards. As I’ve been picking up more, I’ve been modifying engine code to help bring things up to speed where appropriate (i.e. can bring possible performance improvements).

I want to get into the habit of writing simpler code, so I’ve been doing things like replacing most of my iterator based loops with range-for loops. One simplification I refuse to use is the auto keyword. It can make some code confusing, especially if what is being assigned auto isn’t right there for me to refer t, or is hidden in a class implementation. I like things to be clearly defined.

So, I’m trying to improve my essential code right now before I have to lock things down. I’m about a 1/3rd of the way through the book, so maybe by the end of the month I’ll be finished with that endeavor.

Next

This month, I’ll be probably be planning and solidifying more of the base gameplay. I’ll be running more tests and trying to get a better sense of how this whole thing is going to bear out.

[anthonydev]

DevBlog: New Game 03/09/2017

Development of the new game surges ahead. Here’s what I’ve been working on over the last month.

Collision

Been giving the collision system some quick optimizations lately. I ran some tests to find that many actors/projectiles bunched closely together caused heavy slowdown. Turns out an awful lot of math calculations (for projections, axes, etc) where being calculated with each and every collision check. So, if I was checking collision for 60 actors in a bunch/quad, then there would 60^60 of these calculations.

To fix this, I precached the result of those calculations for each entity prior to knocking through the collision checks. So, 60^60 calculations becomes just 60. Sped things up nicely. In addition, I have been experimenting with multithreading certain engine parts. There have been marginal improvements when doing so and I’ll revisit far down the road. Not worth the time investment at the moment.

Animation

The main character of thisnew game had some redundant art in his sprite sheet. Running, shooting, etc.. all had discrete animation frames. I had no means in which to blend animations. So, if down the road, I needed to change the way the character looks, I would have to edit numerous varieties of animation.

To remedy this, I split the animation up into distinct parts, mostly separating the body from the legs. Now, I don’t have 4-5 variations of run animation to edit down the line if need be, just one set of legs. Splitting this apart also improved the quality of animations when transitioning between states. There are no more awkward fame switches mid-animation various states. Everything looks much nicer. I’ll port this process over to other complex animations where needed.

Lighting

Just a mostly minor addition here -- the game now has Cone Lights!

Looking crisp.

Art

Since I’m still developing a gameplay composite (i.e. fully completing a portion of the game), art work continues on. For the composite, I have about 50% of the enemy art drafted and the remaining 50% sketched out. I’m trying to get as much in-game as quickly as I can so I have time to digest everything when I move onto to the grunt work of level creation.

I’ve been completing a lot of other art over the last month as well. Lots of preliminary background art, parallaxing, sprite based effects (enemy dissolves, etc.), projectiles, muzzle flashes, explosions, and the like.

Code

Shored up a bunch of code from the earliest engine tests. I recently:

Removed a number of unneeded virtual methods.

Preferred using override instead of piggybacking virtual onto overridden methods.

Moved many more actor values definitions to external metadata files to further cut down on compile times and speed up experiments.

Rewrote the item drop system to be more controllable.

Implemented more C++11 conventions.

In addition, the game made the transition from VS2015 to VS2017 successfully. No headaches there.

[anthonydev]

DevBlog: New Game+ 02/08/2017

I used to do regular dev blogs while I was working on Turnover. Now that development of my next game is in full swing, it seems like the right time to start them back up. It’ll give me a chance to write about what I’m working on, keep anyone who is following updated, and also to clear my head.

Collision System

Recently, I revamped the collision backend of the new game’s engine. The collision system now has two simple checks: a quad tree check, then a more detailed check using a separating axis theorem for the actor’s collision polys.

Collision is handled something like this:

Think() actors, updating their locations in the logical game world.

Update the collidable actors positions in the quad tree using their position in the game world.

Run through a main list of world actors. For the current actor in the list, pull all actors that reside in the same quad.

Utilize SAT poly check to run a collision check on each.

If there is a collision, run the actor’s collision callback, passing the colliding actor and the minimum translation vector with it (for collision resolution, if applicable).

Go to next actor in step 3 until all actors are checked.

Simple enough. The quad tree ensures that we are not checking too many objects against each other, and the SAT check handles the meat of the collision detection. This setup is more than likely the final version of the collision system.

Lighting System

I’ve modified Turnover’s vision cone system and ported it over to the new engine. I’ve improved it and created a whole lighting engine out of it.

I’m very happy with how it turned out. When I first rewrote it, it was very performance heavy. After some profiling and identifying slow downs, I ended up rewriting the whole thing over. Now, it is 73% faster (per profiling data) than the older, draft version.

I plan on using this lighting system for static world light. I can also generate faster, lower resolution lights for things like projectile trails.

Stylistically , this may end up changing through development, but a strong base of lighting is ready to go.

Drafting Art

Now that I have the main gameplay nailed down, more or less, I’m beginning to draft art for the game. This consists of sketching and blocking out what the enemies are going to end up looking like. I tend to work in iteration, so I’m sure I’ll end up revisiting everything multiple times down the road.

The goal is to establish an art style and execute it consistently across the entire game. The draft art will give me a chance to solidify look, resolution, palette, the average number of animation frames, etc. So far, things are coming along well.

Gameplay

At the moment, I’m putting together some composite pieces to see what the final game will feel like. This means that I’ll be “completing” portions of the game to see where I should take it. I’m just searching for a level of detail to work towards.

While working on Turnover, I found myself building these large gameplay systems (RPG leveling, etc) that ended up getting axed. These experiments helped push Turnover to become what it was, but ultimately they resulted in wasted time. With this game, I’m putting together more robust tests to see if ideas will work out. I’m building progressively instead of creating then cutting.

Story

When it comes to story, I have the prologue and the main arc nailed down. I’m currently working on the the story beats, so I can shore up who the game flows. I’d like there to be a strong connective tissue between the beginning the main character’s journey to the end. I’m also still searching on how to resolve the whole thing.

Progress Report

With Turnover, I announced the name, log line, screenshots, etc probably around the 1/3rd mark of development. I’m probably going to avoid doing that with this game and just wait until I’m about 50% of the way towards an alpha build.

Hopefully soon, I’ll be putting together an internal build that represents about 1/5th of the game. I’ll give that to some testers and get some real feedback before I jump into the grunt work.