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.
Subscribe to:
Posts (Atom)
