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).

No comments:

Post a Comment