This LudumDare, I didn't have *nearly* the time or focus compared to the last one. I had family pictures, a huge family party, EATING, etc. I think I probably got in 20 hours of solid work, minus about 6 that didn't get used. Here's the broken down takeaway:
1. DO NOT START PROGRAMMING BEFORE PSEUDOCODE/DESIGN IS DONE. This caused me to lose a MASSIVE amount of time. Had I done about an hour more of design and planning, I would've moved right past my first implementation, and would have gained 5 hours of time. My entry would've been much more complete.
2. DO NOT TRY TO MIX GAME TYPE/CONCEPTS. It is great for long term development, but it just can't be done in 48 hours.
3. KISS. "Keep it simple, stupid" should be the tagline for the entire competition.
4. DO PLACEHOLDER ART FIRST. Trying to do artwork before coding an engine, and really the entire game, is BAD.
5. Don't go to family Christmas parties.
In all, I wrote 994 usable, end product lines of code. The one thing I did really well this competition was HAVE ALL MY USEFUL CODE IN A FRAMEWORK. That was spectacular, and saved me tons of time.
Download the game here, or in the downloads page.
Happy gaming!
Sunday, December 18, 2011
Thursday, December 15, 2011
The Wonders of Collision Detection
Up to this point, collision detection has been a point of much internal dialogue for me. For instance, per-pixel collision tests are as accurate as it gets, and they provide a wonderful amount of positional information useful for many different purposes. However, it can get to be extremely expensive on the processor and GPU, so in most cases it isn't really an option.
For a while, I thought that rectangle based collision was the holy grail. It's fast, it's easy, and there's still vital mathematical information to be easily gleaned. Just try rotating your rectangles though, and you'll quickly realize that existing methods purely for rectangles will be broken.
After that, I moved on to circles. Circles are wonderfully inexpensive, and absolutely the easiest to implement. Even after parenting and otherwise layering them though, you still get pretty inaccurate collisions in a lot of cases, such as objects with sharp angles. This can be minimized, but it takes a large amount of effort and can end up negating the speed gained over other methods.
Finally, I am where I am today. Convex polygons, as of this week, are my favorite method. I spent hours poring over different sites and their explanations of the Separating Axis Theorem. I looked at source code, I performed tests, I even looked in my Calculus textbook for help (no dice). Eventually it clicked for me, and it works wonders.
Still, there are grounds that have to be given up. SAT only works for convex polygons, which can be a bit of a hassle. You can represent any concave shape with multiple convex ones, but that is beside the point, and automagically creating multiple convex shapes from a concave source is something I have yet to understand. Also, while this method is relatively fast, it still isn't anywhere near as fast as its circle counterpart.
It is obvious to me at this point that compromises will have to be made with any method of collision, and even programming as a whole. Unfortunately, that doesn't keep it from bugging me...
For a while, I thought that rectangle based collision was the holy grail. It's fast, it's easy, and there's still vital mathematical information to be easily gleaned. Just try rotating your rectangles though, and you'll quickly realize that existing methods purely for rectangles will be broken.
After that, I moved on to circles. Circles are wonderfully inexpensive, and absolutely the easiest to implement. Even after parenting and otherwise layering them though, you still get pretty inaccurate collisions in a lot of cases, such as objects with sharp angles. This can be minimized, but it takes a large amount of effort and can end up negating the speed gained over other methods.
Finally, I am where I am today. Convex polygons, as of this week, are my favorite method. I spent hours poring over different sites and their explanations of the Separating Axis Theorem. I looked at source code, I performed tests, I even looked in my Calculus textbook for help (no dice). Eventually it clicked for me, and it works wonders.
Still, there are grounds that have to be given up. SAT only works for convex polygons, which can be a bit of a hassle. You can represent any concave shape with multiple convex ones, but that is beside the point, and automagically creating multiple convex shapes from a concave source is something I have yet to understand. Also, while this method is relatively fast, it still isn't anywhere near as fast as its circle counterpart.
It is obvious to me at this point that compromises will have to be made with any method of collision, and even programming as a whole. Unfortunately, that doesn't keep it from bugging me...
Wednesday, December 14, 2011
Pathfinding (And Resuscitation)
Okay, so it's been a little while since anything went up here.
A long while.
Now that admissions of guilt are over, to the future! For the past couple of weeks I've been preparing for LudumDare #22 (click the link for a description if you don't know what that is), working out some problems that afflicted me last time, trying out some new concepts, getting better at commenting my code, and just generally practicing. I can't tell you how excited I am! No really, I can't. My motivation is a little bit gone at the moment, I've been quite sick this week.
Regardless, I *will* be participating, and I'll force myself to like it if I have to.
Today, I managed to implement some relatively simple pathfinding in a node-based system. Essentially, you split your playing map into nodes. You assign each node a list of neighboring nodes. After giving the system a starting node and an ending node, it determines which neighboring node has the shortest distance as the crow flies to the ending node, then makes that node the current node. This process is repeated, adding every node that has been visited to a "closed" list that it will not re-visit. Once the ending node is reached, the closed list becomes your path!
My system will *always* find a path if one exists (which is possible that it doesn't, considering some nodes are "unwalkable"), although it will not always be the shortest. It works well enough to satisfy me though! Especially since I spent all of my waking day throwing my currently broken brain at this problem, and all I've got is a barely working algorithm that is some 50 lines of code long... XP
Anyways, thanks for reading, and look for more posts from me soon!
A long while.
Now that admissions of guilt are over, to the future! For the past couple of weeks I've been preparing for LudumDare #22 (click the link for a description if you don't know what that is), working out some problems that afflicted me last time, trying out some new concepts, getting better at commenting my code, and just generally practicing. I can't tell you how excited I am! No really, I can't. My motivation is a little bit gone at the moment, I've been quite sick this week.
Regardless, I *will* be participating, and I'll force myself to like it if I have to.
Today, I managed to implement some relatively simple pathfinding in a node-based system. Essentially, you split your playing map into nodes. You assign each node a list of neighboring nodes. After giving the system a starting node and an ending node, it determines which neighboring node has the shortest distance as the crow flies to the ending node, then makes that node the current node. This process is repeated, adding every node that has been visited to a "closed" list that it will not re-visit. Once the ending node is reached, the closed list becomes your path!
My system will *always* find a path if one exists (which is possible that it doesn't, considering some nodes are "unwalkable"), although it will not always be the shortest. It works well enough to satisfy me though! Especially since I spent all of my waking day throwing my currently broken brain at this problem, and all I've got is a barely working algorithm that is some 50 lines of code long... XP
Anyways, thanks for reading, and look for more posts from me soon!
Subscribe to:
Posts (Atom)