Okay, you've probably caught on now: I have been too busy actually working on the game to give super detailed updates on this blog. Hopefully you've enjoyed the development videos I've been posting, because for the time being that's what I will continue to post.
Here's the last few video I've put together that show my progress:
1. Super Dash
I'm testing out an ability which lets the player go really fast.
2. Step Triggers
These are switches that you activate by stepping on a switch on the ground.
3. Delay Triggers
A special entity that simply delays a trigger and then relays it to the next one. Good for sequenced events.
4. Idle Animation
Allison put together a nice idle animation for the main character.
5. 3-hit combat demos
Playing with a simple 3-hit combo system.
...same thing, experimenting with variable knockback forces. Also we've started prototyping a new environment.
Lately I've been moving. Not much time for blog posts, but I've still got some work to show! More videos!
1. First up: falling down transitions. I wanted to put a little twist on the fade out / fade in 'falling' transition. This was the first draft:
2. After some feedback, here's what I ended up with as a final draft. Way better.
3. Just for fun, I added some bugs.
4. Some people suggested that the bugs shouldn't be squished when you're holding still. Someone else took it further and said that they should climb up you. So I did that.
Although I haven't been updating this blog as regularly as before, it's only because I'm too busy with the actual game programming it self. I'd like to share a few videos that I've created over the past month or so.
Just a fun little demo of dynamic floor tile scripts.
2. Persistence
Here's a video where I demonstrate values persisting between level loads. When the bridge spawns, the player can leave the screen and come back and it will still be there.
3. Dashing and Torches
In this video, I've swapped out the old (temporary) character art for a new (also temporary) sprite that represents the actual dimensions of the character. We chose a large head so that the player can fit in a more square-like area because we want the visual appearance to be close to the collision box, so the player can gauge whether or not something is going to collide with the player. This video also features dashing and dash-turning. And some fireballs. And a shield.
4. Switches
Implemented some switches. You can also see the design of the main character taking shape. One of the switch types is a basic toggle, the other is timer-based.
5. Fog
A cool fog effect.
6. Doors
A set of switches that controls the opening and closing of a door.
7. Section entry events / group destroy triggers.
This final video shows how something can occur when a room is entered (the door is closed) and how destroying a group of tagged entities (3 blobs, in this case) can trigger something else (door opening, wall torches being lit, fog fading away.
I've actually been spending a considerable amount of time lately working with the artist on the project, Allison. We've been slowly nailing the style down for a number of things and anticipate future art development to become more and more rapid as we settle into a groove. Refer to the following screenshot:
Anyway, here's what's new since last update:
1. Improved cave tiles. I'm not going to write too much here, but things are looking better now. We're still going to have another pass at them later.
2. Parallax tiles underground. You can't see it in motion from the screenshot, but the underground spikes are parallaxed, meaning they give the illusion of depth by scrolling at a slower rate than the foreground.
3. Player proportions. You're seeing a temporary placeholder sprite as we test the final dimensions of the character. The goal here was to keep the player's collision model at exactly 1x1 tile (that's 32x32 in-game units--actually, we're using 30x30 so that the player can comfortably fit between two tiles). The older character also had these dimensions, but was much taller. It's pretty important to me that the player can accurately and easily gauge, visually, the collision model of the player (so that they know when they're going to get hit by an enemy or a projectile), so the closer the character is to a 32x32 box, the better. Obviously we can't make the graphic square, though, because that would look silly.
4. Better stylistic lighting. Since lights can be any texture we want, we chose to paint a nice cartoony glow instead of the straight gradient of the old textures.
It's been a couple weeks since my last substantial blog post, so I'd like to share what I've been working on during the last week: a new monster I've tentatively dubbed the Lurker, but I plan on giving it a more original name in the future. Note that enemy development isn't normally going to take a week per enemy--I was busy with some personal things. On top of that, this enemy is more complex than my first enemy, the Blob, and required a few engine infrastructure changes to implement. I'll go over those in detail, too!
I wanted to add a new enemy which will appear in the first area of the game, Gloomstone Cave. The idea is that you'll be facing this enemy in a few spots, but initially you won't have a permanent weapon to defeat it with. So, you must come up with more creative ways to pass the first few of them, whether it be total avoidance or using an alternate means of damaging them. Later on, when you have a weapon, they won't be quite as menacing, but the initial encounters should definitely impart fear into the player.
The Lurker waits underground in a certain spot and emerges if the player gets too close, bursting out of a hole in the ground, blowing debris everywhere. Here is mytemp MSPaint art that I used as a placeholder for the enemy sprites so I could start working on the programming immediately:
This is why I'm working with an artist. Body/front/side/back views.
I took a series of videos as I developed the Lurker, so you can see how it's evolved. At the end, I'll share the source code so you can see what the latest programming model against my engine looks like!
Part 1: The Lurker Emerges
This video shows the lurker enemy popping out and swaying in a sinusoidal motion. It doesn't do anything interactive yet.
Part 2: Moving around, basic attack
The lurker moves around to avoid the player, and randomly attacks him if he gets close. Then it gets stuck in the ground, and that's it.
Part 3: Real art, attacking, taking damage
At this point, Allison, the artist, started working on the graphics. The initial design was a cool and creepy monster with a sideways mouth, with plans to animate it chomping the player. You can see the down-facing graphic in this video. Also, I made it so you can hit the head with weapons, and a very basic 'death' animation for the enemy.
Part 4: Better art, cool hit colors, refined movement. Better death animation.
I make various (subtle) changes to the movement behavior of the enemy. Allisonchanged the head design of the monster to a more traditional shape, drew the other angles of the head, and animated the arms on the body segments. So now it's like a creepy dragon caterpillar. I added a more satisfying death explosion animation.
Part 5: Bigger, badder, more explosive
We increased the size of monster. A way better death animation with a bunch of explosions for the head, and a prettier hue shift during hits.
Part 6: Snapping animations, cave shards. Job's done!
I put the monster in its natural habitat, the cave. Allison added animation frames for the head so I can control its mouth--when it pulls back, it opens its mouth, and clamps shut as it attacks. Also, it opens its mouth in pain when I hit it. Allison also made better looking shards that explode out of the ground when the lurker emerges, and I added a rumbling sound (and a temporary hit sound) for the emerging stage. Check out the final product!
Source Code
Disclaimer: I don't typically comment code except for explanations of 'why' (not 'how'--see this article) but I've marked this example up extensively for clarity. I also don't typically have classes that are anywhere near this large; my average class size is quite small, generally following the Single Responsibility Principle. I would probably consider breaking each enemy state into its own class. But, for the purposes of this example, I'm keeping this all in one class (for now).
Anyway, the full source code can be found on this pastebin, right here.
That's all for now. Next I'm going to be fleshing out a bit more of the first cave area.
