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.
Sunday, January 26, 2014
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
Subscribe to:
Posts (Atom)