Level Counter

Story: 60, Challenge: 0.

Friday, June 7, 2013

Lessons from the prototype graveyard - part 1

In Pachinguys related news: in the wake of this year’s Google I/O. the entire project has been ported to the new and improved Android studio. Moving to a new IDE takes its toll and it will be some time before serious progress can be made on Pachinguys again. The third boss fight is in active development at the moment.

I've also started using Trello to keep track of my progress on the project. It seems to be a useful tool, if I bother to keep it up to date. At the very least it revealed to me that there is still a lot of work left to be done before Pachinguys is released.

Following a conversation with a friend, I've decided to run down some of my old and unsuccessful game prototypes to see what can be learned from them. I will keep games made without code and various pong/breakout clones out of this to keep it (a bit) shorter.

Disclaimer: this post is long and mainly serves as a memory dump / nostalgia post, read (or skim and lose concentration half way) at your own discretion. I've split it into two parts as it grew larger than expected.

1) Unnamed platformer: this was the first real game I've ever made. It was made well before I knew anything about programming. It was my first motivation into the world of code.

Code: the game consisted of a single HTML page with some JS on it, as code goes, it was beyond awful: code repetition, no order, no structure, no documentation, just awful.
Graphics: black and white images made with Paint.
Game idea and design: there was nothing too complex about the game, it had four "levels" (screens basically). The goal was to reach the door to the next level, and it was achieved by jumping around the level, very, very basic.
However, the fourth level had an enemy, a rotating gear that would move around on a track of flat gear teeth. once the player beat that level, he got the gears ability and could use gear teeth tracks to pull himself to places he could not before, which allowed him to return back to previous "levels" and reach new places.
The good: nothing really novel or exciting. But looking back at the (primitive) tools I used for the job, I'm quite proud of the result.
The bad: the code, the graphics, the tools used (notepad and paint).
Status: game completed.
What I've learned: the amount of code repetition and lack of order in this game made me realize that "this can't be the way this is done" and start my long journey in the world of programming. I've also learned that making games (and especially completing games) is a lot of fun. I’ve also reinvented the wheel a bit with AABBs.

2) Unnamed RTS: my second (and last) HTML/JS based game. The intention here was to clone one of my favorite games (Dune 2).

Code: still rather ugly, structure was somewhat better, repetitive code relegated to functions, but still a single giant file containing all the game code.
Graphics: ZOMG color! Still static images made with Paint, but now in full color.
Game idea and design: a grid based real time strategy game with resource collection and unit based battles.
The good: more effort was put towards code structure.
The bad: the lack of originality and focus on graphics made me tire of this game rather quickly.
Status: abandoned at prototype stage. When abandoned it contained a scrolling map, selectable buildings and units, moving units and resource gathering (similar to spice collection in Dune 2).
What I've learned: basic concepts of scrolling tile engines, mouse input, path finding (A*).
 this game had a complex coordinate system used to handle mouse input and unit movement in a scrolling world map, while I was initially proud of mastering this difficult system, I would later come to understand that it was a result of bad systems coupling.

Sadly these two games were made on a computer that was not mine and are now lost forever.

3) Blob: my second stab at platformers. This time made with Flash, using action script 2, made during my first year in the university.

Code: that very early version of flash wasn't much of an IDE, but it was far superior to notepad and Paint. Flash abstracted away many of the graphics related issues and allowed me to concentrate on game logic. Some separation of interests was finally introduced. Not a real game engine yet, but a step in the right direction
Graphics: frame by frame animations and motion-tweens, created in the flash editor.
Game idea and design: the concept here was an alien crashing on a strange planet; where he has to absorb elements of the environment (enemies and static objects) in order to gain abilities that allow further progression (sound familiar?). The alien (named blob) would start off very under-powered (his first and only ability at the beginning was to crawl). And build up slowly as the game progressed.
The good: care was taken to separate the player code from enemies code. Frame by frame animations used for walking, turning and idle states. This led to the creation of a (primitive) state machine.
The bad: overreaching. The scope of the game was well beyond what I could accomplish by myself at that point in my learning process. Every new ability required new movement code and graphics. Time was spent on planning boss fights and levels that never got created.
Status: abandoned at the prototype stage. When abandoned it contained a crawling blob in a scrolling world, a single enemy leading to a victory animation and an upgrade of the blob to a walking blob. And many unused design sketches.
What I've learned: curb your enthusiasm. Build smaller games. It was clear now that I had to make sure I have the technical and time related ability to make the actual game before committing too much time to things like level design and animation.

4) Shadowport: another flash game. It revolved around a portal like mechanic that used the shadow of the character as the portal location. I was really excited about this mechanic and thought it would be loads of fun.




Code: much better than earlier games, this is now well into my university years. Mouse input is handled separately from keyboard input, which both feed into a central (game engine-esque) system that the player code polls for input. Also contained my first try at a particle system.
Graphics: simplistic black and white representations of the concepts, following the animation related quagmire of the previous game and the effort to separate interests, I've decided to make sure the mechanic works and works well before I devoted time to animation and graphics.
Game idea and design: the player controlled two things; a character was controlled with the keyboard and handled like a platformer. And a light source was controlled by the mouse. The positions of the light source and character changed the position of the character’s shadow. To which he could teleport using a mouse click. The goal was to help the character reach the level end door.
Death resulted in a particle heavy effect. A tutorial system was implemented to help clarify the mechanics for early testing.
The good: this was closer to the proper definition of a prototype then any game I made before, simplistic placeholder graphics, single level and a focus on a single core mechanic.
The bad: the mechanic turned out to be not fun. I've tweaked and I changed and still the experience was not fun. The control scheme was to complex, the timing required was too exact at some points and too easy at others, and this really brought home for me the value of prototyping. as the time it took from having the idea to realizing it’s not fun was about a month or two (keep in mind I was a full time student at this point and game making was a hobby).
Status: abandoned at the prototype stage. When abandoned it contained the completed teleporting mechanic, a simple input aggregation system, some basic math usage (calculations of where the line between the character and the light source hits a remote wall), a particle system and a tutorial system.
What I've learned: the value of rapid prototyping, the huge chasm between how a game plays in your head and how it behaves in real life, and that math is not as scary as originally thought.

Continued in part 2.

No comments:

Post a Comment