Another Art Sample

I've been doing a lot of work on the art style of Amoeba now that my game engine has a working skeleton. This is far harder for me than any of the programming work, or even game design. As an engineer I understand the processes used in both of those tasks. I am not a graphic artist, and I have only basic training in the principles and processes used, especially when it comes to pixel art.

I've struggled to try and get even a basic representation of the game that communicates the style, mood, and sense of place I want Amoeba to have. I'm learning a lot as I go, but it's slow and can be very discouraging when I put in a lot of work but feel as though I've accomplished nothing.

Here is a sample of the art so far:

I feel happy with the "style" - the camera projection, the shape of the character silhouettes, the pixel scale, etc. However I have particular trouble selecting color pallets. I get the basic idea (I think) but my lack of experience is really getting in the way. I have an idea in my head of how I want the scene to look, but when working on pixel art the coloring of individual pixels is sometimes really unintuitive.

Take this example from user "Helm" at pixeljoint.com (http://www.pixeljoint.com/pixelart/76179.htm):

Take a look at individual pixels, especially the highlights and shadows. You'll notice bright cyan, purple, and deep greens for a scene that takes place in a metallic hangar that in "real life" would probably just be grey. Obviously though, if you look at the whole scene, the color palette works very well, communicates depth, age, and mood very well.

Although I'd like to learn how to do this properly, eventually I think I'll seek out a "real" artist to help me polish off Amoeba. In the mean time I'm just plugging along trying to learn as much as I can and refine what I have as much as possible.

Onward!

Interesting Moving Platform Bug

The saga of the moving platforms continues... or maybe is finally over. Only time will tell. After about 3 or 4 different versions of my moving platforms I feel like I finally had something that worked, that was clean, and that was generalized. I started setting up a series of test cases to make sure all my collisions worked as intended and discovered an entirely new bug:

All of my movement in the game (things like player walk speed, gravity, jump speed, etc) are defined with whole numbers. Even curved motion (like the ballistic trajectory the player follows when jumping to the side) is calculated with x and y components, so as long as the speed factors applied to those x and y components are whole numbers, your position is still restricted to whole numbers. I suspect that in many cases this is the best practice. It eliminates the need to deal with fractional positions in general, leaving the code nice and neat.

Where I ran into the problem is with Game Maker paths. Paths are defined in the Game Maker IDE as a series of points defined by x/y coordinates. In order to move between the points however, an interpolation is done resulting in intermediate positions that may have a fractional component. Paths can also be "smoothed" turning linear segments between points into curves, resulting in the same situation.

Luckily the solution to my specific problem was pretty simple once I did some pondering. At the beginning of every step the platform object rounds it's position to the nearest whole number. Only after it has done that does it moved the player. This means the player's coordinates are always (so far) whole numbers, even if the platform's coordinates are not.

Moving Platforms and Collisions

I've been working hard since the last update on getting my moving platforms to work in the game engine. This didn't necessarily have to be such a difficult task, but I wanted a single moving platform object that was general enough to be used as an elevator, a door, or any kind of moving platform moving along any arbitrary path.

After some significant time thinking about how I might implement this, I was getting discouraged. It seemed like generalizing the problem was going to be way more work than it would be worth and that it might be easier to simply create different objects for vertically moving elevators, horizontally moving platforms, sliding doors, etc. This would have been much faster to code, I think, but it just felt so inelegant, I couldn't bear it.

I did a lot of reading through the Game Maker forums looking for hints on how to find a solution to this problem. One big advantage to making a game inside a familiar genre is that most design problems have already been solved by someone else, so my hopes were high that I'd find a solution without too much trouble. Not so.

Now I'm sure others have solved this problem, but I couldn't find anybody who had also shared it publicly. I then dove deeper into Game Maker documentation and churned out my own solution. Actually it ended up being far simpler than I imagined, and far simpler also than hard-coding all the different moving objects in my game.

If any other Game Maker developers out there have questions about how I did this, feel free to contact me. I'll help if I can.

Here's a short video showing what I have so far:

I still have some work to do with moving platforms and collisions. Right now vertical and horizontal platforms work 99% correctly, but if the platform path is arbitrary (diagonal, curved, etc) then my collision code no longer functions correctly. That's what I'll be working on next.

Writing "Smart" Code

One of the most challenging parts of the Amoeba project so far is making sure I'm writing "smart code". By this I mean minimizing duplicate code, making the most of object hierarchy, and generalizing objects as much as possible.

One example of this idea is the way I started thinking about how the door mechanic would work in Amoeba. I imagined our protagonist blob of goo being able to ooze through vent grates in the background to get to secret or out-of-the-way locations. Step one was to create a vent object and start describing its behavior. I realized that I could just make the vent act like a teleporter, changing the player's x and y coordinates to the target of the "vent". With a little animation work, I could now have my blob ooze through a vent into some ducts (i.e. teleported t a new area of the level), crawl to another vent, then ooze through back into the main environment (again teleport to the appropriate level location).

This worked great, and I was happy with it, until I started working on sliding doors. Now I had two types of "doors" and started to write checks in the code to decide which type of door I was working with. Then I started working on elevators and was having conflicts with my object hierarchy; doors and elevators are pretty similar.

As I stepped back for awhile I realized that I had been treating elevators and doors are two separate things when really they're both just collidable platforms that may or may not move. They're the same thing and can be treated as such with a few parameters to decide whether they act like a door or an elevator. I also realized that my vents weren't really doors at all but teleporters. This observation allowed me to clean up my code and simplify my hierarchy.

All of this probably sounds pretty obvious to anybody who's job is software development. Although I have some experience in the field, it's not my area of expertise, and so I have a lot to learn - especially how to think.

I think it's interesting to note that the process I described above is not just a programming exercise. The way I imagine and talk about game mechanics and gameplay directly affects how I go about executing those ideas in the code. It's important for me to start to think about the implications of the code earlier in the process. Thankfully my engineering background makes me intimately familiar with the process of design iteration, so I never get too far along before I realize I'm doing things the hard way.

Today was spent on navigating all these issues vis-a-vis doors, vents, elevators, and switches. Although I'm not done yet, I can already tell I've made a huge improvement to Amoeba that will save me a lot of time and frustration in the future.

Art and Code

I've spent a lot of time since the last post working on level art for Amoeba. This has been both rewarding and frustrating. My background is technical: mechanical and industrial engineering. This has strongly influenced my approach to game development, not always for the better.

Video games are an interactive audio/visual art form, but because they are also complex logical and mathematical systems it's easy to forget that they're art when deep in the code. In many ways a developer can focus on purely technical details of a game and put off worrying about visual style, sound design, or music until the software skeleton is in place. This is how I've always approached the problem. I use placeholders for everything to make sure things work, then worry about replacing placeholders with actual game assets.

The advantage of this approach is that it allows me to focus on technical details without getting spread too thin working on too many parts of the project at once. The downside is that it's very easy to forget that you are creating an audio/visual work of art. You might be able to create a technical masterpiece, but nobody will appreciate it as a game if it doesn't also have beautiful art, fun gameplay, and a compelling story.

With Amoeba, I am trying to parallel my work on the technical systems and the art side. This is actually proving to be far more inspiring than I thought it would. I'm discovering a nice iterative interplay between searching for a visual style and deciding what elements of gameplay are going to be fun or interesting.

Tileset feels much improved, but lacks lighting effects to set the mood.

Here is a small sample of the current tileset. I'm getting much closer to the look and feel I had in my mind at the beginning of this project, but I have a long ways to go yet. The lighting is an obvious aspect that needs work, and one that requires a fair bit of programming as well.

I'm still plugging away at getting my environmental objects filled out; doors and switches are what I'm working on now.

And So it Begins...

I am a gamer. Games have powerfully captured my imagination since my earliest experiences with Oregon Trail, Where in the World is Carmen Sandiego, and King's Quest on the Apple II. Games represent to me a rich storytelling canvas that engages both the mind and the senses. Games like The Legend of Zelda, Metroid, Flashback, Marathon, Oddworld: Abe's Oddysee, and Half Life have given me rich "literary" experiences that co-exist with the best films, novels, and poetry in my life.

As I've grown into my adulthood I have realized there is an important dichotomy between the attitudes of creativity and consumerism. As much richness can be added to you life by "consuming" experiences in art, music, culture, food, nature, travel, there is a land of growth and maturity that can only be accessed through acts of creation. These acts can be great or small but the creative spirit, that which empowers us to add to the world what was once only in our hearts, is the key to the gate that guards that land.

And so I embark on this project called AMOEBA. Playing games has always been a passion of mine, but creating games is a new step that will, no doubt, challenge my intellect, art, persistence, salesmanship, and humanity.

Amoeba

Amoeba was conceived as a 2D platformer built around a single core mechanic. The player takes on the role of a sentient blob of goo that is able to absorb enemies to mimic their behavior and attributes. For example, absorbing a security guard might allow the player to take humanoid form, operate technology and carry a weapon while absorbing a reptile might grand a higher armor rating and a poison attack.

This core mechanic pushes the game firmly toward a puzzle-platformer style of play in the vein of Flashback or Abe's Oddysee. And like both of those games, my goal is to create a rich and compelling setting in which an interesting narrative can take place.

A good strategy for complex projects is to iterate constantly and to work top-down and bottom-up simultaneously. This is how I've been organizing my development on Amoeba. I've got my basic platformer mechanics working (running, jumping, attacking, etc) as well as a simple environmental system (walls, floors, doors, etc). My core absorption mechanic is also working at a basic level.

At the same time I've also been working extensively on finding an art style that works well with the concept and communicates the sense of place I'm looking for. I've gone through two fairly extensive mock-ups complete with character animations and environmental tile-sets, but I still don't feel like I've found what I'm looking for yet.

Current art style feels flat and lacks atmosphere.

Short-term Development Goals

My coding goals (bottom-up) in the short term are these:

1. Generalize player forms as much as possible to eliminate duplicated code.
2. Generalize enemy code.
3. Create 2 more enemies (lab tech and soldier) in addition to the existing security guard.

My gaming-systems goals (top-down):

1. Create tiered gameplay goals (mandatory, secondary, tertiary, etc).
2. Develop framework for player advancement on the power curve (upgrades, power-ups, collectibles, etc).
3. Explore absorption mechanic and enemy synergies that lead to compelling gameplay.

My refinement goals (iterative):

1. Design a consistent hitbox paradigm that simplifies environmental collisions.
2. Add more interesting AI behavior to security guard enemy.
3. Refine enemy list so each enemy both feels unique and has a purpose.

See you when I've made some progress!