Learning

It feels like more and more of what I had been doing using the Torque editor is now being handled by script. This seems to come from me just doing things however I can, then figuring out a better way later. Sometimes due to preference, sometimes due to necessity. There are blocks in Hue that change their appearance when you change colour, and up until now they had been considered "objects" in the game. I put them into place, they had a class, and some scripting changed which sprite was displayed. Now they are tiles, with coordinates set in script, and a sprite set in script. This is a bit of work setting them up for each room, but it's really not much worse than placing hundreds of these things carefully and hoping the editor doesn't crash.

"Hundreds of these things" became the problem. In room 2, there is a HUGE performance hit. This is due to having way more of these blocks than room 1 ever had. Using tiles instead should fix this, but I actually haven't gotten far enough to say for certain yet.

It feels good to learn a more efficient way to do things. I have replaced almost everything in the game at least once now, which is funny to think about. I don't really have much to show for the year I've spent on this game, but I have gained a lot of knowledge and have a strong foundation to work off of now.

Moving on...

After spending months refining my gameplay inside what I've been calling "Room1", work on Room2 has officially begun.

I actually designed the first 7 rooms on paper a long time ago, so I don't have to think too much about puzzles and stuff as I'm building it. Just trusting my past self and making little adjustments here or there. I went through the puzzles themselves over and over again on paper, revising most rooms several times. I'm pretty confident they all make sense.

The core gameplay still isn't actually complete, but for my own sanity's sake I'm moving on. Climbing under things still hasn't been implemented at all in the current prototype. It worked in my old one, but that one had its own problems...

Anyway, here's a screenshot from the first real puzzle in the game. Meant to indicate to the player that they need to make choices and really think about how the colours interact with each other.

Screenshot Saturday

I managed to get a "spawn" system sort of working. I was having trouble with it last night, but after some sleep it seemed to click into place. Time to start adding more rooms to this thing.

Here's a screenshot.

Roughing in animations...

I'm hoping to get rough versions of all the player-character animations in the game very soon, or at least made and ready to drop into the game. I've decided it's counter-productive for me to focus too much time on animation, so as long as I get a decent look/feel I can touch up details later. Here are some of the images I have so far.

Again, these are rough animations/sprites. I'm a fan of the proportions and overall look, but they definitely need some touching up eventually. May go with the whole thick lines thing though... gives the game kind of a cool feel. To be determined.

I've also decided to add a run button, because I want players to be able to slow down and have minute control, but to also be able to speed up if they need momentum for a jump or if they GOTTA GO FAST. Should be easy to implement, hoping to have that in this week.

Finding the right "game feel"

In my mind, the core of any great game is great gameplay. Even outside of the level design, the graphics, the sound, the story, the objectives... a great game just FEELs right. I'm aiming to match that.

But it's not as easy as it might seem.

There are a lot of things to consider, especially with a 2D platformer. Do I want my character to build up momentum and then slide a little bit, like Mario, or to move at a set speed and stop on a dime? Do I want jumps to have a set height or do I want the player to be able to control it? Movement in the air doesn't really make logical sense... should I include it anyway because it feels natural to gamers and adds additional controls? How far should the camera be zoomed in? To what extent should the camera follow the player?

These are all questions I am asking myself and have been asking myself for months. As of right now I have tentative answers, but nothing is set in stone. The character does build up momentum and slide a little bit, but I want it to be more subtle than it is right now. You do control your jump height based on how long you hold down the button, and you can move in the air. The camera is something I am constantly tweaking and it's sometimes surprised just HOW different a game feels with different levels of zoom. I am also constantly touching the movement speed and jump height and how strong gravity is. It's a very delicate balance, and touching one thing often means touching everything else.

Torque 2D has a built in physics engine that is incredibly useful, but can also be a bit limiting. When I want my character to grip the floor more to prevent too much sliding, it also reduces jump height. When I increase the jump height (which is technically a vertical speed variable) it just makes the character jump faster now without actually going as high as I want. All little quirks I will be attempting to work out very soon. I have been working a lot on animation because I do believe that having a fully animated character that looks at least somewhat close to final will help with adjusting the game feel.

Game feel is incredibly important and not to be taken lightly. I have played numerous amateur/indie games where the gameplay feels just a liiiittle off, and it has a notable negative impact on the experience. Game feel is too important to not focus on. I'm also very strongly considering changing the scale of every level I've designed so far to accommodate better game feel. It's that important.

New Rough Animation/ Pencil

I recently downloaded an open source animation program called Pencil. I like it so far, aside from some little quirks with the interface. It has been incredibly useful for roughing out my animation a bit more, and the result of an hour or so of messing with it is this:

Still very early. I still need to touch up the timing a bit (it's a little too consistent, needs to look more natural) and then polish it up with more appealing art but... it's a huge improvement over the way I had been animating before. I was just drawing layers in GIMP and hoping they looked okay when I exported as a GIF.

Side View

Here's a possible pose for my protagonist's walk/run/jog/whatever cycle. I spread my layers out to show some progression. Still not totally happy with the last one (the left leg specifically still looks off to me) but I've pretty much sold myself on this character design. I do need to solidify her proportions, and probably make a model sheet/style guide to be 100% sure I don't screw up. I'll probably use this as the basis for creating a walk animation and see how it turns out.

Character shape/motion study

I've been fortunate enough to have a friend lend me a drawing tablet for a little while. It's been a good excuse to doodle a little bit. I started messing around with the shape/form of my character and working out how I want her sprite to display in-game. Through my prototypes thus-far I've learned I don't really like to have the character all the way in profile. It was actually weird for me to realize that most side scrolling games don't put the character in profile, even though everything is flat and you're moving left and right.

Anyway, I'm not going to act like I'm a great artist but I do have some formal art training and I like how these scribbles turned out, so here they are. I'll probably never clean these particular scribbles up into actual drawings, but the exercise was good.

Character concept art

Main character concept art I drew tonight.

The tentative story is that her friend wakes her up in the morning to show her something cool he found (some sort of large, pulsing, floating black thing in a nearby valley). He gets sucked into it, she follows him. She ends up inside and he's nowhere to be found. Adventure begins.

I have a lot more planned out, but I don't want to give too much away. 

October Updates

Current Hue prototype. http://t.co/3CUb1xc8

Also, I just finished submitting Hue for government funding! I'm really excited! Even if I don't get it, it should be a cool experience getting feedback on what I can do better if I try again (they apparently do that).

It's been a while...

I stopped updating this because I figure nobody really reads it. Just for the sake of tracking stuff, in the past 3 months I have...

• Done a bunch of level design stuff on paper.
• Made an effort to solidify the core game design and story.
• Changed the way just about everything in the game works.
• Move speed.
• Jump height.
• Camera zoom.
• Size of character.
• There is now momentum behind everything (rather than the character just stopping and starting on a dime).
• Complete overhaul on how repelling/bouncing works.
• Complete overhaul on how sticking works (still in progress)
• Applied to become a corporation so I can apply for a grant from the Canada Media Fund.
• Played around on my guitar and acted like I was composing music.

The overhauls to repelling and sticking were for a few reasons:

• Objects in the game are now 1 single collision volume instead of 7 volumes/triggers (had top/bottom/left/right repel triggers, 1 main collision volume, 1 stick trigger, 1 smaller collision volume "core" inside the stick trigger).
• Looking ahead, they make it easier to throw different animations into the mix.
• I didn't like the way either of the old mechanics felt... they were functional but they didn't feel quite right.
• Repelling specifically now multiplies the character's speed, which means getting a running start or jumping from a great height actually makes a difference. I always wanted to do this, but a few months ago I simply didn't know how.

Work in Progress - Character Sprite

So, I actually simplified my character from the initial sketches I did. But, I think the design has more character now. I've viewed this animated and it looks pretty good. I'll leave you in suspense for now. I have a lot more animation left to do and quite a bit of coding around it. I also need to clean this one up a bit... it's a little hard to maintain a balance between going for a decidedly low-tech and simple look and making things look nice. 

The amount of work I have left to do on the character is a little overwhelming, but I basically know what I need to do. Lots of frames and lots of code making the frames show up at the right times.

"Repel" Tiles: A History

The tiles used for objects that repel the player have been through several iterations. Here's a breakdown of all of them so far. Keep in mind that each individual coloured square in each of these splits up into 9 pieces for tiling purposes (top left, middle middle, bottom right, etc.).

Concept 1: Animated diamond tiles

Logic: they point out in every direction, and the animation makes them similar to those boost strip things racing games have (in my head).

Flaw: This doesn't really tile that well, and the animation was annoying to me. Plus individual pieces liked to not be in sync. I'm sure I could have fixed it somehow, but I had already decided not to use this idea by then. I'll spare you the animation, but as you can see above there are two frames for each colour.

Concept 2: Pixely lines

Logic: At this point I think I was convinced I was going to make an Atari-esque looking game, so I went with that. The lines to me seemed to more clearly illustrate "you bounce off this thing" to me than the diamond idea. Plus this one tiles fairly well. This remained my placeholder image for quite a while.

Flaw: It doesn't look good. Doesn't match my current art direction.

Concept 3: Diamonds revisited.

Logic: I was sketching out ideas for tiles with a pencil and I ended up going back to this (sans animation). I wanted it to look at least sort of made-of-stone. I think I forgot how bad it looked when tiled. Here's how bad it looked when tiled:

Flaw: See image above. It would look alright if I tiled it differently, but the way this game is built that would mean a lot of extra work. I was basically faced with the choice of writing several new lines of code and babysitting the classes of all my tiles every time I build an object or coming up with a new idea. I still really like the way these look as squares, so it feels almost like a waste not to use them. I tried just tiling them as individual smaller squares, but it didn't look too hot either.

Concept 4: Zig-zagging bricks

Logic: I basically arrived at this while trying to make the diamond tiles tile more nicely. I really like the way it looks, but...

Flaw: It's just too solid looking. It looks like a wall you would hit and then stop. I tried to use the zig-zagging and alternating colours to suggest motion, but in the end it's still a brick wall. Plus, from a game design standpoint, it's similar enough to the brick wall that it sends the wrong message to the user regarding gameplay. Assuming the player knows that the way the blocks look dictate gameplay and the straight bricks stop you when you hit them, so the slanted ones... make you move in a diagonal line? Well, sometimes... but not always. It also looks like it maybe repels you in the direction the bricks point (which is open to interpretation based on how you look at it), but again it only does that sometimes. So basically, the designer in me hated this idea despite my eyeballs thinking it looks cool.

Concept 5: Jelly blocks

Logic: Once I accepted that zig-zags and diamonds weren't going to work, I had to think about what I could possibly do to suggest an object that will repel the player. Anything involving circles would have the same problem as diamonds. Lines, a la the pixel blocks, felt like they would always look like placeholders to me. I also decided that these blocks shouldn't be stone. So I tried to make them look like rubber. Now they look more like jell-o to me.

Flaw: I'm going to stick with this design for now, but I'm far from married to it. I think it might be slightly too cartoony. They also remind me of something that would be in a Flash game from 1999. If I come up with something better I'll change it. I'm probably going to animate them slightly when the player touches them (either some kind of wobble, or just a blur effect to indicate vibration and make it look a bit more kinetic). So I guess that extra bit of work is a flaw, but whatever. Oh, and it just hit me that the right side will look almost identical to a stick object if it's a larger wall. I need to fix that.

New tiles

First batch done.

First prototype level working

I had a breakthrough this past weekend and completely scrapped and rewrote part of my collision code. Solved almost all of my problems, and with a little bit more work I had what felt like a very solid prototype. So I built a level... which caused all new problems. Such is game development, I suppose. Anyway, I fixed most of the major bugs and now I have a complete (albeit short) level.

Here are screenshots.

And here's a look at the editor.

Music

I've been busy having a life this past week, so I haven't really done much work on the game. The most I've done is screw around on my guitar and think about music. Trying to write some songs. I think I have a bit of a foundation.

Here are some videos of stuff that is influencing my music ideas. I'm not going to pretend it'll be even nearly as good, but yeah.

As I think I've mentioned before, all of the music I make for this game is probably going to be made with guitars. I will probably play over myself a bit, but the riffs themselves will be pretty simple. I have a couple I've been screwing around with and trying to build on. It still feels really early to focus too much on music, so I haven't really put any real effort into it beyond noodling around while watching TV. The music is part of my overall "vision" though and actually influenced me to change the art style form simplistic pixel art to something a bit more fluid and "loose".

Prototype gameplay video

The basic mechanics are in place. Here's a video.

EDIT: Ugh, this is hideously low-res. It's not worth it for me to bother re-uploading this right now, but next time I won't be uploading directly into a blog post. Still gets the point across, for the most part.

New screenshot

I took a screenshot my test room in Torque, just to give an idea of what actual progress has been made in ways a regular screenshot wouldn't.

Notice that the blue square has overlapping rectangles on each side. Those repel the character (who is a grey square). I will be applying that functionality to the rest of the squares shortly. The smaller squares within the larger squares indicate stick functionality. I still have to add that for yellow and blue, but the code is all there. All of the squares are in a red state right now by default even though the player is grey.

After I work out a couple of bugs, I might start building an actual level. I expect there to still be bugs, but hopefully I can get this thing in front of people and get some feedback or at least get some moral support.

Notepad++

Started using Notepad++ instead of plain 'ol Notepad. It's actually really useful to be using an actual IDE instead of a text editor for coding. I actually have Visual Studio as well, but I like the relative simplicity of Notepad++. I recommend it highly, at least for hobby level coding. Struggles right now are mostly around collision. I have started rolling out experimental collision types (sticking and bouncing) to all objects. For some reason the sticking acts weird with violet. There has to be something in the code I forgot to port over properly, but me in my current state (tired) isn't seeing it. I also made myself a bug database in Excel. My day job is as a QA tester, so it sort of pains me to even do it but at the same time it feels very right and natural to be recording bugs I find and tracking whether or not I've fixed them.

Also, here's an updated version of my run cycle (from about a week ago, haven't touched it since). I can adjust the timing in Torque and don't really have a proper animation program, so this is basically each frame being shown in unison with equal timing.

I want him to move with a level of uniqueness and character, so I'll be playing around with this more until it feels right. I can't do too much considering I have to be able to implement it into the game and have it look/feel natural (gameplay comes #1), but I want the character to feel as fluid as I can muster. The web series "Baman Piderman" does a great job at fluid, but I don't have any illusions of animating even nearly as well as Lindsay Small. Plus characters that floppy wouldn't work well for this game. Maybe another game someday. Possibly worth noting: Watching a livestream of her animating an episode of BP is part of what motivated me to start working on animation.

Preview of my amazing 2D animation skills

My initial plan with this game was to have almost non-existent art, probably no music, probably no sound effects. I changed my mind. I'm going to do some simple art, music and sound effects myself. "Simple" art includes 2D animation, which I totally took a class for like 5 years ago. I also took a bunch of art classes, so I figure I might as well use my entry level art/animation classes for something. Here is the first pass of half of a run cycle. Click the red square to view all 4 glorious frames of actual animation.

It's even sloppier than it probably could be, since my background and initial guide sketch show up as their own frames. You get the idea though. Also, I don't really plan on making this much more complex. Basically just cleaning it up. The dude's gonna be solid colours, possibly with shadows. No face, hair, clothes or any of that.

Regarding music and sounds... I am probably gonna do minimalist electric guitar (i.e. my skill level) for the music and do some home foley for sounds. The goal here is to do this whole game myself.

Oh, and here's what it looks like with every animation layer visible (just for fun):

 

"Hue"

Tentative title time.

I spent a lot of time labouring in my head over alliterations, puns, portmanteaus... then I thought about how I want this game to come across in a conversation and what sort of image I want to project. I decided that one word, short, to the point, would do this best.

Torque

Game Maker is often what amateur game developers that don't want to program use to make 2D games. I tried it, had a bit of success, but ultimately I didn't really like the interface. I tried out Torque Game Builder and liked it quite a bit more, so I shelled out a bit of cash for the indie license (I had done the same for GM as well) and that's what I've been working with.

I almost went back to Game Maker when I was having some scripting problems I knew I could solve with the graphical scripting stuff it has (which is GREAT by the way, if you really don't want to script anything yourself), but overall I have been happy with Torque so far.

Anyway, here are some other games that have been made with TGB: http://www.garagegames.com/games/2d-games

There are a few semi-major indie releases there. I think I own at least one or two of them, but it's hard to remember sometimes with all of the indie bundles I buy.

I actually solved the problem that made me want to go back to GM just today. In order for a trigger to function in TGB, you have to have an object actually collide with it. If you have any code in said object that is tripped when you collide with things (like if it's a player character that collides with walls, for example) it will react weirdly with the trigger. I solved this by mounting an invisible collision volume to my character that activates the trigger. Worked out perfectly. Now if only I could have all those hours of trial and error back...

Yeah! Learning!

First look at what I'm working on right now.

Over the last few years I have started and stopped various projects, with a lot of the problems coming from them being a bit too ambitious. I attended PAX this past summer, and during the PAX10 panels there was a very constant theme - keeping things simple. So I remembered back to the core mechanic of a concept of mine I came up with when I was attending the Art Institute (and wrote a 30 page document about), and decided that instead of using it for a 3D action/adventure game I'd use it to make a 2D platformer. And you know what? I don't even need nice art. I decided I'd just do it, use whatever crappy art I can slap together (mostly focusing on the art representing the game mechanics) and release it for cheap or free when I'm done.

So what is the game mechanic? In a word - colours. The environments are largely made up of coloured blocks, and you yourself play as a coloured block (this may change to an actual character later).  You pass through "gates" that change your colour, and depending on what colour you are you interact with the environmental blocks differently. This is based on a colour wheel made up of just primary and secondary colours. You stick to the same colour, bounce off the opposite colour, pass through adjacent colours and triadic colours are completely solid. The reason for the gates is so that the level design can dictate what colour the player is, thus allowing more compelling puzzles/challenges and less guess work on the player's part. I am building this with Torque Game Builder, which seems like a solid platform thus far.

Anyway, here are a couple of screenshots of my test room. Right now all that works is touching the gate to change colour (I juuuuuust got this working, so there's only a red gate for now... I also have debug keys that let me change colour at will) and all of the sprites changing each time you change colour (to represent how you interact with them). I have a lot of work left to do, but I'm making progress and I'm excited about it.

One big wake up call was just how long it takes to do simple things. Those bigger blocks are made up of 9 smaller blocks each (to allow me to create objects that aren't just squares). For some of them, they are 9 unique blocks. In order to make things customizable, I had to script all 54 blocks seperately. I spent a lot of time ctrl+c/ctrl+v'ing code last night and making little changes for each block. I can't help but think there might be an easier way, but I don't know it.

I don't have a title yet, but I'm thinking probably an alliteration that refers to colours somehow. "Chroma Castle" is a front-runner, since my only idea for a story right now involves it taking place inside a castle. I'm purposely keeping things simple so I can actually get this thing done, but I have ideas bouncing around in my head for a sequel/successor already.

Alright, time to stop talking about it and get back to work.