Sunday, April 12, 2009
Friday, March 20, 2009
Final Thoughts...
Game Development III was a most excellent class! I thank "yall" for your comments and constructive feedback. You too were a part of my learning experience, and I am very grateful for that. Thank you very much.
Thursday, March 19, 2009
...brain...swollen...
AwesomeTown Postmortem
What went right?
Everything that “we” did went right. Our schedule and workflow layout worked flawlessly. If our work ethics were played in Mortal Kombat II, the little dude would pop out of the corner and say TOASTY! We initially set mildly expensive poly limits, (ones that would be acceptable in the Torque Advanced engine) and based on our final results, we were way under budget. The spirit and moral of me and my partner Tom remained high and bright. Our deadlines and milestones were strict, but they were met. This was by far, the most organized project I’ve ever worked on. Our team dynamics were superfluous. Overall, this project was awesome…hence the name “AwesomeTown.”
What went wrong?
Torque. We had challenged TGEA and TGE with our ambition. The Torque’s failed. Either that or our visual awesomeness was just too much. I wish we would have done some more testing in the engines before getting into this class. Other than that, nothing really went wrong.
What for the future?
Tom and I can’t work on a team. We’re stupid. We’re too ambitious. We like to try and touch “the bar.” If we don’t try, Kim will beat us with something that will cause pain, swelling, bleeding, and diarrhea. On the other hand, we have to appease the Great Amanda Lange. Amanda is a ninja. She is proficient in the art of killing. We (the human race) must make Amanda happy. On another serious track. I would like to be a bit more organized in the file/folder department. I was organized for my standards, (no problems) however the end process became somewhat time consuming (literally only a few seconds here or there). We will get the town into the (or some) game engine.
What went right?
Everything that “we” did went right. Our schedule and workflow layout worked flawlessly. If our work ethics were played in Mortal Kombat II, the little dude would pop out of the corner and say TOASTY! We initially set mildly expensive poly limits, (ones that would be acceptable in the Torque Advanced engine) and based on our final results, we were way under budget. The spirit and moral of me and my partner Tom remained high and bright. Our deadlines and milestones were strict, but they were met. This was by far, the most organized project I’ve ever worked on. Our team dynamics were superfluous. Overall, this project was awesome…hence the name “AwesomeTown.”
What went wrong?
Torque. We had challenged TGEA and TGE with our ambition. The Torque’s failed. Either that or our visual awesomeness was just too much. I wish we would have done some more testing in the engines before getting into this class. Other than that, nothing really went wrong.
What for the future?
Tom and I can’t work on a team. We’re stupid. We’re too ambitious. We like to try and touch “the bar.” If we don’t try, Kim will beat us with something that will cause pain, swelling, bleeding, and diarrhea. On the other hand, we have to appease the Great Amanda Lange. Amanda is a ninja. She is proficient in the art of killing. We (the human race) must make Amanda happy. On another serious track. I would like to be a bit more organized in the file/folder department. I was organized for my standards, (no problems) however the end process became somewhat time consuming (literally only a few seconds here or there). We will get the town into the (or some) game engine.
Sunday, March 15, 2009
Run away! Run away!
Deep within the development labs of awesome town, we have stumbled upon something utterly horrible....Torque.
Saturday, March 7, 2009
Wednesday, March 4, 2009
Truckin'
I'm working on the street sign textures right now. I'm making a bundle pack. I will post them soon. I will continue to work according to schedule. Things are looking good...this is a true story.
Tuesday, March 3, 2009
Title
"Cause I'm 2 Dope, clown loco G, and it's one chop, two boing, boom chop three...in the melon, in the back of the melon. One black, two black eyeballs swelling." - Shaggy 2 Dope
Saturday, February 28, 2009
...and on the 12th day, he said - "let there be street lights."
The birth of the street "lights" ( say like this -> "lig-hets" (referring to Monty Python's The Holy Grail)).
Thursday, February 26, 2009
Tuesday, February 24, 2009
Monday, February 23, 2009
3 Cheers for the Samuel Smith Brewery!!!
I'm enjoying a delicious Pure Brewed Lager right now...ah! Things are on track. Here are some of the first objects for the Factory. Some of the textures are "just there" right now. A few shots have 3 point lighting. Our schedule allows us one whole week for fine tune/detail work. I just started developing some building overhangs, the hoist plates for the bin (below), and general decor, (mostly for the smoke stack) they're not finished yet. I'll post them later. Anywho...CHEERS!
Saturday, February 21, 2009
Moving...
Things are moving along a bit slow right now. I still don't have all of my programs on my new computer yet, so...I can only do so much. Come to find out, a 64bit OS causes problems with a bunch of different things. Crap! Anywho, I do have one model (as of right now) completely finished and ready for export. The Great Lakes Ore Freighter. I have a couple other models complete, they just need the unwrap to be done. Not a problem. Here are a couple of screenshots.
Tuesday, February 17, 2009
Swollen Colon....
...don't google image the title. Anywho, after an awesome battle with project1, I decided to pair up with Lex and goto war with PROJECT2. DEFAULT! I have chosen the art track. I am not leaving this track. We have the design scope entirely laid out. We have a schedule with due dates and deadlines. We also have an asset list that contains the work (divided) to be done. Check Tom's blog for the list details. I have them too, butt (ha! I said butt!) that's a bunch of words. I will post some concept pics later.
Thursday, February 12, 2009
Postmortem
SuperFist
What went right?
This project has become an excellent foundation for a 2D (or 2D/3D) platform game that utilizes jumping/attacking mechanics. The main environment object collisions (floors, ceilings, walls) have been debugged and are working awesome. The job for the level designer should be much easier now: the wallObject building block is dynamite, it can be stretched, scaled, and so forth; the collisions still function properly. All “they” have to do is drop the alpha, and boom! Invisiblock, draw on top! There are also blocks that detect only topside collisions, nice for “jump-thru” platforms. There are 2 types of kill zones, one of which inherits the same type of properties as the wallObject. There are treasures (power ups) that can be picked up. Each treasure increments the player’s score by five. There are also keycards which open certain “indestructible” doors. Yes, there are doors too…and they work with supporting animations. The player can level-up, (level 2, 3, etc.) and the code is in place and easy to implement. There were also major breakthroughs with code and level design as a whole. An elegant block of code provides smooth and continuous character/screen movement. This same block of code also takes in account of the design scale and output scale of the stage. The code interprets the design scale and implements it during runtime.
The flight mechanics are pretty solid and rather enjoyable. “Even without enemy placement, jumping and flying around in the level is fun.” (developer commentary intended for Amanda Lange). The characters battle mechanics are working for the most part. The attack animations need to be completed in order to add the necessary spice & zest to the meatball. Some 3D work for SuperFist has already started. The base model for SuperFist is complete. There are also some environment objects that are in early stages of development. The main goal is to have an entirely 3D/2D platform game. Awesome!
What went wrong?
Well, the start date of this project was the first initial wrong. I was to design: “fun for a level design track.” Did this happen? No. I didn't complete the level design track. I jumped ships before untied from the dock. I went with the Mechanics track. I felt, that in order to design a fun level for SuperFist, I first must exploit the character properties. Easier said, typed, thought, conjured, resurrected, reincarnated, than done. I began to backwards engineer Gary Rosenweig's code for the Flash platform tutorial from the very start of the project. I ended up in a clusterflute of poo. I'm not yet that proficient of a programmer...or for that matter “scripter.” This for me was a challenge, it still is, and will continue to be. If there is no struggle, there is no progress. Overall the main hurdle for me was the code, scripting logic, and good coding practices. I’m not so sure, but, those might fit into one term...I can't tell you. I can tell you, what pyroclastic density currents & Pneumonoultramicroscopicsilicovolcanoconiosis have in common (volcanoes).
The portions of the project that were completed are still in their base formats. There are no animations for the battle mechanics and they are quite buggy while the character is in the air. There are enemies, however none of them are in the level (right now at least). However, they can be killed by being jumped on (a huge use for a character who punches! He is very heavy, so I guess we can go with it). There is no collision detection on the sides of the enemies yet. The lack of paper documentation became a set back later in the project. I found myself jumping between functions trying to build numerous things at once. Not smart. Multi-tasking should be avoided (in certain cases) as there is no real sense of accomplishment based off of one specific task. Prioritizing code blocks to be completed is a necessity. Jumping around is too confusing. However, at times it is required, and at that moment, suggested. I came to this realization mid way through the project. I know that we were instructed in our coding classes to (on paper) pseudo-code first, then goto the computer. The only problem with that is…no compiler. Where are my errors? So now what? Mind map and chart out basic/core mechanics in the order of operations. Know the scope of the design; ask questions that will “buttonhook” obstacles that may come about in the future of the project.
What was learned?
My lifelong hopes and dreams of being a programmer are smashed! On a more serious note. I did learn a substantial amount about 2D platform coding. I also learned that I have to put more down on paper first. I realize that jumping ships is usually uncommon and not something that's widely practiced, but I feel that this was the right choice overall. I have done Art tracks. I have done Level design tracks. I'm an artist. I can do those things...probably with my eyes closed (joking). Seriously...I learned that I wanted to learn. That may sound like bullshit. It's not. I hope that's not too deep for some. Thanks to all that helped and all who provided feedback for this project.
I want to be a better programmer and this was a huge step. I found myself rewriting the code from scratch. This rewrite was much needed for clarity sake. I used more code that was developed by me and other coding genius's in unison deep within the coding laboratories at IADT. I also mention some things learned in the “what went wrong” section. Mind mapping, charting, and a basic conceptualized view of the design scope is a requirement and necessity that should never be avoided or thought of as “a waste of time.” Overall, I am very happy with what was gained from this project. I’m very glad that I decided to add extra pressure and stress to myself by jumping ships. I probably won’t do it again, but hey, there is a first time for everything right?
What for the future?
The future is an untold, unbound, pseudopodian & metamorphic conglomerate…thing. I would like to focus on more of the paper documentation. I would also like to have a true and realistic sense of the design layout, what is to be expected, and what is going to be performed. When I work on my next mechanic track, I will make sure that I separate previous blocks of code that are functional; implement them (if possible) with the application being developed, and continually check the checker while asking questions. I also will continue to research, study, and practice code. Education is like a shark, if you stop swimming (learning), you suffocate and die (become stagnant and complacent with staleness).
What went right?
This project has become an excellent foundation for a 2D (or 2D/3D) platform game that utilizes jumping/attacking mechanics. The main environment object collisions (floors, ceilings, walls) have been debugged and are working awesome. The job for the level designer should be much easier now: the wallObject building block is dynamite, it can be stretched, scaled, and so forth; the collisions still function properly. All “they” have to do is drop the alpha, and boom! Invisiblock, draw on top! There are also blocks that detect only topside collisions, nice for “jump-thru” platforms. There are 2 types of kill zones, one of which inherits the same type of properties as the wallObject. There are treasures (power ups) that can be picked up. Each treasure increments the player’s score by five. There are also keycards which open certain “indestructible” doors. Yes, there are doors too…and they work with supporting animations. The player can level-up, (level 2, 3, etc.) and the code is in place and easy to implement. There were also major breakthroughs with code and level design as a whole. An elegant block of code provides smooth and continuous character/screen movement. This same block of code also takes in account of the design scale and output scale of the stage. The code interprets the design scale and implements it during runtime.
The flight mechanics are pretty solid and rather enjoyable. “Even without enemy placement, jumping and flying around in the level is fun.” (developer commentary intended for Amanda Lange). The characters battle mechanics are working for the most part. The attack animations need to be completed in order to add the necessary spice & zest to the meatball. Some 3D work for SuperFist has already started. The base model for SuperFist is complete. There are also some environment objects that are in early stages of development. The main goal is to have an entirely 3D/2D platform game. Awesome!
What went wrong?
Well, the start date of this project was the first initial wrong. I was to design: “fun for a level design track.” Did this happen? No. I didn't complete the level design track. I jumped ships before untied from the dock. I went with the Mechanics track. I felt, that in order to design a fun level for SuperFist, I first must exploit the character properties. Easier said, typed, thought, conjured, resurrected, reincarnated, than done. I began to backwards engineer Gary Rosenweig's code for the Flash platform tutorial from the very start of the project. I ended up in a clusterflute of poo. I'm not yet that proficient of a programmer...or for that matter “scripter.” This for me was a challenge, it still is, and will continue to be. If there is no struggle, there is no progress. Overall the main hurdle for me was the code, scripting logic, and good coding practices. I’m not so sure, but, those might fit into one term...I can't tell you. I can tell you, what pyroclastic density currents & Pneumonoultramicroscopicsilicovolcanoconiosis have in common (volcanoes).
The portions of the project that were completed are still in their base formats. There are no animations for the battle mechanics and they are quite buggy while the character is in the air. There are enemies, however none of them are in the level (right now at least). However, they can be killed by being jumped on (a huge use for a character who punches! He is very heavy, so I guess we can go with it). There is no collision detection on the sides of the enemies yet. The lack of paper documentation became a set back later in the project. I found myself jumping between functions trying to build numerous things at once. Not smart. Multi-tasking should be avoided (in certain cases) as there is no real sense of accomplishment based off of one specific task. Prioritizing code blocks to be completed is a necessity. Jumping around is too confusing. However, at times it is required, and at that moment, suggested. I came to this realization mid way through the project. I know that we were instructed in our coding classes to (on paper) pseudo-code first, then goto the computer. The only problem with that is…no compiler. Where are my errors? So now what? Mind map and chart out basic/core mechanics in the order of operations. Know the scope of the design; ask questions that will “buttonhook” obstacles that may come about in the future of the project.
What was learned?
My lifelong hopes and dreams of being a programmer are smashed! On a more serious note. I did learn a substantial amount about 2D platform coding. I also learned that I have to put more down on paper first. I realize that jumping ships is usually uncommon and not something that's widely practiced, but I feel that this was the right choice overall. I have done Art tracks. I have done Level design tracks. I'm an artist. I can do those things...probably with my eyes closed (joking). Seriously...I learned that I wanted to learn. That may sound like bullshit. It's not. I hope that's not too deep for some. Thanks to all that helped and all who provided feedback for this project.
I want to be a better programmer and this was a huge step. I found myself rewriting the code from scratch. This rewrite was much needed for clarity sake. I used more code that was developed by me and other coding genius's in unison deep within the coding laboratories at IADT. I also mention some things learned in the “what went wrong” section. Mind mapping, charting, and a basic conceptualized view of the design scope is a requirement and necessity that should never be avoided or thought of as “a waste of time.” Overall, I am very happy with what was gained from this project. I’m very glad that I decided to add extra pressure and stress to myself by jumping ships. I probably won’t do it again, but hey, there is a first time for everything right?
What for the future?
The future is an untold, unbound, pseudopodian & metamorphic conglomerate…thing. I would like to focus on more of the paper documentation. I would also like to have a true and realistic sense of the design layout, what is to be expected, and what is going to be performed. When I work on my next mechanic track, I will make sure that I separate previous blocks of code that are functional; implement them (if possible) with the application being developed, and continually check the checker while asking questions. I also will continue to research, study, and practice code. Education is like a shark, if you stop swimming (learning), you suffocate and die (become stagnant and complacent with staleness).
Tuesday, February 10, 2009
Beer:30 ???
Yes! It is that time. I had some breakthroughs and some breakdowns. SuperFist can attack in the air now. However, my computer died this weekend. personal note - "If anyone was upset about the statement that was posted here earlier. I'm sorry. Good day."
Thursday, February 5, 2009
Mechanic Track
The mechanic is going to be (mostly) a character mechanic. The character “SuperFist” has jet powered arms and legs. He is a robot. He has a set of flight and battle mechanics. The flight mechanic consists of: flight, hover, jets (on/off), & boost jump. The battle mechanic consists of: an array of multiple attacks while moving (walking, running, and jumping).
Well, you’re a virtually indestructible robot that has been sent to beat ass. This game resembles Teenage Mutant Ninja Turtles IV, as the main mechanic is beating carcass. The combonation of the attack moves delivered just by pressing 1 button is very rewarding to the player. It holds true to the classic arcade button blasting fury. Mix in some cool flight mechanics and we are talking an all out awesome-A-thon.
As far as research in the code itself…none. Competition…some. I mentioned above, TMNT IV.
Pretty much any side scrolling, punch/kick game is going to be competition. Real world research will be more on jets, the level (Zug Island), and AS3 mechanics.
The technology that I will be using is Flash CS3 & ActionScript 3.0.
Well, you’re a virtually indestructible robot that has been sent to beat ass. This game resembles Teenage Mutant Ninja Turtles IV, as the main mechanic is beating carcass. The combonation of the attack moves delivered just by pressing 1 button is very rewarding to the player. It holds true to the classic arcade button blasting fury. Mix in some cool flight mechanics and we are talking an all out awesome-A-thon.
As far as research in the code itself…none. Competition…some. I mentioned above, TMNT IV.
Pretty much any side scrolling, punch/kick game is going to be competition. Real world research will be more on jets, the level (Zug Island), and AS3 mechanics.
The technology that I will be using is Flash CS3 & ActionScript 3.0.
Friday, January 30, 2009
Well...(water)
I'm going to be brief. I want to be clear to "yall" as to what my intentions are. This project is due in a few days. I've been programming since the start date; I'm going to continue programming until the due date. I will supply all the supportive documentation that accompanies the role of the Mechanics track. The documentation will be posted immediately upon completion. I feel that this decision is is for the best. It will continue to strengthen my programming abilities and provide a multitude of different and new challenges. Thanks for the feedback in class. I've already implemented new features that are working well. The goal: FUN. Vini! Vidi! Vici!
Wednesday, January 28, 2009
In a world....
...where screenshots rule.....
...one man....
...one level....
...one mission...
...one outcome...
(if you don't get this by now, I'm not gonna explain)
Here are some screenshots.
...one man....
...one level....
...one mission...
...one outcome...
(if you don't get this by now, I'm not gonna explain)
Here are some screenshots.
Tuesday, January 27, 2009
Mechanic Track?
Well...in order to make my game level function like it's designed to, I have to do(and have been doing for quite some time now) scripting. I feel like I've joined the mechanic track with Lex and Justin (however, not as in depth). Things are going awesome! JumpMan (a stand in for SuperFist) has the ability to airJump, jetCoast, (etc.) which allows for the correct obstacles to be utilized to their fullest potential. I have really been trying to go for "fun" on this level, as instructed to do so by the the Great Amanda Lange. I feel that this goal is attainable, and not too far off in the future. I will post screenshots later today.
Sunday, January 25, 2009
Level Up...
Things are going well. The level for SuperFist is taking shape. Some of the core mechanics are working now. I can finally start building the level. Screen shots...very soon.
Thursday, January 15, 2009
SuperFist
(A 2D Flash platformer)
The type of environment will be a scorched city’s industrial outskirt. For Michigan folk, it would be the equivalent to Zug Island. Smoke, fire, giant metal structures, molten steel, and a sky choked with layers of poisonous smog.
Well, if you had trouble understanding the title; I don’t think that this section is going to help you…it’s the same thing. SuperFist is a 2D platform game that will be created in Flash CS3. The core mechanics are jumping and punching (killer combos, flashy, real martial arts stuff).
SuperFist(a highly sophisticated justice robot). He is the main character. The world is Earth, and the level is on Earth. There is a direct correlation between the two: the level space exists on the facial space of the world, therefore they are one in the same. What makes a divergence in the settings is the physical distinction in which the geographical location is sited. The “story” of the level site is short and simple. This is a heavily guarded, controlled facility where evil robots are forged, programmed, and sent out onto the streets to spread fear into the hearts of the humans. This place is very dangerous, there are shredders, crushers, compactors, foundries, and of course tons of evil robot drones that are on guard and performing work duties. The level will be outside of the main building. The goal is to make it inside of the building; that would be the queue for the next “sub-level.” Once in the next level, the player would fight through the hoards of evil robots to the power source of the plant, the DarkFire ProcessorCore. The DFPC is to be destroyed. There will be other locations across the globe that must be destroyed, but that’s an entirely different document in itself.
The player will face an army of robot drones. These drones come with an assortment of tools and weaponry, all which are capable of destroying SuperFist. For example, there are robots called “ARC-ers,” these smaller flying/hovering football sized/shaped drones have short ranged high powered arc welding abilities. Small and fragile, they pose more of a nuisance threat than anything else. They are kind of like the invisible blocks in impossible Mario, always in your face when you jump, what a pain in the butt! Worse than Ann Coulter! The player will also come across the various machines mentioned above (shredders, crushers, etc.), classic molten metal (bad for robots), and high flying jumps and ledges.
The type of environment will be a scorched city’s industrial outskirt. For Michigan folk, it would be the equivalent to Zug Island. Smoke, fire, giant metal structures, molten steel, and a sky choked with layers of poisonous smog.
Well, if you had trouble understanding the title; I don’t think that this section is going to help you…it’s the same thing. SuperFist is a 2D platform game that will be created in Flash CS3. The core mechanics are jumping and punching (killer combos, flashy, real martial arts stuff).
SuperFist(a highly sophisticated justice robot). He is the main character. The world is Earth, and the level is on Earth. There is a direct correlation between the two: the level space exists on the facial space of the world, therefore they are one in the same. What makes a divergence in the settings is the physical distinction in which the geographical location is sited. The “story” of the level site is short and simple. This is a heavily guarded, controlled facility where evil robots are forged, programmed, and sent out onto the streets to spread fear into the hearts of the humans. This place is very dangerous, there are shredders, crushers, compactors, foundries, and of course tons of evil robot drones that are on guard and performing work duties. The level will be outside of the main building. The goal is to make it inside of the building; that would be the queue for the next “sub-level.” Once in the next level, the player would fight through the hoards of evil robots to the power source of the plant, the DarkFire ProcessorCore. The DFPC is to be destroyed. There will be other locations across the globe that must be destroyed, but that’s an entirely different document in itself.
The player will face an army of robot drones. These drones come with an assortment of tools and weaponry, all which are capable of destroying SuperFist. For example, there are robots called “ARC-ers,” these smaller flying/hovering football sized/shaped drones have short ranged high powered arc welding abilities. Small and fragile, they pose more of a nuisance threat than anything else. They are kind of like the invisible blocks in impossible Mario, always in your face when you jump, what a pain in the butt! Worse than Ann Coulter! The player will also come across the various machines mentioned above (shredders, crushers, etc.), classic molten metal (bad for robots), and high flying jumps and ledges.
Capsized S.S.Turd
Z Brush can open its mouth and catch that sinking "ship." Anywho... My project is moving along quite well now. I have a definite idea/direction for my level design track. The level is going to be based off of a character that I created years ago. He (it) is a robot named SuperFist. He was created to destroy the evil robots and corrupted computer systems that have taken over the world. Mankind has let their technology literally run away from them. The evil robots are being mass produced by numerous facilities around the globe spreading fear into the remaining humans. SuperFist is man's only hope. Blah, blah, blah, the level I'm creating starts in the outskirts of one of the facilities. For a mental picture, think of a metal foundry in Hell (minus the Demons) heavily guarded by an assortment of evil robot drones. Enough for now...
Tuesday, January 6, 2009
The start of my (we)blog
Well, today was simply delightful. I'm regular & life is just peachy. I feel that for project 1 I would like to be part of the level design track. I would also like to supply the sounds and code supporting the sound effects. As far as game mechanics, I have some ideas: none that are ready to pop yet. I would like to see a game that utilizes 3D models and objects in a 2D space. I would like to work with TGB, the 3D import process is relatively simple and the visual results are awesome. Thank You Drive Thru!
Subscribe to:
Posts (Atom)
