The one year game develpoment duel
Apr

14

2014

On the Shoulders of Giants

This post is a status update, which is how I track progress specific to my game. Check out my timeline to see what I've recently accomplished.

    Key Events
  • Finished video tutorials
  • Proof of concept completed
  • Double dispatch working for physics

Game development has always been intimidating to me. There have always been so many unknowns that learning how make a game, let alone write in C, seemed unachievable. The past two weeks have been shocking to me because the tools and libraries available have come so far that game development is now accessible. I feel like I did when developing for the web and jQuery/Prototype.js came out. It’s an amazing time and indie games will only become easier to produce.

Now, don’t get me wrong. There is still a ton of work ahead. Fortunately, most of my work will be adding polish, levels and enemies to my world instead of struggling to draw something to the screen. There will also be a learning curve organizing a code base that needs to be so flexible and always changing. But enough about my concerns — let’s celebrate what I’ve accomplished in the first two weeks by watching the video below.

In my demo, I’ve got music, text, video, particle effects, collision detection, a HUD, animation and combat. That’s crazy! I thought I would have a couple of circles. It’s been an extremely rewarding two weeks. Aside from a few Objective C growing pains, I’ve had a great time working with Sprite Kit. I’m also starting to gain confidence that I can actually finish a game.

What Surprised me the Most?

There is more logic than I could have ever expected, and the code needs to be flexible enough to accomodate everything. To give an example, let’s walk through a ranged unit determining what to shoot.

  • Drop a new circular physics object sized by the archers range.
  • Once an enemy collides with that object, shoot the enemy and remove the ranged physics object.
  • Once the enemy dies, drop the range physics object again and wait for another enemy to collide.

By that point, I thought I had the foundation of archers working. As I developed more, the code had to be adjusted in some way. What happens when a unit walks out of range? If multiple units are in range, how will you decide which unit to attack? Should arrows collide with only their intended target, or hit other obstacles in the way? What if a unit has a min range in addition to a max range like a catapult? Are two different projectile types need to handle splash damage and normal damage separately? What about special effects like poison on an arrow?

As you can see, each feature touches the code in some way, so organization will be critical.

Onwards

You’ll notice my demo is of the tower defense variety. Tower Defense games like Defender Chronicles and Kingdom Rush have always been among my favorite mobile games, so it is natural that I’m pulled towards that direction. In terms of scope, I’m a bit concerned but I won’t turn back just yet. Most importantly, I’d like to add enough interesting, new concepts to move the genre forward a bit.

Over the next two weeks my focus will be movement and melee combat. I’d like movement to feel organic for skirmishers, and I’d also like to add a formation option to group units together. For combat, make the units smarter and visually make things look more interesting. For example, have units pick up their speed as they get closer to engaging someone. Check back in two weeks to see how it goes!

Speak Freely


Thank you

Your comment will be published once it has been approved.

Click here to see the pull request you generated.