I moved to a new URL! Check it out!

posts tagged with: gamedev

Releasing Five Games in a Year

Releasing Five Games in a Year
Today is my birthday! It's a good time for reflecting back upon my now 27 year long life. This time last year I was right in the middle of crunching on Offspring Fling for the Steam release. I was coding up the level and replay sharing website with some help from Matthew Wegner, and I was also polishing up more stuff in the game for the big day when the game would arrive on Steam. Stress levels were at an all time high, where as this birthday I think my stress levels are at an all time low.

Between my last birthday and this one I've released, or in part released, five new games into the world. This was part of a promise that I made to myself at Game Developers Conference in 2012. At that GDC, I was neck deep in working Snapshot still. Snapshot is a project that started originally in 2008 as a little Multimedia Fusion prototype. Eventually that prototype got into the Independent Games Festival in 2009, and from then on out it was a full fledged game being assembled by David Carrigg, Peter Jones, and myself. The game didn't come out until August 2012. That's a pretty long time to be working on a single game... although its not that long compared to the time spent on a number of really awesome indie games.

Image

The main problem is that Snapshot is the longest term project that I've ever worked on. During the course of its development I felt very stagnant. This game was taking forever to make, and a lot of the time I just felt like we had nothing to show for it because usually the game was in a half broken unplayable state. The game didn't really start to take form until the final year of its development, but by the end of the project I felt like I was being suffocated by it.

Jump Input Buffering

Jump Input Buffering
Yesterday I updated Super Ninja Slash with a few tweaks, including the addition of jump input buffering. I talked about this a little bit on Twitter, but due to the 140 character limit I think I might've caused some confusion as to what I meant by jump input buffering.

First what I mean by input buffering is allowing the player (or any source of input) to input commands into the game and allow those commands to be effective for a short window of time after they are inputted. In the case of jump input buffering, the goal is to allow the player to input the jump button and still have a successful jump even if they mistimed their input by a tiny amount.

I made some doodles to try and illustrate what exactly is going on. Imagine that this is some typical platforming game.

Screenshot Saturday

Image


Some progress today on a fancy menu screen. Making a lot of use of my nine slice rendering class. I'll be posting an updated version of that soon!

Dev Log: Some More Camera Stuff

Dev Log: Some More Camera Stuff
I'm feeling pretty exhausted today so this post will probably be pretty short. Last week I posted about working on some camera stuff for platforming in Flashpunk. I made a few adjustments to the way my camera worked based on some more stuff I observed from Mario World and Yoshi's Island.

Image

I changed around how some of the horizontal camera stuff works. Now you have some wiggle room before the camera starts to move at all horizontally. The look ahead also works slightly better than before. If you're pushing up against the side of the wiggle-area, the camera will slowly look ahead in the direction you're pushing. If you're moving in that direction, the speed in which it looks ahead increases so that you'll hopefully always be able to see what's coming down the line if you're moving fast.

The vertical movement is more or less the same. The camera only catches up to you when you're on a platform, or if you're pushing the margin of the screen with jumping or falling. The falling margin of the screen is much higher, since usually if you're falling you want to see a little bit downward. One thing I did change was the camera's natural target point in the y direction. Now if the camera thinks you're moving upward a lot, it will look above the player somewhat. If you're moving down though, it will look directly at the player again. Looking somewhat above the player ends up looking nice in most platformers because locking on in the center usually means showing 50% of the screen as solid ground with the most basic camera behavior.

I have run into some snags along the way... right now I need to figure out how to handle camera blocking better. Camera blockers are necessary for a game like this to hide secret areas, and I don't want to reveal them until the player actually crosses into the secret area. At the point in which the player crosses the blocker, the camera will then be unlocked and catch up to its target position again. This worked fine up until the point in which I made the player camera more complicated... I might have to do some tinkering to get it working just the way I want, but also in a clean and reusable way.

Okay that's all for now! (PS The Flashpunk website is still down, but once it comes back up all my links to it will work again! Also if you're looking for just the code, check out the Git repository.)

Dev Log: Platforming Camera

Dev Log: Platforming Camera
Chipping away at things in my remake of my Global Game Jam game. Now that I have more than 48 hours to make the game, I've been taking some time to figure out some things that I've been neglecting for the past couple years of making short form game jam games.

In Offspring Fling, there is very little scrolling. I think only one level actually scrolls both horizontally, and vertically. On top of that there are still only a few levels that scroll at all. This means that I didn't really have to worry about a complex camera, I just have the camera follow the player with a little bit of a drag and it works out mostly fine.

For this new game I'm working on, there's a bit more platforming, and almost every level will have scrolling in it, and there will be some big and open rooms... so I want to have a better camera system in general to handle platforming.

What do I mean by this? Take a look at this breakdown of the camera system from Mario World.



This kind of camera system is pretty crazy. There's a lot going on behind the scenes to make sure that the camera is showing the player exactly what they need to see. This is definitely one of those things where if you do it right, nobody will notice you're doing anything at all, but it is incredibly difficult to get this kind of stuff right.

Colliding with Slopes?!

Colliding with Slopes?!
In my last blog post I talked a little bit about how I've implemented slopes in my latest project, but I only talked about how I was actually importing them from Ogmo Editor into Flashpunk and not about how I'm actually using them for platforming. In this post I'll attempt to explain how I actually use slopes in my movement system, which means my platformer characters can walk up and down them without any problems.

The first thing to keep in mind is that all of my slope code only really works with slopes that increase or decrease by 1 pixel. I could rework some of it to make it work with a step of any size that the programmer could define, but for now 1 step is all I really need.

Pixel Sweepin'


The first thing to know is how I actually go about moving my platformer characters, and other moving objects around my game world. I use a method that I refer to as pixel sweeping. Basically whenever an object moves in my games, I move it one pixel at a time and check for collisions at each step! This might sound a little crazy to some folk, but this is the most reliable way I've been able to do stuff like platforming and other moving objects and still collide with even the tiniest pixel of a floor or wall. I've been using this technique since the very beginning of Bonesaw: The Game.