A Shift in Code and Platforms That Provide Downward Opposition

There was a newer version of the base platforming code I was using that decided to implement. It provides several bug fixes, which is helpful. But most importantly it has built-in infrastructure that allows for jump through platforms and moving platforms. This code is a revised version of brod's work, created by a dude who goes around the Internet with the name "Ace." So one of those. But despite my apparent disrespect for the lack of originality in his online handle, his revision work is very useful. It was originally connected to a more vast engine of his but I severed it off since I'm not in need of the other features his engine offers. Transferring the code, I cleaned up the grammar to match that of the rest of my code and re-implemented the modifications I made to the previous set. This process went surprisingly smoothly with almost no problems. I was afraid that Ace's more complex code would present some problems I couldn't foresee, but apparently I am becoming a better programmer. Hurray.

With this new code, I was able to quickly add jump through platforms. Now those exist in my game, bringing me one step closer to realizing my ridiculously ambitious vision. Thankfully, after some experimentation with room transitions, I have already started to scale back the vision to something both more reasonable and interesting. That is a good sign. Always.

Earlier I had mentioned that some of the ideas I currently have for this project have it leaning towards being like Zelda. I was originally going to have large dungeons that consisted of large grids of rooms. There would be no scrolling of the screen, just individual frames. This concept is hard to explain in words, but an example of this is the overworld of the original Legend of Zelda, where the player moves from area to area, each area filling the screen. An other example can be found in a game like Knytt Stories. I ran into some issues making this work in a satisfying way however, and now the idea is that each dungeon is simply a small, one room affair, each with its own idea. I think this is an interesting direction to go in; it is a beautiful return to the simple, one room stages of early video games.

Up We Climb to Reach the Top

I added ladders.

They were actually pretty interesting to code. While they initially presented some major technical issues, most of these problems have been thoroughly handled. All that is left is one pesky animation bug that I am hoping will be more easily solved when the whole animation system is implemented. The player snaps to the ladder they are climbing and can get off either by moving right, left, or jumping. The controls here don't feel quite perfect, but I'm going to have to start designing actual play environments to decide on what works and what doesn't. This process is some time away, so I'm going to leave ladder behavior the way it is and move on to jump-through platforms.

The Beauty of Stealing Other People's Work and Flexible Dialog Systems

So I have realized that in my last post I didn't even really mention what it is exactly I am making. All I had mentioned was that it was some sort of action/adventure game that was far to ambitious. Well, it is indeed that. Basically, the game's temporary title is Zelda 2 Kinda Not Really. It is a side-scroller and it borrows some of the ideas (the good ones) from the typical pacing and structure of the Zelda games. So it's kinda like Zelda 2, but not really since it is more of a platformer and has no blatant RPG elements (because those usually are unnecessary, despite what modern design practice might teach you).

This project has been in development for a massive total of 3 days. I can just smell the success. Since I'm lazy and inexperienced, I was browsing the Game Maker Community forums searching for simple code that allowed for smooth, pixel perfect platforming. Nothing more, nothing less. I would build upon this code and add all of the actual features of the game. I found the perfect solution in a very simple script developed by a guy who goes by the name "brod." Smooth, adjustable jumping combined with horizontal motion that could handle any type of slope are some of the features I was looking for and this script delivers. It still has one glitch, but I am almost certain of its cause and I have seen some branches of this code that are supposed to fix the problem, so I will look to those when the time comes to eliminate it. And best of all, it is simple to understand and extremely flexible.


So with that in place and after some of my own modifications, I have ended up with this beauty of a test room.

Look at the irregular terrain! Behold the naked NPC's!

I get around to coding clothing sometime. I spent quite a bit of energy adjusting and then testing out different values that controlled the jump physics. Thankful the brod's script has several values that can be modified, and they give the designer a great amount of control. Currently I have something acceptable in place, but only until everything comes together will I know if it needs any more tweaking.

I have made some changes to the art style. When the player was talking to NPC's, the two characters blended into each other and created a lumpy mess of fleshy pixels. So, in order to make objects of interaction stand out (ie. stuff that isn't background material or detail), I outlined each sprite with a thin black line. This is possible because the 8x8 sprites are scaled up to 32x32 sprites.

 

 The first element I added to the game was something I have never done before; non-playable characters. I usually associate NPC's with eccentric and unnecessary comments, but I'm going to need them for this project. Right now they only have one behavior, which is just to stand around and maybe talk to the player. Of course, this means I also have already developed the dialog system for the game, and while it is definitely not finalized, its nice to know that I have finally reached the point where I can actually make one.

Each NPC can have different types of dialog boxes, dialog color, and dialog box positions. I will eventually add even more flexibility, like variable fonts, effects and so on. I wanted to keep the dialog quick and simple. Like I said, I was only taking the good ideas from the Zelda series for this project, and one of the most terrible things in that whole entire franchise is the super slow and annoying dialog code. "Oh, but what if the poor children accidentally skip very important text that tells them what to do in the game!" says Nintendo apologetically. Well, in that case, something is probably wrong with the design if it relies on text alone to convey important gameplay information. Obviously, there is a middle ground to how to approach the problems that arise, but I believe that quick and simple dialog works out best in the end.

 

Okay, I am now tried of writing. Above one can see what the dialog boxes in this game currently look like. With basic NPC stuff out of the way, I am now interested in adding in some more platforming fundamentals; on the list are ladders, moving platforms, and jump-through platforms.

Another Horribly Ambitious Action/Adventure Project that Can Only End in Disaster

Yes, it is true. I have fallen prey to the powers of childish ambition once more. "Hey guys," I say, "this new game will be the greatest game of all time. Just you watch and see! The story is epic and the game has like 340 hours worth of content. It is going to be amazing. I'm making it by myself and I think it will only take a month if I work hard enough." Everyone else just scoffs and rightfully so. I am a fool and the game will never be finished; once again it will lose cohesive direction or I'll run into some seemingly unassailable technical problems and it will be thrown into the massive heap of unfinished projects that has been rotting away on my hard-drive for years. Maybe some day I'll be some famous wizard of ludology and this junk would instantly turn into a gold-mine worth millions. Scholars around the world will analyze what I was trying to build, finding brilliance where there is none. Fanatics will take the games and finish them for a novelty effect; the arguments over what I had originally intended the games to be will be glorious.

Unfortunately, most of the stuff I had worked on at a very young age using programs like Klik'n'Play is lost forever. Which is no tragedy; it was all garbage. But in my hypothetical dream future this fact would inspire all sorts of speculation. These horrible, horrible games of the 7 year old mind would be legends. There will be archeologists digging through landfills searching for the hard-drive that holds these relics.

That is a bit of a tangent. Hope you enjoyed my very arrogant indulgence of ego! Eh, so my point is that I have started some casual work on another game that, based on early signs, I will not get around to finishing. I am, though, intending to learn some new things in the process so that my time isn't completely wasted.

To start things off on a brilliant note (and by that I mean the most stupid note I could have possibly started them of on), let me speak briefly about what I am currently doing with the art style of this new project. About a year ago I created an 8-bit color palette (256 colors) for a modification of Doom that I was considering. I ran into some problems with custom fonts and scripting in that engine so my intentions never went very far. The color palette I had created was interesting because instead of focusing on a wide range of tones, it instead tried to have a variety of color hues. I was intending to make something a little more colorful than the typical stuff people do with Doom.

When creating art I want a consistent set of colors to work with. I think it has to do with my perfectionism mixed with the fact that it helps to keep the visual style consistent. For all my pixel art I use Gimp, which allows me to load and then use color palettes like this one. So, ever since I had made this palette I have been using it for all of my work. So, for instance, all the graphics from Reconstructing S-31 used this palette.

However, after working with the palette for a while and especially after doing some of the work for my current endeavor, the very limited selection of tones really started to become a problem. Since I was no longer working within a 256 color limit, I decided to expand this palette into this:

This palette has the same color hues but greatly increases the amount of tones to work with. Now why was I running into so many problems with the original palette? Well, my current project consists of 8x8 tiles, making the fidelity of the sprites extremely low. The reason why I choose to do this is because it allows me to make finalized artwork really fast, since it doesn't take very long to make something that is 8x8. Drawing it so it looks good can often times be challenging, but having an expanded color palette allows me to add more details.

The most difficult things to portray in 8x8 sprites are, of course, the characters. However, I did come across a solution early on. An independent developer who goes by "oryx" created some really expansive sprite sheets for an 8x8 rogue-like. Currently he is using the sprites for the game Realm of the Mad God, but I've seen them used else where as well. They are really quite wonderful and they are free for anyone to use. My characters are based around the general shape of his, but I intend to go in some different directions with how I shade them.

Oryx's sprites can be found here: http://forums.tigsource.com/index.php?topic=8970.0.

And, finally, a naked dude. Enjoy.