Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comment
  • views

About this blog

Develpment Journal for T-JAM Studios

Entries in this blog


Flick Ninjas Dev Part 4: Pixel based collision detection in 2D games

[font=Verdana, Arial, Helvetica, sans-serif]This article was originally posted on Gamasutra on February 11, 2011

Flick Ninjas was approved for sale tonight on the iTunes App Store! To celebrate I thought I'd offer some inside info into the collision detection and response system that I implemented in Flick Ninjas. Check outPart 3 of my series to read about why I think that Apple is still way ahead of Android when it comes to helping out indie developers.

When designing the collision detection system for Flick Ninjas, I originally determined that I would use a simple tile based system with maybe some 45 degree angles for good measure. I actually implemented the prototype of the game this way to prove that the control scheme could be fun. But when it came down to designing the visual appearance of the game, I felt that the limitation of square and 45 degree angles just wasn't going to work. I really wanted to have arbitrary level designs. I looked to games like Worms for inspiration and started searching the web for ideas when it came to collision detection.

I found a couple of articles explaining how games like Worms and Scorched earth did their collision detection, but quickly found that these methods would not be sufficient. In these types of games they simply test a single pixel on the bottom of the Worm. When it overlaps a pixel they simply move the Worm up a pixel at a time until it is no longer overlapping. This is called collision detection and response. The detection part simply looks to see if there is an overlap, and the response portion involves moving the entity until it no longer overlaps.

The weaknesses of this approach became apparent very quickly. When it came to side and top collisions, this technique wasn't smart enough. It could only really determine that the response would move the entity too many pixels high, and thus prevent forward progress, however it couldn't tell me how far it had moved into the wall as you could only inch one pixel at a time in worms. There simply wasn't enough information to tell me what I needed to know when I impacted a wall, a floor or a ceiling, or any combination of all three. I needed a new approach.

First, I needed a collision detection technique. I decided that I would test every pixel that overlapped my entity instead just a single pixel, this way I could see where overlaps took place. I created tiles that were essentially 32 DWORD values where each bit represented whether a pixel was on or off. I would then see how the entity overlapped the world tiles by ANDing the DWORDS together. This meant I just needed to test 32 values using bitwise operators per frame. Pretty cheap! This approach worked great for collision detection. I knew exactly when I was overlapping and which pixels overlapped. From here I assumed it would be easy to determine how to respond based on the number of pixels overlapping in each direction.

Sadly I was incorrect. It was non-trivial to determine whether a pixel overlap should shift my entity up, down, left, or right. I needed a way to isolate each side of the entity from the other sides, so that I knew how many pixels I should shift in a given direction. After a few days of beating my head agains the problem, I discovered an interesting approach illustrated by the image below:

I call this approach, a Cross Mask. Essentially I created a new 32 DWORD tile that only flags some of the pixels as part of the collision volume. I then do the same ANDing process with the world tiles, and check only the top 8 DWORDS for Top, the bottom 8 for Bottom, and the middle 16 as the two sides. I then needed to tell the difference between the left and right. I did this by only testing if values were greater or less than the values representing the inside portions of the mask.

This approach allowed for almost everything I wanted. I could tell how many pixels I needed to shift, and what direction for up to two sides at a time. This is where the only downfall to this approach presented itself. I couldn't test both the top and bottom, or both the left and right at the same time. I tried prioritizing certain sides and such, but to no avail. I may approach this problem again, but to solve it, I simply don't allow gaps smaller than 32 pixels wide in the level. In cases where the style required it, I simply created a special entity that block progress further into these sections of the level.

If you have any questions about this approach, let me know in the comments. And check out mypersonal development blog for a look at both my official trailer, and my new launch campaign series of trailers. Also, feel free download Flick Ninjas now if you feel so inclined.





Flick Ninjas Dev Part 3: Why iOS is Better for Games than Android

This Journal entry was originally published on Gamasutra on February 1, 2011

[font="Verdana, Arial, Helvetica, sans-serif"]With 4 days remaining until submission, I decided that now would be a good time to discuss a topic that I feel is essential for indie developers on mobile platforms. Why pick iOS over the competition?

In Part 2 of this series I discussed the idea of a Tile Based Game Engine that would allow for a completely arbitrary level design. In that article I mentioned that I have never actually owned an iPhone. So why would a developer who was writing software for a platform that was, until recently, called "iPhone OS" when he doesn't even own the phone? At first is was because of cost. But as I proceeded, I found a new friend when it comes to game development, and a great reason to stick with what is now called iOS.

For starters, let's look at the Android platform. As an open platform, the SDK and all the software necessary for development are absolutely free. Some would call this quite the low barrier for entry, and a boon for developers. While it's great that I don't have to pay $100 per year to develop for them, there are other concerns that game developers particularly have to take into account. Testing on an emulator can only take you so far. It can get you there when it comes to raw functionality, but when it comes to feel and performance, you really need to invest in a device to install your game on.

When in the prototyping stage, I really couldn't go any further in development with the provided Simulator, because I couldn't tell how my games would actually feel on an actual piece of hardware. There always comes a time in development when you just need a piece of hardware to test on. With Android, this currently means a couple of things. One, you have to buy a phone. Two, unless you want to pay nearly $1000 dollars for said phone, you are going to have to tie yourself to a two year contract. Three, hardware and software fragmentation will mean that you have to either purchase at minimum 2-3 devices for testing, or have that many friends willing to lend you their phones. This barrier will prevent innovation on the platform, because often games will be developed without the actual feel of a device until much later in the dev cycle.

And now for Apples solution. Enter the iPod Touch. When I first heard the announcement of the iPod Touch, I was a bit confused. It's an iPhone without the phone. How could that be useful? Then a few months later Apple announced the App Store, and the native SDK for iPhone development. It finally clicked when games started to hit the App Store. The iPod Touch is a game platform. Low cost of entry, means that the potential audience is huge. What parent is going to buy their kid an iPhone with a contract of $30 a month for data. Most parents would have no qualms with spending a couple hundred dollars on what is both an MP3 player, and a decent portable games device as well.

The iPod is also a great answer for developers. If you follow Apple's design cycle carefully you'll notice a few patterns. Apple will release a new hardware revision each year. This could mean you have to buy a new device each year, pegging iPhone development at around $300 total each year. However, another pattern has also been fairly evident. Major features seem to only be introduced every two to three years. I was able to stick with my Second Generation iPod Touch for two years until the iPod 4 came out. I only bought a new one because I really needed to test drive the Retina Display to make sure it wasn't detrimental to performance. That put iOS development at only around $200 a year average, which is even better. Compare that with the possibility of having to spend nearly $2000 a year just to keep up with Android and I can see exactly why developers flock to iOS for games.

Of course the requirement to use Apple computers for iOS definitely doesn't help the cost situation any, but I think that most developers would buy a computer to work with anyway. Then you just have to factor in the "Apple Tax" as it is sometimes called.

Finally, this iPod can keep us as developers focused on a few things when it comes to game design. I've seen a lot of cool tech demos and interesting apps developed with the iPhone's capabilities in mind. The GPS and 3G connection alone offer some great possibilities. However, you're going to be limiting your potential audience. Just think of all the kids out there with iTunes gift cards that want nothing more than to buy more games for their shiny new Birthday/Christmas present. If we keep focused on the core tenets of the platform, we won't be tempted to leave a majority of our audience in the cold. Developing on the iPod Touch is a great way to keep that perspective very clear.

Well that's it for today. Stay tuned for another feature each day, and keep your eyes open for my game Flick Ninjas to be released in mid-February. Feel free to visit my personal development blog for more information, and to view my official gameplay trailer. Also feel free to click the "Like" button on my blog to follow Flick Ninjas on Facebook.





Flick Ninjas Dev Part 2: Arbitrary Level Design with a Tile Based Engine

This Journal entry was originally published on Gamasutra on January 31, 2011

[font="Verdana, Arial, Helvetica, sans-serif"]So, I'm just 5 days from submitting my game Flick Ninjas to Apple, and I'm in the thick of final testing, but I decided that I should start of series of posts relating to difficult problems I had to solve during development of my first game as I count down the days to submission.

Part 1 of this feature (admittedly, I didn't know this would be a series when I wrote it) addressed crafting a platformer that works better with a touchscreen then it would with a gamepad.

In this post, I will review a decision I made to create a tile based engine that imported arbitrary images of levels and generated the tile-map based on that. Right off the bat, I'll admit that this might not have been the best choice I made, as size constraints quickly reared their ugly head as I started creating Retina Display ready images. However, the ability to quickly draw my levels and simply import them with very little modification into my game was quite a time saver. Being an artist, WYSIWYG is an awesome perk in an engine!

I originally designed my game to use a standard tile based engine, with the intent to fit together standard tiles to construct levels based on different environments. I designed a few levels based on this approach, and determined that these basic tiles would limit my art direction significantly. Also, it would expose my weaknesses as an artist, as repeating tiles/textures have never been my strong suit. I luckily had made a decision early on that I wanted to use Flash to simply draw the levels and then import them without having to have a special level editor. Because of this approach, I already had an importer that would search for repeating tiles in a png file and construct a map out of it. I decided to throw a simple arbitrary level design (no obviously repeating tiles) at it and see what happened. It worked beautifully.

The next issue was to fix my collision detection and response system to allow for pixel based collisions, but I'll save that discussion for another post.

I worked with this approach for several weeks, cleaning up and polishing gameplay before really putting the content pipeline through it's paces. I designed 5 different themes each with a corresponding level, and here is where I ran into one of my first drawbacks to this approach. Level complexity was limited to the size of the image that the tile generator would spit out. If I increased complexity, it wouldn't fit in a 1024x1024 image, the texture size limit for the iPhone at the time. I was luckily able to figure out how to decrease the complexity of my levels without it being too obvious in the design of the levels, but it was still a bit disheartening. Oh well, chalk one up to experience.

Then came Apples announcement of the iPhone 4's Retina Display. I really loved how sharp everything looked on the device in the Apple Store, and I couldn't wait for the feature to come to the iPod Touch (I don't actually own an iPhone. I'll explain this in a later post as well). I filed away a feature request to myself to add support and didn't really touch it for a month or two.

When I did finally approach the problem, it took a few days to get it working properly, but since I had drawn all my levels in Flash, I could export them at double resolution without any loss in quality. The first real problem with this was addressed by Apple. They increased the max texture size to 2048. Because of this I could generate essentially identical images by simply doubling the resolution. Honestly, all of these decisions coming together to make my life easier were fairly serindipitous (I being a faith-based individual, attribute this to confirmation that I should stay on the path I've been taking), but I definitely didn't complain. After exporting a few levels I ran into another problem. Flash CS3 would not export images large enough to encompass one of my levels. In the end I ended up having to cut part of the level out, and keep the limitation in mind for future designs. Once again, difficult, but definitely not the end of the world.

In the end, I ended up with what I think is a fantastic art style, and a pipeline, albeit with a few caveats, that makes content creation fairly straightforward and simple to accomplish.

That's it for this post. Stay tuned for another feature each day, and keep your eyes open for my game Flick Ninjas to be released in mid-February. Feel free to visit my personal development blog for more information, and to view my official gameplay trailer.





Flick Ninjas Dev Part 1: Creating a platformer for iOS that's better without a gamepad...

[font=Verdana, Arial, Helvetica, sans-serif]This journal entry was originally published on Gamasutra January 27, 2011

I started developing a game for iOS over a year ago. I started with the simple goal of building something unique on the platform that hadn't been done before. I scoured the App Store searching for any untapped potential and nearly gave up. I built three different prototypes with two things in mind: Build a game that plays to the strengths of the platform, and NEVER USE ONSCREEN GAMEPADS!

I'll be honest. I despise onscreen gamepads. I've played dozens of platformers and the like that try to use them, and the lack of tactile feedback makes quick-twitch games always feel cheap or unplayable. These games feel like cheap and easy cash-ins of existing IP's, and I think that it shows a lack of effort on the part of the developers. iOS offers many unique opportunities for control schemes, that can't be found anywhere else at the moment. The multi-touch surface alone affords loads of ways to control a game. It just takes some creativity to figure it out.

I like to look at Nintendo when I evaluate the control opportunities of a platform (and I think that most developers should do the same.) Using Phantom Hourglass as an example, here are a few examples of how Nintendo utilized the features of it's platform to give a unique experience.

At one point, I was asked to put out a large candle, and sat dumbfounded for a few minutes. It turns out I just needed to literally blow the candle with my own mouth. It just used the microphone, but it was still interesting. Still later in the game I was asked to press my map on the bottom screen against a symbol on the top screen to find the location of an island. The way this was accomplished was by actually closing the DS.

To cap it all off, the entire game is played using the stylus and touch screen. A Zelda game had never used a control scheme like this, but I would argue that I prefer to play both Phantom Hourglass and Spirit tracks this way. It really feels intuitive to use the screen as an analog stick, and to tap and swipe to attack.

If Nintendo can almost entirely eschew a standard control scheme in favor of touch controls on one of their flagship franchises, I really feel like more people can take these risks on the iPhone.

Back to my own experience. In the end, the three genres I experimented with were:

A top down vertical shooter An asteroids clone A platformer The top down shooter used basic touch controls to move the character around the screen and shoot. I ended up opting out of the idea because I found many other games on the store that used the same mechanic, and I wasn't really improving the concept any.

The second I tried was pretty much like asteroids, but using touch on the screen for aiming and moving. Although I haven't found anybody else doing this type of game this way, I felt that I could be even more creative.

So, I came to my last option. A platformer. I had been concepting an idea I had once, where I would design levels simply by doodling a random line on a paper, and treating it like it was the players movement. I then treated those random lines as swipes or flicks on the screen. I experimented with this concept for a few months, and asked others to try it out along with my asteroids clone. I then added a basic clock and asked people to try to beat my times. Most everybody loved the platformer.

As I started designing the rest of the game, I quickly discovered that I had a tremendous amount of flexibility when it came to level design. Things didn't need to be exactly on grid lines, because I could jump at any arbitrary angle. This wouldn't have been intuitively possible with an onscreen gamepad, or a gamepad at all for that matter.

Precision of running and stopping became my final concern with design, as most people ran off cliffs rather easily. I then added a context sensitive tap system. These taps suddenly made movement and control feel instantly intuitive. I originally feared that this would remove some challenge from the design, but quickly found the the timing necessary to stop at just the right moment was very interesting.

I am now nearing release for my game. It's called Flick Ninjas (you can find a link to my official trailer on my development blog) Every time I hand it to somebody, I just have to say "flick the ninja to move him," and the user is instantly able to start traversing the level. Tapping takes some more explaining in the games tutorial system, but the ease with which I can explain the basic controls makes this control scheme invaluable. I really don't think that Flick Ninjas would have been possible on any other platform.

Look for Flick Ninjas in the App Store in February, and feel free to "Like" our fan page on Facebook. Simply search for "Flick Ninjas" and it will come right up.




Sign in to follow this  
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!