Had a talk with Brian Schrank today, our adviser/professor for the capstone project. He thinks the game is coming along nicely and is shaping up well, which is a huge relief, but it's more than clear we aren't out of the woods yet, a lot of work, and I mean a whole lot of work remains on this project.
Also, zombie yoga needs the Kinect working at 100% levels by... April 15th. Oh snap.
So what did I get done today? Practically nothing, I'm still working on my triangulator that I mentioned last (or the one before last) post, and after having a day off of it it's ridiculous to go back and have such a clear head of where everything was going wrong... which hopefully will happen with Zombie Yoga's pose recognition system too, but that's aside from the point. I simply got too far into the system and made some dumb mistakes with inter-class relations. Now it is very, very, very close to working. The only issue now is I have too many triangles on the inside of my objects, as opposed to having only 2 triangles in a box I have 4, they simply create too many triangles and let the others overlap. This is cause for minor concern, as I don't really know why this is happening (duh) but also minor celebration (yay!) in that I got the Delaunay triangulation technique to mostly work.
The other thing I did was go ahead and build a system for combos in our game. This leads into one of the points Brian (Schrank) mentioned today, that while our game is coming along great, some of the cohesiveness is missing. We have a game where you play as an angel, defending Eden, but with an arcade-y feel with points and numbers popping up everywhere and cartoony graphics. Each element is great on its own, the arcade feel is fantastic and was met by players with good responses, the carnoony art that Justin has been working on is simply amazing, and the story is one that has a lot of potential. But we have to cut back and reign it all back in, possibly major changes are coming in the future of this project, not necessarily in gameplay, but perhaps in presentation, we shall see.
Anyway, the combo system is a fairly flexible system, C# for some unholy reason decided it didn't really "like" binary search trees and doesn't include them as a base systems class which strikes me as rather odd. Regardless, I had to set up what would be a "quick search" system (ended up being a dictionary of lists...!) that could take the first "hit type" that a creep has received, find the appropriate list of possible combos, and iterate through that list until a match is found and a combo is registered. The combo is found, the appropriate message is displayed, point's added, and a counter keeps track of the times each combo is used/found/registered, etc. It's pretty standard stuff, however we can get a lot of creeps on screen, and searching through a list which has a list of conditions each combo must fulfill can eat up more time than I'd like, so the combo system has a cap. Think of it like your computer trying to send packets. There's a queued buffer of packets waiting to go out, if your packet encounters a full buffer of packets then, well, it get's dropped. (Yay multiplayer game development explaining the different joys of packet loss!)
My system is not quite so elegant (if you can call fumbling a packet elegant) it simply has a set number of times per second that the CheckForMatchingCombo() call can actually be utilized. If it has already reached it's max for that second, no more "expensive" calls iterating through the dictionary and lists will be made.
That kind of stuff is busy work. My system works, I have no doubt there are more elegant and efficient solutions, but mine is robust, it allows for lots of experimentation with different combos and more importantly it works, which is all that I need for it right now.
Tomorrow beings the long process of beginning to wrestle with the kinect again.
We who are about to die, salute you.
-Kev
No comments:
Post a Comment