Basic lasers and collision detection

If you're the left ship, you can now shoot the other guy. If you're the right ship - maybe you can be the left ship next time.


Left Ship

Left stick angles ship

Right trigger accelerates

Right bumper or X button fire

Right ship

Arrow keys


Swoop swoop

After a little bit of time fighting with rotation math, I managed to get basic controller support for the left ship. That led to this little demo of what it looks like to swoop around the other player when they're standing still.
- WASD to move left ship
- arrow keys to move right ship
- Gamepad 1 left stick to rotate left ship
- Gamepad 2 left stick to rotate right ship
- Gamepad 1 right trigger to accelerate left ship

Splitting hairs

For this next project, I've decided to build something that's two player split-screen.

The idea of split-screen has been around for a while, so I thought - how hard can it be? As it turns out - pretty hard. In order to get split screen working I had to sort of step back from all of Flash's DisplayList abstractions/help and go back to drawing things myself. After some finagling I managed to pull it off though, and now I have working two player split-screen. WASD to control the left player, arrow keys to control the right.


Dungeon final build

Well - it's deadline time, and I wasn't able to scrape out the time to make the sword work the way I intended to. This is the final build of Dungeon, with a terrible name, and it's a stealth game.

What went well:

Doing my own art

I floundered a lot at first, but eventually managed to buckle down and just draw some things (and they're all fairly identifiable as the things I set out for them to be, so - success). This is something I'm going to continue doing for other projects in order to help myself grow - I don't know that I'll ever get good at art, but I can at least get decent enough that it won't slow me down.

Improving tooling

At the start of the project, I was compiling and running using a shell script I'd cobbled together by hand. By the end, I had a nice Makefile I was using that could generate debug builds, package up release builds, and (assuming it was a mobile project) share builds to TestFlight for me to test. All of those tooling improvements continue to pay dividends as I work on more projects.

Just Finishing

By working to make sure that play mode was almost always playable, I was able to easily cut down scope and trim things out when it became clear that I wouldn't have the time to get them in before my (arbitrarily defined) deadline. Even though this project took (much) longer than I expected it to, I ground it out and I finished it. 

What didn't go well:

Poorly planned level editor

I didn't put a lot of thought into my level editor, and that began to show through the cracks fairly early on - I had designed it around editing a single level on the screen, without giving any thought to the overworld. This led to a structure that was fairly brittle to work with/around and probably cost me more hassle than it was worth - but by the time I realized it, I had already sunk enough time into working around it that I didn't want to go back. In hindsight I think I made the right decision in terms of just getting the project finished, but next time I build a level editor I'll definitely give more thought to how it integrates with the greater scope of the project.

Not enough thought about distribution

In some of the earlier builds, you can see there's a downloadable as well as a rooms.xml file - and if you don't load room1.xml when you first start it up, Things Break. This was pure laziness on my part - that's how I built it for debugging, so that's how it was distributed. After thinking it over I realized that kind of sucked for distributing it, so I sat down and hacked out a good-enough level loader - but I think that could have gone a lot better if I'd given it more thought upfront.

Shoehorned Play Mode

The play mode was built right on top of the level editor, and both codepaths still exist within the app (although I don't think it's possible for you to build + play a new dungeon layout anymore because of the embedded levels); this caused problems because the level editor needed a lot less chrome than Play Mode did, and as a result I ended up punting on adding any chrome to Play Mode. It still works, and you still know when you have keys and things, but - that could have been handled better, if I'd been clearer about my plans for what Play Mode would look like upfront.

Collision Detection

At first I did tile-based collision detection, which worked...okay. I ran into problems while I was filling in the enemy behaviors though; now that there were things on the screen that moved and didn't move tile-to-tile, none of my collision detection work made sense. I ended up having to rip out and replace it at the eleventh hour, which was a good learning exercise but would have been unnecessary if I'd done it right the first time. I'm going to give more thought to what's required in terms of collisions on the next project right at the start, so that I can avoid having to do that again.

Closing thoughts

I'm glad that this is finished and I was able to finish something and wrap it up in a way that's maybe not the most polished, but is  complete. While I didn't do as much with the game as I wanted to - I still learned a lot, added techniques to my repertoire for the next project, and came out of this with a finished project that's completely self-contained and ready to be distributed. Overall, I'd say this was a good experience.

But I am pretty excited to work on the next project.

A little more polish

In the interests of keeping this project as distributable as possible, I worked out a way to embed the level files into the executable - now when you launch it, you'll instantly get the start screen and be able to interact with the dungeon that's included. You can also get into editor mode to build your own levels, although I don't think that Play Mode works with custom levels anymore because of what I had to do to get embedded levels working.

I also spent a little bit of time polishing up the panels that you see throughout the game; they're a bit easier to read now (but still nice and chunky).

I'd still like to work on making your sword work so that you can take out enemies as you encounter them, instead of playing the stealth game you are now - but the deadline for this project is March 15th, and if I don't finish that part by then - this will just be a stealth game.


Collision detection: still the worst

I was well on my way to wrapping things up - I just needed to finish enemy collisions. That's when I realized that because they move, my existing collision detection code wouldn't work (it was based on a constrained grid, and didn't handle things moving from position to position) - so instead of wrapping things up and having enemies that work, I had to rewrite that.

This is a development build that includes the collision-checking rectangle; I made it a little smaller than the tiles so that your character colliding with doors and pushables works a little better (and also because when it's the full size of the tile, you snag on edges too easily). It's not super well constrained, but - it works, and I'm pretty okay with that.


Collision detection is the worst.

After getting room transitions working last week, I realized as I transitioned to the next room that my collision detection was only working for walls and doors - not blocks or anything that was actually IN the rooms. You can see a little white square that drifts around in front of the player character now, to show where I'm checking for collisions - it took a while, but I managed to get it so that when you run into something you're supposed to collide with, you can't walk through it anymore.

Room #2 added a pushable block though, so I needed to add handling for that - so I did.

(You can also go back into edit mode now, using cmd+O while in play mode)

Now transitioning between rooms

I now have the player character successfully transitioning between rooms as you wander the map - the game starts up in “Play” mode now, and you have to pick a level to get started (I’ve attached two rooms - pick room1.xml to start). WASD moves the character around, and bumping into doors transitions you through them.

Building the room transitions exposed some rough spots in my original design; it was heavily focused around there being only the one screen to manage, so getting the new rooms loading and transitioning took more work than I'd like. It works now, though!


Controller tank test

I took a short break and spent a little bit of time hammering out a basic project that uses a PS3 controller - the left stick rotates your tank and moves you around (poorly), and the right stick rotates your tank’s barrel.


Level editing, done

It’s taken a bit to get back into the post-holiday routine, but I’m getting there. I’ve completed the “edit levels” side of the editor, and now I just have to make it so that you can toggle into play mode.

New additions in this build:
- cmd+r resets the room
- clicking on doors lets you pick the room file that the door should exit to
- You can only place the player and goal tiles once

I spent a lot of time trying to come up with the best UI pattern for door exits, which was frustrating - after giving it a lot of thought it turned out that the best pattern was just to have it be a file select dialog (no extra UI chrome needed). Oh well - I know for next time, at least.