Time spent: Only around 30-40 minutes. Caught up on the last of Jessica Jones tonight. Good stuff, if you're looking for more netflix to indulge in. Gets very intense.
Didn't get too much done in that time. Got JSON parser in, set up the basic deck, shuffling, working on popping unique cards off of that deck and using the JSON nodes to populate the info. Pretty simple so far, rule changes went without a hitch. Working on value changes now. Slightly trickier, but not by much. Tomorrow is date night with Morgan so I won't get anything done then, I'll have to come back to this on Thursday.
Tuesday, January 5, 2016
Monday, January 4, 2016
#RealWinners
So I know barely anyone still reads this, which probably makes it perfect for the experiment I want to try. I don't think it's any secret that I'm not exactly great at finishing what I've started, but I've put money down on this next thing I'm working on so I need anything I can get my hands on to keep myself accountable. I think having a journal of my work will possibly help motivate me, or at least can be a source of seeing how far I've come when I'm feeling down.
So this is the journal of my work going forward. At least for this one project, code named #RealWinners.
A base description of the project is "Calvin Ball as a Videogame"
I'm pretty excited about it's possibilities, and the system I have in place should be flexible enough to allow me to do this. I need a playable demo ASAP, and that's my short term goal. The code can be complete shit as long as I get it playable and hopefully fun.
Not many details now, the last part I was working on was the Slap Card system. I need it to load cards, images and descriptions from JSON so I can get a basic deck set up, then I just need to add cards to players hands after they score. That should be about the last thing I need to do before playable. That and re-spawn players at their starting points when the ball drops, but that's not 100% nessecary.
I also need to set up a perforce for my collaborators. Last time I tried to do this it ended badly because there's already a perforce server in our subnet. I should talk to ricky about what he had to do to set this up.
No shame on this project, Gibbs rule #28: if you need help, ask.
So this is the journal of my work going forward. At least for this one project, code named #RealWinners.
A base description of the project is "Calvin Ball as a Videogame"
I'm pretty excited about it's possibilities, and the system I have in place should be flexible enough to allow me to do this. I need a playable demo ASAP, and that's my short term goal. The code can be complete shit as long as I get it playable and hopefully fun.
Not many details now, the last part I was working on was the Slap Card system. I need it to load cards, images and descriptions from JSON so I can get a basic deck set up, then I just need to add cards to players hands after they score. That should be about the last thing I need to do before playable. That and re-spawn players at their starting points when the ball drops, but that's not 100% nessecary.
I also need to set up a perforce for my collaborators. Last time I tried to do this it ended badly because there's already a perforce server in our subnet. I should talk to ricky about what he had to do to set this up.
No shame on this project, Gibbs rule #28: if you need help, ask.
Saturday, February 1, 2014
Lazy Saturday
Re-factored the camera, did some more proto-type art, got a run/jump/death cycle, etc. Looks better than the blocks I was using. At this point I want to:
A) Get a complete level-flow working from main menu to level completion
B) Finalize a good, fun, prototype level
C) Add enemies that can shoot back?
D) Get it on mobile for testing / playtest with some friends.
But currently have dinner plans, so I can't say much more than that.
It was kinda just lazy work, not bad.
A) Get a complete level-flow working from main menu to level completion
B) Finalize a good, fun, prototype level
C) Add enemies that can shoot back?
D) Get it on mobile for testing / playtest with some friends.
But currently have dinner plans, so I can't say much more than that.
It was kinda just lazy work, not bad.
Wednesday, January 29, 2014
Super Quick Update
Got the player restart and score stuff in. No stretch goals, not enough time!
More to follow tomorrow.
Peace, everyone.
More to follow tomorrow.
Peace, everyone.
Tuesday, January 28, 2014
D-D-D-Design work!
Tonight was very light on the tech side. I re-adjusted the PlayerBehavior system to have a "negative Effect" that starts only when the specified behavior is not in use (mostly so I could do some "beginning-to-fall" effects in gravity only after a jump has been released) which should prove to enable some more interesting behaviors down the road!
I banged out a few small art assets, and spent the majority of the night trying to find a way to make jumping and shooting feel good. I tried doing an additive approach, where jump-speed wasn't gained instantly and extended over time, and gravity took effect over time as well. I didn't like how that felt, so I tried an "instant-velocity" jump with a speed lerp at the peak of the jump and it's feeling a bit better. I might continue to tweak it to get the jump just so, since it will be an integral part of the game. Perhaps a parabolic jump equation? I've used such equations in games before, they're aesthetically pleasing but never end up being just how I want them to be. I should take a look at Super Meat Boy again, I really like the jump in that game, as a platformer it is without parallel. I also played around with varying heights of the jump. Once I identify a scale it will be easier to figure out such matters, though. Probably that should be a priority of mine.
I think I'm closing in on a feel, threw together a basic run and it got better towards the end of the evening. Think tomorrow I'll try doing some more art? Not sure yet. Once I get started on a task you can't stop me, but determining what the flow of those tasks are is the area I have the most difficulty with, especially since I only get 1-3 hour windows with which to work on the game. Hopefully becoming a more focused and plan-oriented programmer for these side projects can also help me maintain focus at work where external factors all play a role in messing with my flow (meetings, lunch, etc.)
Plan for next 2-hour programming block (hopefully tomorrow night though perhaps not)
-Visualize Score System (score visible, flavor text for destroying targets)
-Player Reset System(currently just destroys self, no-good)
-Design Stretch goals:
1) Finalize Scale
2) Complete minute-long prototype level
3) Implement "dropping" enemy
-Art Stretch goals:
1) Do player run cycle
2) Do gun aim/shoot cycle
3) Implement in-unity Animation editor
Night all. Back day tomorrow, still super sore from chest day and Jiu-jistsu. Bleh.
I banged out a few small art assets, and spent the majority of the night trying to find a way to make jumping and shooting feel good. I tried doing an additive approach, where jump-speed wasn't gained instantly and extended over time, and gravity took effect over time as well. I didn't like how that felt, so I tried an "instant-velocity" jump with a speed lerp at the peak of the jump and it's feeling a bit better. I might continue to tweak it to get the jump just so, since it will be an integral part of the game. Perhaps a parabolic jump equation? I've used such equations in games before, they're aesthetically pleasing but never end up being just how I want them to be. I should take a look at Super Meat Boy again, I really like the jump in that game, as a platformer it is without parallel. I also played around with varying heights of the jump. Once I identify a scale it will be easier to figure out such matters, though. Probably that should be a priority of mine.
I think I'm closing in on a feel, threw together a basic run and it got better towards the end of the evening. Think tomorrow I'll try doing some more art? Not sure yet. Once I get started on a task you can't stop me, but determining what the flow of those tasks are is the area I have the most difficulty with, especially since I only get 1-3 hour windows with which to work on the game. Hopefully becoming a more focused and plan-oriented programmer for these side projects can also help me maintain focus at work where external factors all play a role in messing with my flow (meetings, lunch, etc.)
Plan for next 2-hour programming block (hopefully tomorrow night though perhaps not)
-Visualize Score System (score visible, flavor text for destroying targets)
-Player Reset System(currently just destroys self, no-good)
-Design Stretch goals:
1) Finalize Scale
2) Complete minute-long prototype level
3) Implement "dropping" enemy
-Art Stretch goals:
1) Do player run cycle
2) Do gun aim/shoot cycle
3) Implement in-unity Animation editor
Night all. Back day tomorrow, still super sore from chest day and Jiu-jistsu. Bleh.
Sunday, January 26, 2014
Lazy Sunday Work
Didn't get nearly as much done today as I wanted to. I implemented a basic player tracking/scoring system build into anything that can take damage. Theoretically the level at this point could gain scores from killing the player? That could be a fun statistic to track.
Somehow Unity decided several of my files would get wiped so I spent a majority of my time re-writing code that mysteriously vanished. Lesson learned, installed perforce server on my machine, and I'll be using that from now on. I meant to do that for a while, anyway.
The scoring system works by having each player own a ScoreTracker, which reports back to a ScoreMaster at then end of a run/level. The ScoreMaster is a singleton, or what passes for one in Unity since I made it a MonoBehaviour, which I might go back and blow that away, but we'll see. I don't have any pressing need to make it a pure singleton at the moment.
ScoreMaster serializes records in/out upon load and save functions, standard affair. Every item in the game that can take damage is required to have a scoreable component on it, but scoreable components can be put on non-damageable objects as well. The basic scoreable component only adds value when the object is destroyed, though with an enum switch and a derived class it can be made to add score upon contact with certain classes, etc.
Nothing too exciting, didn't get a chance to work on any of the actual gameplay like I wanted too, or even get to the score visualizations. :(
Well, the girlfriend is gone this week so perhaps I can get a few really productive nights in after work! I'm still excited for this game, just sucked to have to re-write code for unknown reasons.
If I got to bed in the next 15 minutes I can get a whole 8 hours of sleep...! Fingers crossed.
Somehow Unity decided several of my files would get wiped so I spent a majority of my time re-writing code that mysteriously vanished. Lesson learned, installed perforce server on my machine, and I'll be using that from now on. I meant to do that for a while, anyway.
The scoring system works by having each player own a ScoreTracker, which reports back to a ScoreMaster at then end of a run/level. The ScoreMaster is a singleton, or what passes for one in Unity since I made it a MonoBehaviour, which I might go back and blow that away, but we'll see. I don't have any pressing need to make it a pure singleton at the moment.
ScoreMaster serializes records in/out upon load and save functions, standard affair. Every item in the game that can take damage is required to have a scoreable component on it, but scoreable components can be put on non-damageable objects as well. The basic scoreable component only adds value when the object is destroyed, though with an enum switch and a derived class it can be made to add score upon contact with certain classes, etc.
Nothing too exciting, didn't get a chance to work on any of the actual gameplay like I wanted too, or even get to the score visualizations. :(
Well, the girlfriend is gone this week so perhaps I can get a few really productive nights in after work! I'm still excited for this game, just sucked to have to re-write code for unknown reasons.
If I got to bed in the next 15 minutes I can get a whole 8 hours of sleep...! Fingers crossed.
Thursday, January 23, 2014
Two-hour update
Got about two solid hours in today on the game.
No art, unfortunately, but I got a healthy chunk of the core systems in. I have the systems in place that I want for the core of the game play experience, now it's just creating interesting test levels with them and testing the initial deployment for mobile devices (part of the end-target for the project)
All in all in those two hours I completed:
- [Fixed] Core single-button-multi-use systems and events for both press and release, with room for multiple different interpretations based on the sequence of the press. Might want to re-do this to allow for certain time-segment sequences to trigger different trees of behavior, could be interesting but I don't think I will want or need that functionality for the duration of this project. Cool idea to keep in mind should I eve try another single-button game.
- Core weapon systems. Press to begin the process of "aiming" after a jump and the gun will swing out from the "holster" and continue swinging to point straight up, release to fire at any angle in between.
- Core projectile class. Very simple, standard projectile shenanigans.
- Core damage-interaction systems. Unity3D works off of the idea of scripts or components being attatched to a single object. Imagine this to be somewhat similar to the Decorator pattern if you're not familiar with the idea of components, but with some differences that I will not get into now because I do not deem it worth the time of discussion and I really want to get to bed right now.
Essentially there is a component that can take damage, and a component that can give damage. They can exist on the same object (such as an enemy that can be hurt by the player's weapons but can damage the player if the player were unfortunate or masochistic enough to touch them) There's more to them than that, rules for when the damage taker and/or the take-ee are to report themselves as "finished" and ready to be destroyed, resistances for different damage types, limits to how much damage a take-ee can deal out, if that strength weakens over time or can only touch so many unique takers before it is deemed unusable, etc.
-Prototype level: Gets across the point, has plenty of targets, platforms, etc. to run players to and to tweak values to guns, player speeds, gravity, etc. Currently not super fun, which is not heartening, but I knew my values out of the box wouldn't feel so great, so plenty of time to tweak and continue with the idea.
Plus I tend to be highly critical of myself and my accomplishments, will release a more public prototype test this weekend to some friends to get better feedback.
TO-DO FOR NEXT WORK PERIOD (Likely Sunday)
-Expand prototype level (more targets, more platforms)
-Tweak player values (gravity, run speed)
-Tweak gun values (speed of "aiming" and projectile types, their speed, damage, falloff, adding in burst fire or shotguns, etc.)
-Preliminary art (not having everything being boxes)
No art, unfortunately, but I got a healthy chunk of the core systems in. I have the systems in place that I want for the core of the game play experience, now it's just creating interesting test levels with them and testing the initial deployment for mobile devices (part of the end-target for the project)
All in all in those two hours I completed:
- [Fixed] Core single-button-multi-use systems and events for both press and release, with room for multiple different interpretations based on the sequence of the press. Might want to re-do this to allow for certain time-segment sequences to trigger different trees of behavior, could be interesting but I don't think I will want or need that functionality for the duration of this project. Cool idea to keep in mind should I eve try another single-button game.
- Core weapon systems. Press to begin the process of "aiming" after a jump and the gun will swing out from the "holster" and continue swinging to point straight up, release to fire at any angle in between.
- Core projectile class. Very simple, standard projectile shenanigans.
- Core damage-interaction systems. Unity3D works off of the idea of scripts or components being attatched to a single object. Imagine this to be somewhat similar to the Decorator pattern if you're not familiar with the idea of components, but with some differences that I will not get into now because I do not deem it worth the time of discussion and I really want to get to bed right now.
Essentially there is a component that can take damage, and a component that can give damage. They can exist on the same object (such as an enemy that can be hurt by the player's weapons but can damage the player if the player were unfortunate or masochistic enough to touch them) There's more to them than that, rules for when the damage taker and/or the take-ee are to report themselves as "finished" and ready to be destroyed, resistances for different damage types, limits to how much damage a take-ee can deal out, if that strength weakens over time or can only touch so many unique takers before it is deemed unusable, etc.
-Prototype level: Gets across the point, has plenty of targets, platforms, etc. to run players to and to tweak values to guns, player speeds, gravity, etc. Currently not super fun, which is not heartening, but I knew my values out of the box wouldn't feel so great, so plenty of time to tweak and continue with the idea.
Plus I tend to be highly critical of myself and my accomplishments, will release a more public prototype test this weekend to some friends to get better feedback.
TO-DO FOR NEXT WORK PERIOD (Likely Sunday)
-Expand prototype level (more targets, more platforms)
-Tweak player values (gravity, run speed)
-Tweak gun values (speed of "aiming" and projectile types, their speed, damage, falloff, adding in burst fire or shotguns, etc.)
-Preliminary art (not having everything being boxes)
Tuesday, January 21, 2014
Mini-Jam
Over the next few days I'll be doing a mini-jam, with the limitation that I am only allowed to use one button for the control scheme.
Given the success of Divekick with a two-button mechanic I thought it would be a fun and interesting challenge to limit myself to only one button and see what depth/fun if any I can squeeze out of it. Plus, Adam ended up adding a whole lot of depth to Divekick with two buttons, and that game took us a good while, granted that was with art and GGPO, etc, but I figured one button would be pragmatic for a short-term game and prevent me from doing what I usually do with games, which is to severely overscope them.
I have the basic run/jump/shoot mechanics down, and the rough outline of the story, as per usual the timesink will most likely be art style and animation.
The story takes place in the daydreams of Freddie, a 4th grader with an overactive imagination and access to netflix at home, while he tries to make it through Spanish class. The current working name of the game is Uno Mas, a play on the fact you can only use one button. The story will be told through mostly incomprehensible Spanish, as I do not speak the language and Freddie is a thin allegory for myself at that age. Essentially he doesn't pay attention and instead transports himself into a non-stop action movie all told in a random mixture of Spanish words that sound close enough to Freddie.
The gameplay itself is being narrowed down, but as I said, it's a one-button game. As per Jetpack Joyride the game is a left-to-right sidescroller, first button causes Freddie to Jump, second causes him to draw his six-shooter, release of the second press causes him to shoot, and subsequent presses will each have their own special effect, to be determined and up to a certain limit (one can only press space so much while a character is in the air)
Art will likely just be my doodles, my only goal with art is to keep the style somewhat consistent and just not-awful.
Well, I got back day and a date tomorrow, so that's all for tonight! Likely won't get back to this until Thursday night.
Rest well, all!
Given the success of Divekick with a two-button mechanic I thought it would be a fun and interesting challenge to limit myself to only one button and see what depth/fun if any I can squeeze out of it. Plus, Adam ended up adding a whole lot of depth to Divekick with two buttons, and that game took us a good while, granted that was with art and GGPO, etc, but I figured one button would be pragmatic for a short-term game and prevent me from doing what I usually do with games, which is to severely overscope them.
I have the basic run/jump/shoot mechanics down, and the rough outline of the story, as per usual the timesink will most likely be art style and animation.
The story takes place in the daydreams of Freddie, a 4th grader with an overactive imagination and access to netflix at home, while he tries to make it through Spanish class. The current working name of the game is Uno Mas, a play on the fact you can only use one button. The story will be told through mostly incomprehensible Spanish, as I do not speak the language and Freddie is a thin allegory for myself at that age. Essentially he doesn't pay attention and instead transports himself into a non-stop action movie all told in a random mixture of Spanish words that sound close enough to Freddie.
The gameplay itself is being narrowed down, but as I said, it's a one-button game. As per Jetpack Joyride the game is a left-to-right sidescroller, first button causes Freddie to Jump, second causes him to draw his six-shooter, release of the second press causes him to shoot, and subsequent presses will each have their own special effect, to be determined and up to a certain limit (one can only press space so much while a character is in the air)
Art will likely just be my doodles, my only goal with art is to keep the style somewhat consistent and just not-awful.
Well, I got back day and a date tomorrow, so that's all for tonight! Likely won't get back to this until Thursday night.
Rest well, all!
Friday, January 3, 2014
Monday, June 4, 2012
Apex
Well,
Today we showed off capstone. After 20 weeks, it's over.* We set up the game to show in an old quasi-gutted church, plugged in the ol' laptop and let 'er rip.
Barring a few hiccups, it went flawlessly and people liked the game quite a bit. We figured out that Kinect and direct sunlight do not mix. At all. Bodies/body parts exposed to direct and/or intense sunlight won't be picked up by the Kinect. I know the Kinect works off of infrared light, beaming "lasers" out into space and measuring the diameters of said light sources, using that to determine depth. Something in the sunlight washes out those lights, perhaps the sun's own infrared emissions, but that's an just a partially-educated guess.
Long story short, the place we demoed the game in was not short of a whole lot of nice big windows that let the sun come streaming in, so after the first few playtesters we had to be moved to a different spaces simply so the game could run. I was somewhat crushed because the new room was set apart from the main testing area, but we managed to keep a good crowd despite that fact.
I managed to set up a high-score system about 30 minutes before the game was set to be tested that did the simple task of listing/retrieving and writing a list of high scores. It tracks all highscores, ever, which needs to be changed because that could get insane, but for the purposes of the day it preformed swimmingly, tracking the scores of every one of our 30 players today.
So, what went right, and what went wrong?
Today I'll be depressing and start with what went wrong: The game wasn't universally playable. The Kinect we brought with us refused to adjust it's elevation, which rendered it unplayable for one young boy and an excited mother who both wanted to try the game. To me, that was a bit of a soul-crusher. To our great professor, Brian Shrank, he simply adjusted the Kinect manually. A task which you are not supposed to do because it kills the motors and that's probably why our Kinect wouldn't adjust automatically in the first place.
The buttons that I spend Friday creating weren't super intuitive, we kept having to tell players how to pick them up and what to do with them, they need to be both smash-able and crush-able, without having to pick them up and then smash them back down. That, luckily, can be fixed.
Full screen mode has issues with computers other than my own, that was news to me.
Also, we are making one too many new calls in the game, somewhere. Despite the fact that C# is a managed language and therefore memory leaks are technically impossible, after an hour and half of straight running the sound began to cut in and out and sound terrible. The proposed problem of this would be that we ran out of virtual memory for our program. Or were constantly on the verge of running out before the garbage collector came by and ate up some sounds.
The problem with that is, I have no idea where to start trying to solve that issue aside from hunting down and eliminated as many new calls as possible, and even then I'm only guessing. The other possibility is that we went through too many levels, and David's great level-saving system hadn't let any of these assets go over the course of an hour+ cumulative game time, which includes the thousands of particles of blood and other effects that were generated throughout the course of the game. But this puppy also has about 6 gigs of Ram, if I remember correctly, which would be an insane amount of memory to take up. When we stopped the game, though, the physical memory capacity was around 43%, though. So there's that.
Okay, so now for what went good:
Aside from our two stranded players ( :( ) we had a lot of people play, and for me it was fun just to see people smile or laugh or even glare intensely at all of the little cavemen attacking their cave on the screen. People had fun, people said the game turned out well. If you know me well you know that, subconsciously at least, I yearn for validation for my work. I work hard, but I'm never sure of it's quality. That's not necessarily a good thing, but today really put me at ease, at least, because we achieved what we set out to do: Build an interesting, somewhat innovated and fun game that people would enjoy playing any way the played it.
The best was seeing friends play the game and how they reacted and played. My friend Majdi was my hands-down favorite, he played the entire game as if he was trying to sooth the cavemen instead of kill them. He was the gentle giant of the night, but watching him play made my day and hearing the banter between him and the crowd made my day, easily.
We did it, by golly we did it. I've done a lot of attempting in my life, and if there's anything that's difficult for me it's following through. Be it my swing in baseball, my techniques in Judo or the games I strive and love to create, I always start strong but end in a far worse position than I hoped for. Capstone was not easy, but I had a great team and great people to support me and finishing this game was one of the more difficult tasks I've ever tackled. And this is a game that I made with my friends from the ground up. There's not one brick or piece of duct-tape or staples that holds this game together that wasn't made by us, Team We're Okay, and the next wave of the gaming industry.
Sorry, I meant to say I HAVE a great team and great people supporting me.
Now... Back to programming! More games! Go, go, go!
-Kev
Today we showed off capstone. After 20 weeks, it's over.* We set up the game to show in an old quasi-gutted church, plugged in the ol' laptop and let 'er rip.
Barring a few hiccups, it went flawlessly and people liked the game quite a bit. We figured out that Kinect and direct sunlight do not mix. At all. Bodies/body parts exposed to direct and/or intense sunlight won't be picked up by the Kinect. I know the Kinect works off of infrared light, beaming "lasers" out into space and measuring the diameters of said light sources, using that to determine depth. Something in the sunlight washes out those lights, perhaps the sun's own infrared emissions, but that's an just a partially-educated guess.
Long story short, the place we demoed the game in was not short of a whole lot of nice big windows that let the sun come streaming in, so after the first few playtesters we had to be moved to a different spaces simply so the game could run. I was somewhat crushed because the new room was set apart from the main testing area, but we managed to keep a good crowd despite that fact.
I managed to set up a high-score system about 30 minutes before the game was set to be tested that did the simple task of listing/retrieving and writing a list of high scores. It tracks all highscores, ever, which needs to be changed because that could get insane, but for the purposes of the day it preformed swimmingly, tracking the scores of every one of our 30 players today.
So, what went right, and what went wrong?
Today I'll be depressing and start with what went wrong: The game wasn't universally playable. The Kinect we brought with us refused to adjust it's elevation, which rendered it unplayable for one young boy and an excited mother who both wanted to try the game. To me, that was a bit of a soul-crusher. To our great professor, Brian Shrank, he simply adjusted the Kinect manually. A task which you are not supposed to do because it kills the motors and that's probably why our Kinect wouldn't adjust automatically in the first place.
The buttons that I spend Friday creating weren't super intuitive, we kept having to tell players how to pick them up and what to do with them, they need to be both smash-able and crush-able, without having to pick them up and then smash them back down. That, luckily, can be fixed.
Full screen mode has issues with computers other than my own, that was news to me.
Also, we are making one too many new calls in the game, somewhere. Despite the fact that C# is a managed language and therefore memory leaks are technically impossible, after an hour and half of straight running the sound began to cut in and out and sound terrible. The proposed problem of this would be that we ran out of virtual memory for our program. Or were constantly on the verge of running out before the garbage collector came by and ate up some sounds.
The problem with that is, I have no idea where to start trying to solve that issue aside from hunting down and eliminated as many new calls as possible, and even then I'm only guessing. The other possibility is that we went through too many levels, and David's great level-saving system hadn't let any of these assets go over the course of an hour+ cumulative game time, which includes the thousands of particles of blood and other effects that were generated throughout the course of the game. But this puppy also has about 6 gigs of Ram, if I remember correctly, which would be an insane amount of memory to take up. When we stopped the game, though, the physical memory capacity was around 43%, though. So there's that.
Okay, so now for what went good:
Aside from our two stranded players ( :( ) we had a lot of people play, and for me it was fun just to see people smile or laugh or even glare intensely at all of the little cavemen attacking their cave on the screen. People had fun, people said the game turned out well. If you know me well you know that, subconsciously at least, I yearn for validation for my work. I work hard, but I'm never sure of it's quality. That's not necessarily a good thing, but today really put me at ease, at least, because we achieved what we set out to do: Build an interesting, somewhat innovated and fun game that people would enjoy playing any way the played it.
The best was seeing friends play the game and how they reacted and played. My friend Majdi was my hands-down favorite, he played the entire game as if he was trying to sooth the cavemen instead of kill them. He was the gentle giant of the night, but watching him play made my day and hearing the banter between him and the crowd made my day, easily.
We did it, by golly we did it. I've done a lot of attempting in my life, and if there's anything that's difficult for me it's following through. Be it my swing in baseball, my techniques in Judo or the games I strive and love to create, I always start strong but end in a far worse position than I hoped for. Capstone was not easy, but I had a great team and great people to support me and finishing this game was one of the more difficult tasks I've ever tackled. And this is a game that I made with my friends from the ground up. There's not one brick or piece of duct-tape or staples that holds this game together that wasn't made by us, Team We're Okay, and the next wave of the gaming industry.
Sorry, I meant to say I HAVE a great team and great people supporting me.
Now... Back to programming! More games! Go, go, go!
-Kev
Friday, May 25, 2012
Running Scared
For the first time in my academic career I'm genuinely frightened of the upcoming weeks.
That's heard a lot, I understand, and my friends and family are quick to point out that I have spoken such "nonsense" before. I stipulate, however, that this time is genuinely different at set apart from the previous set of experiences. I have only one final to study for. On the flip side, I have three monumental projects to complete... In a little under two weeks. Less, actually.
Capstone needs menus. Badly. I hate UI programming, but essentially that's one of the only things left on the list. It's time consuming and arduous, but absolutely, positively, painfully necessary
In multiplayer I still have zero idea if my theoretical networked code will run. I haven't been able to test it, I don't have access to another computer that can run the friggin' windows live that the project requires. The school computers are all out of date and I can't install or update them with Windows Live because I don't have administrative access, of course.
And I just barely got started with Graphics, which involves building an entire particle system utilizing the graphics card. This assignment is what has me sweating bullets, I got such a late start because of other factors in school and I have no idea what I'm doing and despite the academic papers I've read there is no authority on the subject that I can find with any sort of examples or "baby steps" to follow.
Ordinarily, I would relish the opportunity to learn something from complete scratch, however, given my time constraints and the fact that these final projects are huge portions of my grade I really can't afford to get stuck on ANY of my projects.
And I'm stuck on ALL of them. Capstone is bogged in UI, I have no clue what's happening in RenderGL, the "lovely" open-GL framework DePaul has (with shoddy documentation) and I can't even see where I stand in Multiplayer until I somehow get access to another computer.
And that doesn't even factor in my Calculus work, of which I have 5 outstanding assignments all given within the past week and a take-home quiz to complete.
...Check, please.
-Kev
That's heard a lot, I understand, and my friends and family are quick to point out that I have spoken such "nonsense" before. I stipulate, however, that this time is genuinely different at set apart from the previous set of experiences. I have only one final to study for. On the flip side, I have three monumental projects to complete... In a little under two weeks. Less, actually.
Capstone needs menus. Badly. I hate UI programming, but essentially that's one of the only things left on the list. It's time consuming and arduous, but absolutely, positively, painfully necessary
In multiplayer I still have zero idea if my theoretical networked code will run. I haven't been able to test it, I don't have access to another computer that can run the friggin' windows live that the project requires. The school computers are all out of date and I can't install or update them with Windows Live because I don't have administrative access, of course.
And I just barely got started with Graphics, which involves building an entire particle system utilizing the graphics card. This assignment is what has me sweating bullets, I got such a late start because of other factors in school and I have no idea what I'm doing and despite the academic papers I've read there is no authority on the subject that I can find with any sort of examples or "baby steps" to follow.
Ordinarily, I would relish the opportunity to learn something from complete scratch, however, given my time constraints and the fact that these final projects are huge portions of my grade I really can't afford to get stuck on ANY of my projects.
And I'm stuck on ALL of them. Capstone is bogged in UI, I have no clue what's happening in RenderGL, the "lovely" open-GL framework DePaul has (with shoddy documentation) and I can't even see where I stand in Multiplayer until I somehow get access to another computer.
And that doesn't even factor in my Calculus work, of which I have 5 outstanding assignments all given within the past week and a take-home quiz to complete.
...Check, please.
-Kev
Friday, May 11, 2012
The Little Things
Dr. Livingstone, I presume?
Yeah, it's been some time. Partially for good reasons, partially not. Tonight won't be a super long update, as I have a long day ahead of me tomorrow and It's currently 2:05 in the morning. Dang it, that was not supposed to happen.
And I haven't been up to anything productive, per se. I have a mountain of programming homework to tackle this weekend, and not enough time to do it. That being said, I spent 4+ hours this evening (maybe? I guess that's right, maybe more like 3 or 2) doing little tweaks to capstone. I fixed dumb things like a lag error in our particle effects. I knew what the problem was, or at least I had suspected, for some time but I had not acted on it. I finally got that out of the way today, which felt really satisfying. It was a simple problem, I had all of my object stored in a linked list (I have my justifications, I'm using C# which is a memory-managed language, it automatically reduces memory fragmentation and I get O(1) insertion/removal time with my method, don't anyone start telling me that Linked Lists can't have a O(1) removal or I'll keyboard-smack you harder than that one guy did in Wanted) but I did my removals in a rather stupid manner, e.g. yoinking any object calling for removal immediately, which didn't break, stop, or even halt the game. It would, however, halt the update of some of the other objects in that class group for just a fraction of a second. I don't know the exact specifics, but yanking from the linked list caused the rest of the linked list's update to be skipped or short-changed.
Long story short I threw in a small vector list that stored the positions of all of the to-be-removed nodes, and then AFTER all those happy-go-lucky nodes updated, I swept through the list and plucked out anything that needed to be removed. Problem solved in < 5 minutes.
And sometimes, as a programmer, you need that. I've been wrestling with bugs and problems for months, in some cases, I needed a small, polish task that I could get done and move onto the next one on the list. That just feels good. And I could use some moral boost.
I also took down a number of other small issues.
Apparently our background clouds were supposed to animate, I don't remember ever being told this, so perhaps I wasn't paying attention, but I threw the scrolling clouds in in a few minutes. I did some art-related exchanges, Justin got me the newly saturated sprites, which amped up the color and the overall aesthetic of our game immediately.
And... I completely forgot the other changes I've made. There were a number of them, again, only small, quick little tweaks, but stuff that felt good to put in and have just WORK and not complain at me.
-Kev
Yeah, it's been some time. Partially for good reasons, partially not. Tonight won't be a super long update, as I have a long day ahead of me tomorrow and It's currently 2:05 in the morning. Dang it, that was not supposed to happen.
And I haven't been up to anything productive, per se. I have a mountain of programming homework to tackle this weekend, and not enough time to do it. That being said, I spent 4+ hours this evening (maybe? I guess that's right, maybe more like 3 or 2) doing little tweaks to capstone. I fixed dumb things like a lag error in our particle effects. I knew what the problem was, or at least I had suspected, for some time but I had not acted on it. I finally got that out of the way today, which felt really satisfying. It was a simple problem, I had all of my object stored in a linked list (I have my justifications, I'm using C# which is a memory-managed language, it automatically reduces memory fragmentation and I get O(1) insertion/removal time with my method, don't anyone start telling me that Linked Lists can't have a O(1) removal or I'll keyboard-smack you harder than that one guy did in Wanted) but I did my removals in a rather stupid manner, e.g. yoinking any object calling for removal immediately, which didn't break, stop, or even halt the game. It would, however, halt the update of some of the other objects in that class group for just a fraction of a second. I don't know the exact specifics, but yanking from the linked list caused the rest of the linked list's update to be skipped or short-changed.
Long story short I threw in a small vector list that stored the positions of all of the to-be-removed nodes, and then AFTER all those happy-go-lucky nodes updated, I swept through the list and plucked out anything that needed to be removed. Problem solved in < 5 minutes.
And sometimes, as a programmer, you need that. I've been wrestling with bugs and problems for months, in some cases, I needed a small, polish task that I could get done and move onto the next one on the list. That just feels good. And I could use some moral boost.
I also took down a number of other small issues.
Apparently our background clouds were supposed to animate, I don't remember ever being told this, so perhaps I wasn't paying attention, but I threw the scrolling clouds in in a few minutes. I did some art-related exchanges, Justin got me the newly saturated sprites, which amped up the color and the overall aesthetic of our game immediately.
And... I completely forgot the other changes I've made. There were a number of them, again, only small, quick little tweaks, but stuff that felt good to put in and have just WORK and not complain at me.
Oh yeah, I threw in limbs, that was one thing. When a creep is hit so hard or has had so much damage dealt to him he simply explodes and a few limbs pop off and skitter across the screen, spraying blood as they go.
I love doing this, when it isn't slowly killing me!
I love doing this, when it isn't slowly killing me!
I don't have any doodles for you, unfortunately, not at the moment.
Hold on, I recently uploaded a whole batch! It's (possibly?) your lucky day.
(Apologies for any obscenities, I have a class that I really hate this quarter, and sometimes feelings are manifested into written words)
(Apologies for any obscenities, I have a class that I really hate this quarter, and sometimes feelings are manifested into written words)
-Kev
Friday, April 13, 2012
Crunch Mode
So it beings.
The beginning of the end. The last push, the final battle, down to the wire and everything is on the line.
Well, not yet, but it's getting close to being that time of the year, and my college career. That wasn't really supposed to rhyme, but for that you can blame David. For some unbeknownst reason he has the uncanny and awesomely hilarious ability to rhyme in the character of the Lorax. Yes, the one from the Dr. Suess book. Some of his friends are a little annoyed by it, but I am under the impression that it's downright hilarious. I wish I had that kind of quick mind to think of rhymes on the spot.
But there is a very good reason I'm in game design and development and not rapping, or singing, or majoring in math, or science, or business or medicine. Because I'm not good at all of those other things.
The current stance of the game is interesting. We are posed to submit to IndieCade to try and garner some attention for this little gem, but there are a bunch of hoops we have to jump through in order to get it submitted. Same goes for Zombie yoga, we are both pushing for the 15th deadline. Which is Sunday.
Yikes.
Better get crackin'
That, and on the rest of my homework. Multiplayer Game Development, which should not be left to the last day, math (yuck) and Graphics, which was taught rather poorly to me and has resulted in a confusing mess. I think I know what everything should be doing, but that doesn't mean it actually works according to plan.
This is no bueno.
Anyway, the game went through a small playtest on Thursday, and I think it went very well. We have a lot of good data from the test, but we also have a lot of work to do. I feel as if no game I ever work on will ever be finished, which is a very scary and discouraging thought. I've only ever finished one game. I've started many, but school and technical limitations have stopped the growth of many. When I taught myself programming, I hit a wall of knowledge and understanding. Now I'm hitting walls of time, priorities and some technical limitations. If I just had capstone, this game would be sailing along, but I have to balance this with many other competing factors, I think the end result will just be little to no sleep (it is darn well near two right now) because we want and we need this game to succeed. It won't bring in cash, and it was never supposed to. This game is out there to show that we can be innovative, that we can find the fun in anything and extract that and give it back to players in a great package, and that we can make games, and that we are good at it.
I added some things in recently, mostly a lot of playtest tweaks, but some new features such as earthquakes and combo systems. Brian is working on reducing and restricting the incoming enemy waves. Justin is working on a new batch of art for the change in story direction that fits our scaled-down version of the game.
Just talking about this makes me nervous now, I feel like I should always be working and never be relaxing anymore, I just can't afford to do something like that.
Man, I can't wait to get back to judo, I really need that back in my life...
SOS.
-Kev
The beginning of the end. The last push, the final battle, down to the wire and everything is on the line.
Well, not yet, but it's getting close to being that time of the year, and my college career. That wasn't really supposed to rhyme, but for that you can blame David. For some unbeknownst reason he has the uncanny and awesomely hilarious ability to rhyme in the character of the Lorax. Yes, the one from the Dr. Suess book. Some of his friends are a little annoyed by it, but I am under the impression that it's downright hilarious. I wish I had that kind of quick mind to think of rhymes on the spot.
But there is a very good reason I'm in game design and development and not rapping, or singing, or majoring in math, or science, or business or medicine. Because I'm not good at all of those other things.
The current stance of the game is interesting. We are posed to submit to IndieCade to try and garner some attention for this little gem, but there are a bunch of hoops we have to jump through in order to get it submitted. Same goes for Zombie yoga, we are both pushing for the 15th deadline. Which is Sunday.
Yikes.
Better get crackin'
That, and on the rest of my homework. Multiplayer Game Development, which should not be left to the last day, math (yuck) and Graphics, which was taught rather poorly to me and has resulted in a confusing mess. I think I know what everything should be doing, but that doesn't mean it actually works according to plan.
This is no bueno.
Anyway, the game went through a small playtest on Thursday, and I think it went very well. We have a lot of good data from the test, but we also have a lot of work to do. I feel as if no game I ever work on will ever be finished, which is a very scary and discouraging thought. I've only ever finished one game. I've started many, but school and technical limitations have stopped the growth of many. When I taught myself programming, I hit a wall of knowledge and understanding. Now I'm hitting walls of time, priorities and some technical limitations. If I just had capstone, this game would be sailing along, but I have to balance this with many other competing factors, I think the end result will just be little to no sleep (it is darn well near two right now) because we want and we need this game to succeed. It won't bring in cash, and it was never supposed to. This game is out there to show that we can be innovative, that we can find the fun in anything and extract that and give it back to players in a great package, and that we can make games, and that we are good at it.
I added some things in recently, mostly a lot of playtest tweaks, but some new features such as earthquakes and combo systems. Brian is working on reducing and restricting the incoming enemy waves. Justin is working on a new batch of art for the change in story direction that fits our scaled-down version of the game.
Just talking about this makes me nervous now, I feel like I should always be working and never be relaxing anymore, I just can't afford to do something like that.
Man, I can't wait to get back to judo, I really need that back in my life...
SOS.
Tuesday, April 10, 2012
Humbug.
Normally I get hyper-focused at around midnight.
I don't know what it is about this week but it has been a mixed bag of really awesome and really crappy events, all in all I feel very drained and unfocused right now. Spending almost my entire Easter Sunday trying to do math definitely did not help the matter at all.
And usually I eat quite a hefty amount. In the past week I don't think I've had more than two meals in a day.
Now, I understand that's plenty of food for a person to survive off of, but considering my usual amounts of consumption this is very low and perhaps not a bad sign of... something?
On top of that I got chewed out by one of my favorite professors today. The thing is I wasn't yelled at or reprimanded or given a stern warning or a bad grade or a bad critique. Instead he expressed his extreme concern about the progress of our game. That's a lot like your father sitting you down on the couch and explaining that he's not upset, he's just deeply disappointed in you. Then he leaves the room and all you can do is hang your head and feel utterly devastated.
It was pretty much like that. He was very concerned about my involvement in Zombie Yoga and if that will take over the Capstone project. I know he's right, I know I have to be careful about how I split and spend my time. But I'm giving all of my projects all that I have, I'm coding almost from sun up to sun down, especially now that my other shoulder is bum and I can't get out any of my code aggression in Judo.
I've been getting the small things wrong, bad variable names, bad values, not checking value ranges or forgetting basic features of IDE's and engines.
In my math class I'm flying through the examples the teacher gives with ease, but the homework has been thrashing my behind by being long and complicated.
Zombie Yoga had me smashing my head against the wall until just today where just barely in time for a playtest I got the new code in the game. Only to have it not work for our lead designer/professor, Doris. It worked for everyone else, but I couldn't even give Doris the ability to play her own game.
I had a small bug in the combo system that I've been developing for our Capstone Project that by all means should not have existed.
But I got Zombie Yoga working, I fixed the bug and within an hour or hour and half I had gotten the combo system visualized nicely and even added in features to the system in just 15 minutes. I just wish I could be intelligent and responsive all the time, instead of only every once in a while, and that I could put in enough quality work for Zombie Yoga and Capstone to co-exist peacefully on my plate of ever diminishing time.
In general, I feel like absolute garbage, and for even more reasons than just being sometimes-bad at what I love to do and then for disappointing one of my favorite professors, but that's all I'm going to get into here.
Bah Humbug.
-Kev
I don't know what it is about this week but it has been a mixed bag of really awesome and really crappy events, all in all I feel very drained and unfocused right now. Spending almost my entire Easter Sunday trying to do math definitely did not help the matter at all.
And usually I eat quite a hefty amount. In the past week I don't think I've had more than two meals in a day.
Now, I understand that's plenty of food for a person to survive off of, but considering my usual amounts of consumption this is very low and perhaps not a bad sign of... something?
On top of that I got chewed out by one of my favorite professors today. The thing is I wasn't yelled at or reprimanded or given a stern warning or a bad grade or a bad critique. Instead he expressed his extreme concern about the progress of our game. That's a lot like your father sitting you down on the couch and explaining that he's not upset, he's just deeply disappointed in you. Then he leaves the room and all you can do is hang your head and feel utterly devastated.
It was pretty much like that. He was very concerned about my involvement in Zombie Yoga and if that will take over the Capstone project. I know he's right, I know I have to be careful about how I split and spend my time. But I'm giving all of my projects all that I have, I'm coding almost from sun up to sun down, especially now that my other shoulder is bum and I can't get out any of my code aggression in Judo.
I've been getting the small things wrong, bad variable names, bad values, not checking value ranges or forgetting basic features of IDE's and engines.
In my math class I'm flying through the examples the teacher gives with ease, but the homework has been thrashing my behind by being long and complicated.
Zombie Yoga had me smashing my head against the wall until just today where just barely in time for a playtest I got the new code in the game. Only to have it not work for our lead designer/professor, Doris. It worked for everyone else, but I couldn't even give Doris the ability to play her own game.
I had a small bug in the combo system that I've been developing for our Capstone Project that by all means should not have existed.
But I got Zombie Yoga working, I fixed the bug and within an hour or hour and half I had gotten the combo system visualized nicely and even added in features to the system in just 15 minutes. I just wish I could be intelligent and responsive all the time, instead of only every once in a while, and that I could put in enough quality work for Zombie Yoga and Capstone to co-exist peacefully on my plate of ever diminishing time.
In general, I feel like absolute garbage, and for even more reasons than just being sometimes-bad at what I love to do and then for disappointing one of my favorite professors, but that's all I'm going to get into here.
Bah Humbug.
-Kev
Saturday, April 7, 2012
On Screwing Things Up
Mix of code-related and life-related postings today! Mostly because I'm at similar junctures in both, or at least that's the way it feels.
First the code stuff, since that is the purpose of there 'ere blog in the first place.
If you asked me what my favorite part of programming was, I'd say it would be creating new and fascinating worlds, and learning how to do so in a faster, better, and more intelligent way. If you took a look at what I do mostly when coding, it would appear that my favorite coding pastime would be screwing things up. Most of the time, it's intentionally too. I have a system in place, it works, it preforms as I need to, and I won't be happy with it. I'll tell myself it could be more flexible, it could be faster, it could be more abstract, so I intentionally break it and try to rebuild it.
First lesson of the day, if it ain't broke, don't fix it.
Second lesson of the day, if you really want to fix something, start fresh and don't try and mold what you have into what you want to be (at least coding-wise, I'm not saying find a new girlfriend or wife, relationships don't work like programming stuffs... I don't think, it's been a while)
Molding the old to fit the new is a bigger pain in the rear than starting over. That stands true for most anything, unless, perhaps, if its and entire huge project. Even then, though, starting fresh is beginning to grow on me.
All I wanted to do was make the combo system I have more flexible, account for more options and situations. So I had to make a bunch of changes that killed the system, so I couldn't test iteratively (misspelling? Not sure) and I had already propagated said system throughout the rest of my code, so I had to hunt down those spaces and make changes as well.
Then, when I had it working...
Perforce overwrote it all. There were conflicts in the files that needed to be changed, so I went to press resolve and instead hit revert. I spent all afternoon on this instead of my homework, and now I have nothing to show for the day. Wonderful feeling, enough to make me sick to my stomach!
The thing about coding is, however, I'm rarely afraid of screwing things up. The lessons I have learned in coding don't always seem to apply to my life lessons. It's the same reality, though. If you really screw things up in your code, or in your life, it's going to suck. There's no getting around that fact, it is going to be terrible. But it's not going to be the death of you. Unless your mistake was crossing a mod boss or pressing the "do not press" button at a secret government facility. In which case you probably killed us all. Thanks.
My issue IRL is that I'm usually too cautious and concerned about making a mistake and suffering the consequences that I move in order to stalemate decisions instead of actually making them. The problem is life moves forward, and if you keep side stepping you never actually get anywhere. Even falling on your face is getting you headed in the right direction. Take your pick, martial arts, relationships, other life choices, etc. I don't want to fail, so I rarely take the risk to succeed.
This must stop. Just treat life like a program, plug your nose and dive in. You're going to come out on the other side with experience, at the very least, and that's what makes up your life, a collection of experiences and stories to relive, relate, and pass on.
As they say, go hard or go home.
Though I wouldn't mind being home for Easter.
-Kev
First the code stuff, since that is the purpose of there 'ere blog in the first place.
If you asked me what my favorite part of programming was, I'd say it would be creating new and fascinating worlds, and learning how to do so in a faster, better, and more intelligent way. If you took a look at what I do mostly when coding, it would appear that my favorite coding pastime would be screwing things up. Most of the time, it's intentionally too. I have a system in place, it works, it preforms as I need to, and I won't be happy with it. I'll tell myself it could be more flexible, it could be faster, it could be more abstract, so I intentionally break it and try to rebuild it.
First lesson of the day, if it ain't broke, don't fix it.
Second lesson of the day, if you really want to fix something, start fresh and don't try and mold what you have into what you want to be (at least coding-wise, I'm not saying find a new girlfriend or wife, relationships don't work like programming stuffs... I don't think, it's been a while)
Molding the old to fit the new is a bigger pain in the rear than starting over. That stands true for most anything, unless, perhaps, if its and entire huge project. Even then, though, starting fresh is beginning to grow on me.
All I wanted to do was make the combo system I have more flexible, account for more options and situations. So I had to make a bunch of changes that killed the system, so I couldn't test iteratively (misspelling? Not sure) and I had already propagated said system throughout the rest of my code, so I had to hunt down those spaces and make changes as well.
Then, when I had it working...
Perforce overwrote it all. There were conflicts in the files that needed to be changed, so I went to press resolve and instead hit revert. I spent all afternoon on this instead of my homework, and now I have nothing to show for the day. Wonderful feeling, enough to make me sick to my stomach!
The thing about coding is, however, I'm rarely afraid of screwing things up. The lessons I have learned in coding don't always seem to apply to my life lessons. It's the same reality, though. If you really screw things up in your code, or in your life, it's going to suck. There's no getting around that fact, it is going to be terrible. But it's not going to be the death of you. Unless your mistake was crossing a mod boss or pressing the "do not press" button at a secret government facility. In which case you probably killed us all. Thanks.
My issue IRL is that I'm usually too cautious and concerned about making a mistake and suffering the consequences that I move in order to stalemate decisions instead of actually making them. The problem is life moves forward, and if you keep side stepping you never actually get anywhere. Even falling on your face is getting you headed in the right direction. Take your pick, martial arts, relationships, other life choices, etc. I don't want to fail, so I rarely take the risk to succeed.
This must stop. Just treat life like a program, plug your nose and dive in. You're going to come out on the other side with experience, at the very least, and that's what makes up your life, a collection of experiences and stories to relive, relate, and pass on.
As they say, go hard or go home.
Though I wouldn't mind being home for Easter.
-Kev
Thursday, April 5, 2012
Rehash, Reuse, Recycle... Recreate.
Whoa nelly are there some awesome things to post about today. Kinda/sorta. Actually I'm not allowed to talk about most of them... Which means I'm potentially on the right track for game development if I am being included in hush-hush things. Suffice to say, I really want to spill the beans about awesome stuff, but it's mind over matter, sorry everybody, I can't do that.
In vague terms, though, I can say that Kinect is making leaps and bounds within Zombie Yoga, and as of a few minutes ago I got the new pose system that David and I have dreamed up working full throttle in our C# version of the code, and now we finally have a way to get this code ported over into the game engine so Kinect plays nice with the rest of the game.
But seriously, it wasn't a bad system... if you didn't have a lot of poses to check and everyone in the whole wide world was the same size.
We solved a lot of our problems pretty ingeniously, we had a complex yet effective means of eliminating "bad" poses when checking a player's pose, using outlying points to quickly scan through a list of poses and almost recursively loop through down these outlying points into the center positions (hip location and shoulder location, etc), each pass eliminating more and more poses until just one pose remained.
We also had a trick in terms of scaling the poses to be adjusted to the player's individual size. We got a calibration before the player began the game, and compared these limb lengths with that stored in our pose data. Every posed we had queued up then had it's limbs scaled appropriately, according to the calibration we just took and the calibration of the original yogi.
In vague terms, though, I can say that Kinect is making leaps and bounds within Zombie Yoga, and as of a few minutes ago I got the new pose system that David and I have dreamed up working full throttle in our C# version of the code, and now we finally have a way to get this code ported over into the game engine so Kinect plays nice with the rest of the game.
And, as I mentioned in my other shorter post, David and I received affirmation that we are not, how you say, doin' it wrong when it comes to the Kinect. Lots of people are hacking away at this thing just to get it to work, and currently the best and easiest way to do this is... however you see fit, however you can fit it, however you can get it. Anyway you want it, that's the way you need it... fill in the rest! And our new system, though not thoroughly tested yet (It's just been me our little (yet huge... it's a funny room) studio apt. trying some whacky poses. So far it's more forgiving (which, when it comes to the Kinect can be a good thing) and easier, which is all that we ever really wanted.
How does our new system work as opposed to our old? Well, for starters our old system was based off of joint proximity, how close one joint was to the other. That's all that's needed, right? Well several problems arise from this, stop me if you've heard this before. Or... I guess skip to the next section unless you can communicate telepathically with me RIGHT NOW. Oops, you are reading this, I posted it, too late.
But seriously, it wasn't a bad system... if you didn't have a lot of poses to check and everyone in the whole wide world was the same size.
We solved a lot of our problems pretty ingeniously, we had a complex yet effective means of eliminating "bad" poses when checking a player's pose, using outlying points to quickly scan through a list of poses and almost recursively loop through down these outlying points into the center positions (hip location and shoulder location, etc), each pass eliminating more and more poses until just one pose remained.
We also had a trick in terms of scaling the poses to be adjusted to the player's individual size. We got a calibration before the player began the game, and compared these limb lengths with that stored in our pose data. Every posed we had queued up then had it's limbs scaled appropriately, according to the calibration we just took and the calibration of the original yogi.
This system, however, only worked in practice. Kinect kept stepping in and kicking our butts, either by having a bad value during calibration (Left Hip was once (-infinity, 5, 5)...) or by it's lovely method of "inferring" joints. Kinect doesn't always know exactly where your joint's are, it gets a rough guesstimate (Better than nothing!) but at times this could result in limb shortening or lengthening in the 3D skeleton data.. which is fine, if everyone's body types got this limb shortening at the same time for the same poses, but they don't. So when the scaling was introduced with certain poses it would screw the rest of the data up by this limb shortening/lengthening putting the Yogi's original joints in strange, wild places.
There's ALSO the issue of player offset. The Kinect returns joint locations as position in 3D Cartesian space (X,Y,Z, think graphing, remember High School math? Yeah, you DO end up using it for something) in terms of meters from the Kinect. Which means if I'm in pose A and I'm a foot to the left of where our Yogi originally had the pose captured, then you would not be in the correct position.
This was a relatively easy fix, if you know vector math or understand 3D coordinate space all we did was make each of the joints relative to the center hip, or took each joint position and subtracted the center hip to make everything in "local space" as opposed to Kinect space.
There's ALSO the issue of player offset. The Kinect returns joint locations as position in 3D Cartesian space (X,Y,Z, think graphing, remember High School math? Yeah, you DO end up using it for something) in terms of meters from the Kinect. Which means if I'm in pose A and I'm a foot to the left of where our Yogi originally had the pose captured, then you would not be in the correct position.
This was a relatively easy fix, if you know vector math or understand 3D coordinate space all we did was make each of the joints relative to the center hip, or took each joint position and subtracted the center hip to make everything in "local space" as opposed to Kinect space.
Add, on top of this, the fact that Kinect loses your joints. This is not a matter of if, but when. The Kinect does great considering the fact that it's pretty much still just reading one dimension. The problem is the minute things (read: limbs) start obscuring body parts, the Kinect beings to give it's best guesses as to where things are, which end up being really awful guesses. So half (more than half, at this point, actually) of our poses involved a very three-dimensional stance. Warrior One, and Warrior Two. Google them. Have safe search on, too. You shouldn't need to, but I found out the hard way the other day that even something as innocuous and/or nerdy as C-strings (an oldschool format for printing lines of text in C) can give you very, very, very uncomfortable results. Here's a hint, don't ever google c-strings.
Holy smokes that's a lot of workarounds Batman! Why in the world did you do that?
Well considering Kinect only gives joint position and not rotation, it appeared to be the most straightforward and logical solution. And in certain circumstances this would be the ideal solution. For a small number of poses, if we had all of the tech we wanted down (appropriate body scaling, effective elimination system and not Kinect giving us random bad data) it actually could have been a good and flexible system. It's highly accurate, pose definitions could be kept as tight;y or as loosely defined as we wanted to specify. It's static, but that's all we needed for poses. Before we got into the muck and mire of Kinect work, it seemed like a flawless plan.
Given what I know now, I'd go back in time and throw my past self out of a very tall building to save him pain, agony, and sleepless nights.
So what's the new system? The new system is a combination of several different things that we thought were "hacks" but tend to actually be industry standard. That is to say fake everything.
We combine a pose flag system, which is just a fancy programmer way of saying we store a lot of true/false (or binary) values in a single integer (4 bytes = 32 bits, each bit can be a 0 or 1, giving us 32 compact and easily comparable true/false values) that tell us information such as
Holy smokes that's a lot of workarounds Batman! Why in the world did you do that?
Well considering Kinect only gives joint position and not rotation, it appeared to be the most straightforward and logical solution. And in certain circumstances this would be the ideal solution. For a small number of poses, if we had all of the tech we wanted down (appropriate body scaling, effective elimination system and not Kinect giving us random bad data) it actually could have been a good and flexible system. It's highly accurate, pose definitions could be kept as tight;y or as loosely defined as we wanted to specify. It's static, but that's all we needed for poses. Before we got into the muck and mire of Kinect work, it seemed like a flawless plan.
Given what I know now, I'd go back in time and throw my past self out of a very tall building to save him pain, agony, and sleepless nights.
So what's the new system? The new system is a combination of several different things that we thought were "hacks" but tend to actually be industry standard. That is to say fake everything.
We combine a pose flag system, which is just a fancy programmer way of saying we store a lot of true/false (or binary) values in a single integer (4 bytes = 32 bits, each bit can be a 0 or 1, giving us 32 compact and easily comparable true/false values) that tell us information such as
"Are the player's hands above his head?"
"Are the player's hands togther?"
"Is the Right hand forward?"
"Are the player's hands togther?"
"Is the Right hand forward?"
and etc. to ad infinitum.
(Actually only to 32!)
These are our first test. The really sweet thing about bit flags is that comparison between multiple true/false values is really simple and really fast. So we use the pose flags as our first order of elimination. A pose has a specific set of these very general flags that must be true in order for the player to be in the given pose. Just because the player's left foot and hand are forward doesn't mean that they are in Warrior Two, but it certainly means they aren't in Tree Pose or Warrior One.
This is fast elimination and means we don't have to use that really complicated (and expensive) distance-check for each joint location (lota joints x lota poses = big slow down) To be fair, David had begun implementing the pose flags system in our old game too, but problems plagued that implementation, starting fresh really helped us out.
Then after that we ditch position. Position data means nothing to us, now, we use the positions of joints to get the angular distance between them, and nothing more.
This is achieved by getting the dot product between two normalized vectors. The result is the cosine of the angle between the vectors. We take these dot products at the main joints, the elbows and knees. The second phase is checking the these joint angles (anywhere between 0 degrees, the limb is straight, and 180 degrees, which technically is impossible for the human body, but that's the limb bent all the way back so that, say, your wrist is pointing in the exact opposite direction of your elbow) so that means Warrior Two is defined by the fact that, say, your right hand and leg are forward, your right elbow's angle is 0 degrees (or a dot product of 1) and your right knee is around 90 degrees or so (dot product of 0)
This is a terrible approximation, don't attempt those exact angles or you might suffer some joint strain, but you get the idea.
Now that's getting closer, but as you can imagine that still leaves a fair amount of wiggle room. Or far too much forgiveness. I could turn my torso so that my hands are pointing off at angles, but the angle between my bicep and forearm is still the same amount, and my right hand is still in front of my body, I'm just all twisted up. The last layer on the triple chocolate cake is another dot product, but this time it's in terms of the proximal extremities. Basically where your biceps and quads point. We take these and change them into normalized vectors, and then also store these in our pose file. When you the player are trying to get into a pose, we check the direction of your biceps/quads and see if they match, or are close enough too, the original pose file's directions. This ensures that players are keeping, generally, the correct form and are facing all the correct directions, etc.
There's still wiggle room, but at this point we've eliminated the major stuff. And the nice part about working with pose flags and angles is that they are all relative. Pose flags get set by comparing positions in the skeleton itself. Is the Z value of this greater than the Z value of that? It's relative, it scales with the person playing. Same can be said of the angles. Barring the few possible exceptions, people have the same degrees of motion, and, if you remember trigonometry, angles are independent of size. A 60-30-90 triangle can be infinitesimally small, or colossally large. Same applies to the person on the other end of the Kinect. As long as they fit in the Kinect's FOV (Field Of View) then the angles between their limbs and the directions of their limbs are independent of size and it makes no difference to the Kinect.
We eliminated our scaling and our too-hardcore accuracy problems by a base shift in how we work with the Kinect. Our new system still needs to be thoroughly tested, but it's already been easier to set up and work with than our previous iteration.
Professor Ed Keenan is right, don't be afraid to throw away code, and throw it away often. You build something, it kind of works, delete the code and start over with a better understanding and I guarantee that you will have a better and easier time dealing with the code than if you try and forge through with your old base code. Again, their are exceptions to every rule, but I used to never do that, thinking it was a cardinal sin. Well, I've only just started, but it's helped tremendously.
This is fast elimination and means we don't have to use that really complicated (and expensive) distance-check for each joint location (lota joints x lota poses = big slow down) To be fair, David had begun implementing the pose flags system in our old game too, but problems plagued that implementation, starting fresh really helped us out.
Then after that we ditch position. Position data means nothing to us, now, we use the positions of joints to get the angular distance between them, and nothing more.
This is achieved by getting the dot product between two normalized vectors. The result is the cosine of the angle between the vectors. We take these dot products at the main joints, the elbows and knees. The second phase is checking the these joint angles (anywhere between 0 degrees, the limb is straight, and 180 degrees, which technically is impossible for the human body, but that's the limb bent all the way back so that, say, your wrist is pointing in the exact opposite direction of your elbow) so that means Warrior Two is defined by the fact that, say, your right hand and leg are forward, your right elbow's angle is 0 degrees (or a dot product of 1) and your right knee is around 90 degrees or so (dot product of 0)
This is a terrible approximation, don't attempt those exact angles or you might suffer some joint strain, but you get the idea.
Now that's getting closer, but as you can imagine that still leaves a fair amount of wiggle room. Or far too much forgiveness. I could turn my torso so that my hands are pointing off at angles, but the angle between my bicep and forearm is still the same amount, and my right hand is still in front of my body, I'm just all twisted up. The last layer on the triple chocolate cake is another dot product, but this time it's in terms of the proximal extremities. Basically where your biceps and quads point. We take these and change them into normalized vectors, and then also store these in our pose file. When you the player are trying to get into a pose, we check the direction of your biceps/quads and see if they match, or are close enough too, the original pose file's directions. This ensures that players are keeping, generally, the correct form and are facing all the correct directions, etc.
There's still wiggle room, but at this point we've eliminated the major stuff. And the nice part about working with pose flags and angles is that they are all relative. Pose flags get set by comparing positions in the skeleton itself. Is the Z value of this greater than the Z value of that? It's relative, it scales with the person playing. Same can be said of the angles. Barring the few possible exceptions, people have the same degrees of motion, and, if you remember trigonometry, angles are independent of size. A 60-30-90 triangle can be infinitesimally small, or colossally large. Same applies to the person on the other end of the Kinect. As long as they fit in the Kinect's FOV (Field Of View) then the angles between their limbs and the directions of their limbs are independent of size and it makes no difference to the Kinect.
We eliminated our scaling and our too-hardcore accuracy problems by a base shift in how we work with the Kinect. Our new system still needs to be thoroughly tested, but it's already been easier to set up and work with than our previous iteration.
Professor Ed Keenan is right, don't be afraid to throw away code, and throw it away often. You build something, it kind of works, delete the code and start over with a better understanding and I guarantee that you will have a better and easier time dealing with the code than if you try and forge through with your old base code. Again, their are exceptions to every rule, but I used to never do that, thinking it was a cardinal sin. Well, I've only just started, but it's helped tremendously.
Delete old code. Re-work it. You get better, faster, and the end result makes more sense.
TL;DR, I know, sorry, no doodles for now, it's 0230, I need to sleep before class tomorrow.
And finish that math homework.
Fiddlesticks.
And finish that math homework.
Fiddlesticks.
-Kev
Tuesday, April 3, 2012
Late Night Lovin'
Okay, I'll be the first to admit that's a terrible name for a blog post.
Regardless, let's take a look at what I've done in the past week or so:
Watched all of the Game Of Thrones.
Watched Girl With The Dragon Tattoo.
Hung out with friends a lot.
Watched all of the Game Of Thrones.
Watched Girl With The Dragon Tattoo.
Hung out with friends a lot.
Celebrated Ricky's birthday.
Uh, wait... I programmed in there somewhere, right?
Yes, a little bit. I fixed a massive processor-sink known as the "pit of constant memory allocation"
Our game has these really awesome scores that pop up when you hit guys and deal damage, and I worked my butt off creating a really dynamic (if a little costly) means of adding in our own sprite fonts, since I find XNA's defaults to be... messy. Limiting. Primitive. Primordial. Neanderthal. Really not cool.
The default sprite-fonts in XNA are not nearly as bad as I've made them out to be, but there were a number of limitations that caused me to balk at using them.
Yes, a little bit. I fixed a massive processor-sink known as the "pit of constant memory allocation"
Our game has these really awesome scores that pop up when you hit guys and deal damage, and I worked my butt off creating a really dynamic (if a little costly) means of adding in our own sprite fonts, since I find XNA's defaults to be... messy. Limiting. Primitive. Primordial. Neanderthal. Really not cool.
The default sprite-fonts in XNA are not nearly as bad as I've made them out to be, but there were a number of limitations that caused me to balk at using them.
-They required the computer to have the fonts pre-installed or packaged with the game (not that bad.)
-They require you to use and allocate and entirely different font if you wanted to change the font size! (Kinda but bad, again, a good programmer can create systems to allow them to easily make up for these, creating an array of sprite fonts at different font sizes to allow for rapid font-switching)
-Creating your own font meant learning how to create fonts according to standards (The equivalent of asking for directions, which guys never do. ...Right? Wait, why don't we do that?)
-To my knowledge, you couldn't do cool things like rotation and flexible scaling.
Looking back, it would have been far, far easier to just implement a system that simply didn't try and deal with dynamic rotation and scaling. But I will not be dissuaded from my goal. I crafted a system that lets a person use an image to specify a new font (adding it in is rather tedious, though) and after it's been added any string can be created and scaled, rotated, color changed, it can check for collisions and evra'thang! The way it does this isn't necessarily great, it creates a new texture2d for every unique string generated, but stores all previously generated strings in a lovely hash-table for quick look up and grabbing the next time the same string wishes to be generated. This resets every time the game runs, so in theory a dedicated programmer could pre-populate his list of textures with his desired strings and lookup would run just that much faster! Hooray!
Anyway, the long point of my story was that I was generating a bunch of new calls to create these little effects that called my sprite font, created themselves and then deleted themselves within a hot second (literally) and then sat around, presumably on some duvet somewhere in the lobby of lost memory allocations, smoking a cigar illegally or drinking heavily, waiting for the Garbage collector to come along, and when he did, boy would he have a lot of work to do. Which causes the game to lag hardcore for a few miliseconds, and then return to normal.
Can't have that, that's just bad practice. If games like Borderlands can run at 60fps (or near to it) on my computer then there is absolutely no excuse for my 2D game to lag.
Can't have that, that's just bad practice. If games like Borderlands can run at 60fps (or near to it) on my computer then there is absolutely no excuse for my 2D game to lag.
Aside from that, I've just done some work on the score system, creating examples for Brian and making sure that it's at least visualized partially for upcoming playtests.
W00t w00t.
-Kev.
Oh yeah, you came for pictures, didn't you?
 |
| Cousin Collaboration |
 |
| Guaranteed to solve most problems. |
Friday, March 30, 2012
New Post, new strategy
Hello everyone,
I'm going to be trying a new strategy to the blog, it will mean my posts are more frequent, but possibly that makes them less interesting. Aside from my "usual content" I will be posting "engine maintenance" content, just a log, essentially, detailing the changes made to Princess throughout the course of a day. This is mostly to help me (how selfish of me) keep track of everything that I've done, to what file and why, because future Kevin is going to want to know what in the world past Kevin was thinking, guaranteed.
So what have I done today? I've tightened up Kinect a little bit.
"But Kevin," you ask, "You've been saying that for months! How much tightening can possibly be left?!"
Let's just say I'm the personal trainer of a morbidly overweight technology. There's a whole lot more tightening that can be going on here!
But I did do work, so to speak. I've kind-of-sort-of-maybe finally adopted a new method of looking at my hand "point cloud" that seems to work well enough for my needs. Taking (slight) inspiration from calculus, I changed my method of storing my cloud points as elements of the X-axis (each x-axis spot has a small list of Y-axis positions)
From there its quite simple, I split the cloud into bottom-max values and top-max values (Y-axis) I check for valleys and peaks (derivatives, anyone?) and If I get a certain amount of peaks and valleys in my point cloud I assume this is "fingers" and then my problem is solved.
What if the person has the hand to the side? And their fingers didn't point up or down? I also check the number of points on the given Y axis, any more than four (at least one gap) then I, again, declare the hand to be "open"
Again, are there are ways to do this better, but I want it done FAST, so if I can hit all of this in just one or two passes, I am a happy man, and I can devote my time elsewhere to gameplay programming. Had a friend of mine, Ozzy, test the game rather unplanned, which confirmed to me that: The hand opening/closing is "good enough"
It needs more work, but it's good where it is at. Will I work on it more? You bet, I'm a perfectionist when it comes to, well, random things, but this Kinect is one of the areas I always feel I need to improve at. And so I shall, but it's now officially on the back burner of the project.
Ozzy also showed me a degenerate strategy I'll have to talk with Brian about. One of the coolest parts of our game is the "smashing" feature, it's simple, but fun, if you have guys in your hand and then bring your hands together, they get crushed and blood spews everywhere, it's an insta-kill. However, it's also entirely possible to pick guys up and clap your hands together rapidly, just hovering guys above the ground and as such simply kill attackers left and right without rhyme or reason.
So that must be remedied, but overall we need to reign in the number of our attackers. Too many guys on the screen doesn't make for what feels like good gameplay, just really hectic arm-waving. Brian and I talked it over, we're going to try to lower the enemy count but raise the health and see if that helps maintain the difficulty but makes the game more about having fun smacking guys around a lot.
I'm also thinking about bringing back the "close hand to grab" functionality, at least temporarily to see if, now that Kinect is a little bit nicer, it brought anything to the gameplay.
I also implemented a quick pausing system that pauses the game if you are "interrupted" or step out of frame it pauses the game and allows you to step back in, quit or resume the game. It's not perfect, for some reason the draw order for the pause is out of whack, but it works and it's something that I had been meaning to do for a while.
The next few things I want to nail down is a more efficient system for the numbers popping up every time you hit enemies, it really can slow the game down for a bit if there are a lot of enemies on screen, and.. dang it, I just forgot. Well, I'm sure it will come to me in time.
I actually have a lot left to do.
- Background displays village and enemies leaving village (think the "what's coming next" indicator in Tetris)
- Kinect Wide-gestures (earthquakes, etc)
- Finish up scoring sytstem/hit tracking/combo recognition (base system is in place, I want the visualization to be there)
- Tweak Kinect every so slightly if time permits.
- Add catapult men. (Sssh! it's a secret!)
- Add more sounds and some music
- Many more things I am forgetting right now.
That doesn't seem like a lot, even to me, but I know things will be much harder than they seem, and I am missing a number of different tasks.
We also need some awesome intro cutscenes or something similar. We are re-working elements of the story to be a little more cohesive with what we've got. We shall see how that goes, we have to be very careful now, the difference between an okay game, a good game, and a great game is how it all comes together. We've got the art, we've got the design, I'm holding the program together with staples and superglue, it's good. We need it to be great.
Okay, that was my Coach-Carter moment.
Elsewhere in the world I finished my Delaunay Triangulator by complete accident. Well, not entirely, I scrapped all of my old code that I had because it was just not working and I couldn't figure out why. I re-did the code in a much cleaner and simpler fashion... and it still didn't work.
Then I changed the order of the vertex creation in new triangles and... lo and behold it worked. A seemingly random and insignificant matter as the specified order of vertices in a new triangle makes or breaks the algorithm... yet I followed it to the T, and there was no mention of vertex-dependent order? Did I still do something wrong? I have no idea, but boy am I glad there are only 3 verts in a triangle or I would have never figured it out by moving random stuff around. Which is how I come to a find many a solution in my code. It means I'm always 98% right and 2% wrong... but being 2% wrong still means you are wrong in programming and logic... and math. Most especially math.
Can't be wrong, must improve.
Must maths, must programs, must logics, must succeeds.
I'm going to be trying a new strategy to the blog, it will mean my posts are more frequent, but possibly that makes them less interesting. Aside from my "usual content" I will be posting "engine maintenance" content, just a log, essentially, detailing the changes made to Princess throughout the course of a day. This is mostly to help me (how selfish of me) keep track of everything that I've done, to what file and why, because future Kevin is going to want to know what in the world past Kevin was thinking, guaranteed.
So what have I done today? I've tightened up Kinect a little bit.
"But Kevin," you ask, "You've been saying that for months! How much tightening can possibly be left?!"
Let's just say I'm the personal trainer of a morbidly overweight technology. There's a whole lot more tightening that can be going on here!
But I did do work, so to speak. I've kind-of-sort-of-maybe finally adopted a new method of looking at my hand "point cloud" that seems to work well enough for my needs. Taking (slight) inspiration from calculus, I changed my method of storing my cloud points as elements of the X-axis (each x-axis spot has a small list of Y-axis positions)
From there its quite simple, I split the cloud into bottom-max values and top-max values (Y-axis) I check for valleys and peaks (derivatives, anyone?) and If I get a certain amount of peaks and valleys in my point cloud I assume this is "fingers" and then my problem is solved.
What if the person has the hand to the side? And their fingers didn't point up or down? I also check the number of points on the given Y axis, any more than four (at least one gap) then I, again, declare the hand to be "open"
Again, are there are ways to do this better, but I want it done FAST, so if I can hit all of this in just one or two passes, I am a happy man, and I can devote my time elsewhere to gameplay programming. Had a friend of mine, Ozzy, test the game rather unplanned, which confirmed to me that: The hand opening/closing is "good enough"
It needs more work, but it's good where it is at. Will I work on it more? You bet, I'm a perfectionist when it comes to, well, random things, but this Kinect is one of the areas I always feel I need to improve at. And so I shall, but it's now officially on the back burner of the project.
Ozzy also showed me a degenerate strategy I'll have to talk with Brian about. One of the coolest parts of our game is the "smashing" feature, it's simple, but fun, if you have guys in your hand and then bring your hands together, they get crushed and blood spews everywhere, it's an insta-kill. However, it's also entirely possible to pick guys up and clap your hands together rapidly, just hovering guys above the ground and as such simply kill attackers left and right without rhyme or reason.
So that must be remedied, but overall we need to reign in the number of our attackers. Too many guys on the screen doesn't make for what feels like good gameplay, just really hectic arm-waving. Brian and I talked it over, we're going to try to lower the enemy count but raise the health and see if that helps maintain the difficulty but makes the game more about having fun smacking guys around a lot.
I'm also thinking about bringing back the "close hand to grab" functionality, at least temporarily to see if, now that Kinect is a little bit nicer, it brought anything to the gameplay.
I also implemented a quick pausing system that pauses the game if you are "interrupted" or step out of frame it pauses the game and allows you to step back in, quit or resume the game. It's not perfect, for some reason the draw order for the pause is out of whack, but it works and it's something that I had been meaning to do for a while.
The next few things I want to nail down is a more efficient system for the numbers popping up every time you hit enemies, it really can slow the game down for a bit if there are a lot of enemies on screen, and.. dang it, I just forgot. Well, I'm sure it will come to me in time.
I actually have a lot left to do.
- Background displays village and enemies leaving village (think the "what's coming next" indicator in Tetris)
- Kinect Wide-gestures (earthquakes, etc)
- Finish up scoring sytstem/hit tracking/combo recognition (base system is in place, I want the visualization to be there)
- Tweak Kinect every so slightly if time permits.
- Add catapult men. (Sssh! it's a secret!)
- Add more sounds and some music
- Many more things I am forgetting right now.
That doesn't seem like a lot, even to me, but I know things will be much harder than they seem, and I am missing a number of different tasks.
We also need some awesome intro cutscenes or something similar. We are re-working elements of the story to be a little more cohesive with what we've got. We shall see how that goes, we have to be very careful now, the difference between an okay game, a good game, and a great game is how it all comes together. We've got the art, we've got the design, I'm holding the program together with staples and superglue, it's good. We need it to be great.
Okay, that was my Coach-Carter moment.
Elsewhere in the world I finished my Delaunay Triangulator by complete accident. Well, not entirely, I scrapped all of my old code that I had because it was just not working and I couldn't figure out why. I re-did the code in a much cleaner and simpler fashion... and it still didn't work.
Then I changed the order of the vertex creation in new triangles and... lo and behold it worked. A seemingly random and insignificant matter as the specified order of vertices in a new triangle makes or breaks the algorithm... yet I followed it to the T, and there was no mention of vertex-dependent order? Did I still do something wrong? I have no idea, but boy am I glad there are only 3 verts in a triangle or I would have never figured it out by moving random stuff around. Which is how I come to a find many a solution in my code. It means I'm always 98% right and 2% wrong... but being 2% wrong still means you are wrong in programming and logic... and math. Most especially math.
Can't be wrong, must improve.
Must maths, must programs, must logics, must succeeds.
Wednesday, March 28, 2012
Slowly but Surely.
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
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
Monday, March 26, 2012
Spring
It has Sprung. Too quickly, if you ask me.
Well what have I done? Not much, admittedly, for my spring break my dear cousin came out to visit me in Chicago, and we had a great time doing all the things tourists do.
Up to and including getting really tired the last day and spending it watching movies and TV, haha.
In all seriousness, it was great to have her here, and as much as I enjoyed the break, it's time to get back to business. Or "srs bsns" as it has come to be known in our capstone group. I have to get back to working out, and to all of the things I have to do this quarter, which includes...
Calculus II (After a year off...!)
Multiplayer Game Development (Looking forward to this one!)
Capstone II (Duh)
Real Time Graphics (Please be good, please be good...)
And..
Working as a lab mod
Training for the next Judo tournament
Grading for Charley (My awesome faculty adviser at DePaul)
Zombie Yoga (...so much to do... so little time)
Not to mention the things I want to do, like learning how to do some sweet aerial kicks and tricks to impress at the dojo at home (as well as get me in better shape doing something fun as opposed to lifting which I find very hard to do without someone to do it with)
But, what have I done in terms of PROGRAMMING over the break?
I've been fiddling with creating a generic volume class for princess to be used in mo' advanced versions of our current collision system (which needs to be re-hauled... when I have the time)
It's a relatively simple system, it just takes a series of 2d vertices specified in a counter-clockwise order that is closed by connected the last vertex to the first vertex. There are edges between each of these vertices that check against other edges for collisions and etc.
That, my friends, is the drop-dead easy part.
A vertex class? Piece of cake. Edge class? I could do that in my sleep. Connecting them together? Pah! No problem.
So... then WHY am I still stuck on this? Well that's something I've been asking myself. You see, I'm trying to make the whole process as simple and efficient as possible, but at the same time I want this as robust as possible.
If I just want to check edge to edge collision, my system can stop where it's at, however, if I want to check if, say, certain points are contained in my newly created volume that beings to give me problems. If this volume that you've specified is convex, meaning that there are no interior angles in yo' shapes, then all I have to do is check to see if a point is to the left of each edge in the lot, and TA-DA! If it is, then the point resides inside the volume.
...however, if my shape is non-convex, then this to-the-left-of-each-vertex thing kindof falls apart. (also, the more complex these shapes get, the more processing has to be done for each interior check, which is also a general case, but if there was a simpler way....)
So what to do? Well, its elementary really.
In theory. In practice, not so much. The solution is to divide up the interior of the bounding volume into triangles, then loop through each triangle when looking for a point lying on the interior of a shape, and do some quick and cheap eliminations of unlikely triangles (point not within min/max bounds of a given triangle) before doing the messy stuff (checking the relative space to an edge).
Again, that's not my problem, my problem is HOW to break up the interior into triangles? Well, I kicked around a lot of my own idea for a while. That should be read: I do what I always do when I get stumped, snack profusely while staring blankly at my computer letting my mind alternate between creative thinking and flavor comprehension.
Regardless, I was getting nowhere, this is not a simple as I first thought, so I decided to see if the internet knew anything, and lo and behold I found this, or a good explanation about Delaunay Triangulation, which does more or less what I want to do, it takes a list of vertices, and creates a convex hull out of all of them. The article I linked is the only article I think is worth reading. I found a dozen more before (with source code) and they made no sense to me until I saw the picture-illustration of the algorithm at work in that article. That's when it all made sense to me.
That being said, I'm still having problems. One is conceptual, and one is my implementation. The implementation problem arises when I try to remove triangles as denoted in the algorithm. For some reason my algorithm is very trigger happy and removes too many triangles, leaving me with a sadly half-complete volume-mesh, which makes a very unhappy Kev.
The conceptual problem is that Delaunay's method creates a convex hull, even when I don't necessarily want a convex hull. So I have to go back through once good ol' Delaunay has done his thing and then remove any edges that connect vertices that shouldn't be connected. Imagine two vertices as Romeo and Juliette, which would make me Poison. Or Death. Though I think them both dying was supposed to be, as well as tragic, somewhat reassuring because "they died together" or "died for each other" or whatnot.
It's been a while since I read that play for English in high school, don't judge me. Getting back on track, this is achieved relatively simply if messily by comparing the angle between the two "true" outside edges of each vertex, if the angle from the first to the second (thinking clockwise here) is greater than or equal to 180 degrees or Pi/2 then it's a lovely convex point and we don't have anything to worry about, however, if the point is less than 180 degrees and we have a third edge between the two vertices at either end of the vertex in question, that edge must be removed to maintain our desired non-convex result.
But I haven't even gotten to that part yet because of my trigger happy triangle-removal portion of my code.
This is depressing, this algorithm shouldn't have taken more than a day to implement.
This quarter is going to kill me.
-Kev
Well what have I done? Not much, admittedly, for my spring break my dear cousin came out to visit me in Chicago, and we had a great time doing all the things tourists do.
Up to and including getting really tired the last day and spending it watching movies and TV, haha.
In all seriousness, it was great to have her here, and as much as I enjoyed the break, it's time to get back to business. Or "srs bsns" as it has come to be known in our capstone group. I have to get back to working out, and to all of the things I have to do this quarter, which includes...
Calculus II (After a year off...!)
Multiplayer Game Development (Looking forward to this one!)
Capstone II (Duh)
Real Time Graphics (Please be good, please be good...)
And..
Working as a lab mod
Training for the next Judo tournament
Grading for Charley (My awesome faculty adviser at DePaul)
Zombie Yoga (...so much to do... so little time)
Not to mention the things I want to do, like learning how to do some sweet aerial kicks and tricks to impress at the dojo at home (as well as get me in better shape doing something fun as opposed to lifting which I find very hard to do without someone to do it with)
But, what have I done in terms of PROGRAMMING over the break?
I've been fiddling with creating a generic volume class for princess to be used in mo' advanced versions of our current collision system (which needs to be re-hauled... when I have the time)
It's a relatively simple system, it just takes a series of 2d vertices specified in a counter-clockwise order that is closed by connected the last vertex to the first vertex. There are edges between each of these vertices that check against other edges for collisions and etc.
That, my friends, is the drop-dead easy part.
A vertex class? Piece of cake. Edge class? I could do that in my sleep. Connecting them together? Pah! No problem.
So... then WHY am I still stuck on this? Well that's something I've been asking myself. You see, I'm trying to make the whole process as simple and efficient as possible, but at the same time I want this as robust as possible.
If I just want to check edge to edge collision, my system can stop where it's at, however, if I want to check if, say, certain points are contained in my newly created volume that beings to give me problems. If this volume that you've specified is convex, meaning that there are no interior angles in yo' shapes, then all I have to do is check to see if a point is to the left of each edge in the lot, and TA-DA! If it is, then the point resides inside the volume.
 |
| Pictures always help me |
...however, if my shape is non-convex, then this to-the-left-of-each-vertex thing kindof falls apart. (also, the more complex these shapes get, the more processing has to be done for each interior check, which is also a general case, but if there was a simpler way....)
So what to do? Well, its elementary really.
In theory. In practice, not so much. The solution is to divide up the interior of the bounding volume into triangles, then loop through each triangle when looking for a point lying on the interior of a shape, and do some quick and cheap eliminations of unlikely triangles (point not within min/max bounds of a given triangle) before doing the messy stuff (checking the relative space to an edge).
Again, that's not my problem, my problem is HOW to break up the interior into triangles? Well, I kicked around a lot of my own idea for a while. That should be read: I do what I always do when I get stumped, snack profusely while staring blankly at my computer letting my mind alternate between creative thinking and flavor comprehension.
Regardless, I was getting nowhere, this is not a simple as I first thought, so I decided to see if the internet knew anything, and lo and behold I found this, or a good explanation about Delaunay Triangulation, which does more or less what I want to do, it takes a list of vertices, and creates a convex hull out of all of them. The article I linked is the only article I think is worth reading. I found a dozen more before (with source code) and they made no sense to me until I saw the picture-illustration of the algorithm at work in that article. That's when it all made sense to me.
That being said, I'm still having problems. One is conceptual, and one is my implementation. The implementation problem arises when I try to remove triangles as denoted in the algorithm. For some reason my algorithm is very trigger happy and removes too many triangles, leaving me with a sadly half-complete volume-mesh, which makes a very unhappy Kev.
The conceptual problem is that Delaunay's method creates a convex hull, even when I don't necessarily want a convex hull. So I have to go back through once good ol' Delaunay has done his thing and then remove any edges that connect vertices that shouldn't be connected. Imagine two vertices as Romeo and Juliette, which would make me Poison. Or Death. Though I think them both dying was supposed to be, as well as tragic, somewhat reassuring because "they died together" or "died for each other" or whatnot.
It's been a while since I read that play for English in high school, don't judge me. Getting back on track, this is achieved relatively simply if messily by comparing the angle between the two "true" outside edges of each vertex, if the angle from the first to the second (thinking clockwise here) is greater than or equal to 180 degrees or Pi/2 then it's a lovely convex point and we don't have anything to worry about, however, if the point is less than 180 degrees and we have a third edge between the two vertices at either end of the vertex in question, that edge must be removed to maintain our desired non-convex result.
But I haven't even gotten to that part yet because of my trigger happy triangle-removal portion of my code.
This is depressing, this algorithm shouldn't have taken more than a day to implement.
This quarter is going to kill me.
 |
| It's 0200. I can't maths, I can't draws, I can't programs. Therefore, I blogs. I should probably sleeps, though. |
Subscribe to:
Posts (Atom)