I'm Back

This blog has been on hiatus for about a year... I considered making a post explaining why, but I get the impression that no-one reads this blog. This is mostly my fault, of course! I've never been one for branding and advertisement, so it stands to reason that this place would be pretty empty.

I'm thinking of continuing where I left off, and trying to get more eyes on my work. But first, let's talk about where I was and what I was up to.

 

The Blocky Elephant in the Room

If you have been following this blog, you can probably guess that Minetest was the source of my disappearance. As I became more familiar with the project, I got the impression that I would need to invest a lot of time into helping it along. As a result, instead of leaving it as a side thing I dropped my other projects and invested my time and effort into it.

I don't regret doing this, but I'm also not sure how productive it was. RPG16 got a lot of love from the community, something I'm quite proud of! On the other hand, attempts at game development were bogged down by annoyances and engine limitations. Looking at the engine itself, it became quickly apparent that a lot of important things were broken or missing. So, I dropped that project and started working on improving the engine, telling myself "It will take a while, but once the engine is good I'll be able to make something cool".

There were some problems with this line of thinking:

1. There's a ton of work to be done, and not enough people doing it
2. The pace of development is greatly slowed by the combination of strict standards and a small core team
3. The standards can't be loosened because there's a fairly large community expecting backwards compatible and bug-free updates
4. Joining the core team would effectively cut my own development time

This creates a cyclical problem, resolving the reasons that development is slow would slow development. Worse still, this was taking me even farther away from my original goal. Just resolving blockers was turning into a bit of a nightmare.

In the end, I decided to cut my losses and leave. I suspect that I could invest 5-10 years into Minetest work without seeing any "return", and I just can't justify that kind of thing. I don't hold anything against the developers and community though, and I sincerely hope they can prove me wrong. I'd like to come back to a better engine someday.

At the very least, my time in the Minetest community taught me one important thing: I have the skills to make work that appeals to others. What I'm really missing is visibility.

How About Art?

On a happier note, my art practice has been progressing very well! This year I've been able to accomplish one of my original dreams and branch into landscape art:

I'm still learning a lot, but seeing the strides I've made over time is very exciting. I intend to continue for the foreseeable future, with weekly art streams on Twitch and pieces posted on my Twitter. Follow me in either of these places if you'd like to see my work as I make it.

 

The New Plan

I think that mostly wraps up the last year or so. Now that I have more time to myself, I'd like to continue my old projects and revitalize this blog a little. One of the first things I plan to do is rebuild everything under a new blogging platform. The nature of what I make has shifted over time, and I need something that can better serve my needs.

In addition to programming projects, I'd like to be able to post art pieces, photos, development resources, etc. on this site to give people more reasons to visit it. And finally, I need to start sharing and advertising my work more. There's no point in rebuilding a site like this if there's no community to enjoy it.

Art Project - RPG16

Ever since it came out in high school, I've really loved Minecraft. Despite never mentioning it here, I've sunk hundreds of hours into it over the years. And that's why I'm worried about the future.

Some years ago, Microsoft bought Minecraft. They haven't done anything crazy like the doomsayers claimed at the time, but they have gradually de-emphasized the original Java version in favor of new editions and spin-offs.To my knowledge, those new editions

1. Don't run on Linux
2. Aren't moddable
3. Have been more aggressively monetized with MTX and DLC

None of this stops me from enjoying Minecraft, but it does make me wonder if someday I'll be locked out of the game entirely.

To try and avoid that problem before it happens, I've been looking for alternatives. As far as I can tell, the only really active open-source block builder is a little game called... Minetest.

Nothing in this world is easy though, and Minetest has 2 little problems...
Warning: Strong opinions ahead

It looks bad

As you might expect of a volunteer-run effort, most of the content made for Minetest is made by non-artists. When you start a new game, you're likely to be met with a scene like this:

Not only are most of these textures worse than what Minecraft offers (and it's not exactly known for amazing graphics), there's like 3 different art styles in this screenshot alone!

Like Minecraft, some of this pain can be alleviated with texture packs. Or it could, but for 3 problems:

1. There are very few texture packs
2. 90% of the texture packs look as bad or worse (and indeed, many of them are just the default textures run through a filter)
3. The good-looking texture packs are extremely limited in scope, leading to nasty stylistic clashes with the unaltered content.

Well, at least the game's great fun! Right?

It also plays bad

Whoops.

Now, to be fair this is highly dependent on certain parameters. Minetest itself exists more as a sort of 'platform' that games can be built off of rather than a game itself, and there are a handful of interesting and promising games to play. However, the community almost universally considers the default game to be unenjoyable, and even the coolest games still feel incomplete, unpolished, and just generally not as fun as I'd like...

All of this leaves me in a pickle. I don't want to stick to Minecraft, but I can't see Minetest as a viable long-term way to scratch my creative survival itch. But then, a thought occurred to me: What stops me from fixing this myself?

Introducing: RPG16

Because it seemed easier, I decided to tackle problem 1 first. Consider the following:

My goal with the RPG16 texture pack was to make a big complete texture pack with a fun 16bit RPG look.

Whatever you think of the aesthetic, the visual consistency is much improved. Personally, I'm much happier with a game that looks like this, and I believe that my texture pack makes Minetest visually competitive with its rivals.

I released the pack towards the end of July. And so far, onlookers seem to agree with me! The community have given my textures a fair bit of praise, and I've been busy updating the pack with more content.

If you play Minetest and you're interested in trying this out, you can find it here.
Just for fun, here are a few more screenshots:

A fork in a river

A wasteland of cracked dirt and burnt trees, with some mushrooms on the side (Work in Progress)

Unique armor sets (Work in Progress)

About that gameplay...

This fixes the first of my complaints. However, I still don't feel at home with any of Minetest's current offerings. Ultimately, I'm going to try making a fun and polished game that matches RPG16 in quality.

It's going to be more of a long-term back-burner project, and most of my other stuff will be taking priority. Still, I fully intend to try making more fun content for myself and others to enjoy.

Art, Take 2

Exactly one year ago, I posted some images showing my progress practicing pixel art. I've continued practicing since then, and I think the results are quite solid!

Let's get started with a quick review of the past year. Unlike last year's mostly unstructured practice, I've tried to aim for a few weaknesses in my art fundamentals and improve them. The main core skills I focused on were light and perspective, though I've been tentatively playing with anatomy and proportion lately. I also joined a couple of pixel art communities, which have been a very helpful source of critique.


With the stage set, let's make a few direct comparisons to last year:

Trees

Rocks

Tilesets

Click the image for a full-size version

As you can see, I've made some pretty good progress! Of course, I did quite a bit more than this: Here's an album with some of this year's finished work.

If you're interested in seeing more as I continue practicing, I occasionally post work on Twitter and Pixeljoint.

Making the first Halberd game: There's no math in this blog post, I promise!

In the last two posts I did a ton of math, all to make a squiggly line. That's peak efficiency right there, nowhere to go but down!

Anyhow, today will be a little more hands-on than that. To that end, I've produced a gorgeous tileset:

Being serious for a moment, this tileset should cover all of my basic needs for laying out a path. It has 3 colors, representing floor, stairs, and wall. For a  little winding path in the foothills of a mountain, that should be all I need to start with. Next up is the map itself:

This is the first time I've really been able to appreciate the scale of what I'm building. It's big, bigger than I'd really pictured in my head! And of course, I'll be building several areas of similar scale. It shouldn't be a problem, but man. That's a lot of map.

Well there's no time to spend crying over map dimensions, so let's dig in. First of all, I can cut out the margins...

...3 minutes in, I feel the sweet embrace of Carpal Tunnel Syndrome approach and hastily add a 'paintbucket' tool. Some limitations are just too harsh.

With that roadblock out of the way, putting together a path that mostly matches the calculations from earlier is child's play:

...it's not the most awesome map I've ever seen, but it'll serve as a good template to work with. Next, I abuse the properties of Manhattan Distance to make the path much more interesting with little change to its actual length:

After measuring, this path is pretty close to my 250 tile goal. Finally, I widen it out a little bit:

I can fix any errors and smooth things out as I go, so this feels like a pretty good base to work with. Next up, we need some art!

Art, and problems

Over the weekend, I assembled the start of a tileset for this mountain path:

One thing probably stands out here--There's a lot of brick, but not much natural stone or dirt. I tried a few rockier walls at first, but I had trouble getting them to look good with the rest of the tiles. In the end, I decided to go with retaining walls, as you might see in a couple spots on a well-maintained trail. I'll probably keep looking for a good rough stone wall for some of the higher parts of the trial, though.

Once that was done, I put the new tiles into the map and came to a terrible realization:

The walls have inconsistent heights, royally screwing up the perspective. It's blindingly obvious in retrospect, of course the edges of the terrain need to line up!

Unfortunately, this means that I have some fixing to do.....

Making the first Halberd game: Measuring foothills

In my last post, we did some simple calculations to estimate the amount of walking and combat to put into the game. Now, I'm going to use that data to do some real testing and level-building. But first, let's do a little more math.

Right now, Halberd's ability to resize maps is rather clunky. To make up for that fact, I want to get an idea of how big any given map should be before I make it. We can do this because we have the final length of the path the player has to follow: 250 tiles.

When in Manhattan...

The player won't have free movement in-game. Instead they'll be locked to the tile grid, with only north/south/east/west and diagonals available to them. Since position is locked, They're probably not going to take diagonals too often. So, we can get an estimate of our length using Manhattan Distance.

Unlike direct distance, Manhattan distance is just the sum of the distance on each axis. For instance, let's say your friend lived in a house 10 blocks north and 20 blocks west of you. With the Pythagorean Theorem, you could determine the distance "as the crow flies" to be ~17.3 blocks. But for the Manhattan Distance, you can just add the numbers together and get a distance of 30 blocks (the distance you're likely to walk to get there).

This can also work in reverse. Given a final length, we can subtract numbers from it to form a path, then add the segments on each axis together to get the dimensions of the map. It's hard to explain, so let me show you instead. Let's say we wanted to make a path that was 10 tiles in length. There are many ways to do this:

Even without drawing a box around these paths, we can still get their bounds by following them. Take the green one, for instance. It goes 5 units up, 4 to the right, then one more up:

Up 

• 5
• 1

Right

• 4

If we add all of the numbers together, we predictably end up with 10. However, we can also add them in their respective groups to get 6 up and 4 across. Taking the first corner into account, that gives us a 5x6 area for this path.

So why are we doing this?

Let's get back to the spreadsheets. We already have a predetermined length, so we can get either of two things by picking the other:

1. Map dimensions from the number/frequency of turns (as seen above)
2. Ratio of up/down to left/right paths from a ratio of map dimensions.

For now though, we'll put this work aside. We can't make this decision before making some others first.

What is Area 1?

If we want to decide what our new path should look like, it would benefit greatly to know what the area should be like terrain-wise. I already know the answer, and so do you if you read the title of this post. However, I think the process is more useful than the solution.

Because Halberd is as limited as it is right now, a lot of my design decisions are derived from those limits. When I discussed narrative earlier, I brought up the transition from known/safe to the unknown, and used woods and plains as examples. In retrospect, I'm not fond of either solution:

Plains are generally very open and exploratory affairs. This can be great if exploration is the goal, but in a limited game with few mechanics on offer an open field isn't really that interesting. They also tend to be pretty sparse, which isn't a good first impression for a game that will mostly live or die on its environments.

Woods are fairly ideal in general. A forest offers a lot of opportunities for interesting environmental details, and trees are good for creating paths (and hiding little passages for keen eyes to find). However, such a solution won't work too well in Halberd's current state: With no layers in maps, we can't make tiles overlap anything. Not each other, and certainly not the player! As a result, an environment full of trees would be a nightmare scenario.

Clearly, I needed something else. I chose the foothills of a mountain for a few reasons:

• On their own, the foothills of a mountain aren't as imposing or dangerous as the peaks. They also tend to have more greenery which helps lighten the atmosphere a bit.
• Mountains seem to get used a lot as a symbol for a challenge or ordeal. So, starting in some foothills implies that the real danger is up ahead. To me, this fits well with the progression established earlier.
• Mountain trails and the like are pretty restrictive. This presents the opportunity to add more interesting or complex scenery bits (translation: trees) where the player can't possibly reach and/or clip into them. Tile overlaps can be faked if you don't need tons of them, so it works for this situation.

Of course this isn't the only possible option, just the one I've chosen. Now that we know what the map will offer in terms of terrain, we can use this to get a general idea of the map's size. Since we're building a mountain trail, it stands to reason that we want our player to head up. This is especially true since making sloped tiles that work properly isn't yet possible in Halberd. However, most gentle trails have a lot of winding to them. If you look at any local mountains you'll probably see a long and circuitous 'easy trail' and a few more direct 'hard trails'. Since we want the first area to feel pretty non-threatening, I think it makes sense to have a winding path.

Whoops, more math!

Since the two ideas that I just outlined contradict each other, I think I'd like to see a fairly even map ratio. Unfortunately, getting the dimensions and path lengths will be difficult because the path winds back on itself. So, we need some more complicated calculations.

Lets say that we want a path that crosses the width of the map twice, like so:

Let's also assume that we know the path length (since in our real path, we'll know that too). In this case, we'll go with 100. Given that, the target map ratio (1:1) and the number of crosses, how do we determine the size of the map?

Since we have the width-height ratio, we can also determine the horizontal movement to vertical movement ratio by multiplying by the number of crosses. Better still, we can use this number with the total length to get the amount of horizontal/vertical movement and the width/height of the total map!

Let's try with a real example now. I want my 250-tile path to fit a map with a 2:3 ratio. So, I plug that information into this handy spreadsheet I just made:

Just like magic, I now have map dimensions! The 'pad' entries at the bottom represent the map dimensions with enough extra space to prevent the edges from scrolling onscreen. With this, everything is now in place to (finally) begin working on the map!

As a side-note: I think I'm starting to like spreadsheets a little too much. I suppose that's a fine quality for an RPG engine-builder, but still.....

Adventures in GrafX2 Scripting

I'm currently working on a little game project. Since I want a relatively polished result, I have a lot of art assets to make. I'm spending many hours in my editor of choice, GrafX2, and I get the opportunity to see places where my workflow falls short. Sometimes, I want to do something but it's a little annoying because of the tools I use.

If I were nothing but an artist, then that would be the end. I'd either have to grit my teeth or move to another program. However, I'm a programmer and GrafX2 has a scripting API. I think you can see where I'm going with this.

Minor Troubles

There exists a pretty major roadblock for anyone who wants to get into GrafX2 scripting: There's no API documentation (As far as I can tell, at any rate). I spent my first 15 minutes or so trying to use the example scripts as reference, before getting fed up and tracking down the source code. As you can see here, there's one convenient spot in the codebase where you can find the relevant Lua functions. Thanks to my line of work, I'm already very used to reading code in place of docs so this made my work much simpler once I discovered it.

Another thing to be aware of is that GrafX2 always loads scripts when they're called. That means that all you need is an open copy of GrafX2, and you can regularly call your script for testing/debugging as you work. In my case, I set up my code and my editor side-by-side like so:

Click the image for a larger view

With these tools in hand, writing new scripts to improve my workflow is quite easy!

The Scripts

In the spirit of giving, I'm going to discuss the scripts that I've written and share them with the internet at large. All 3 or so GrafX2 users in existence can enjoy my work and rejoice!

If you just want the scripts and don't care about my chattering, click here now.

Animation to Spritesheet

This was my first and arguably most important script. GrafX2 generally exports animations as gifs which I have to go back and edit in GIMP to make them into spritesheets. This process is rather annoying, so I decided to make a script to do it automatically. Once that was done, I figured it might be worth my while to polish and release some scripts. (Technically, I still have to change the color mode to RGB in GIMP, but I plan to add indexed color support to dfgame sooner or later)

This script pretty just copies animation frames to the second page, and arranges them however the user asks. There are probably more options that I could add for more complex layouts, but it should cover most cases.

I recently noticed an issue with this script where it doesn't work occasionally. When that happens, you can probably just run it again and it'll work. The script's logic appears to be correct, so it may just be a GrafX2 bug. It's hard to tell for certain.

Zoom-in-Place

Zoom-in-Place, or ZinP as I like to call it, is a product of how I like to present my work. As you can see in this post, I like to place a zoomed version of my art next to the original. This is also useful for getting critique! Unfortunately, this is a little bit annoying to do manually. I could just take a screenshot, but that method is impossible for animations like this one:

That took about 2-3 seconds to produce, and most of those seconds were spent finding and starting up the script. It's probably even faster than spinning up a gif/video recorder, and unlike a recording this preserves the palette information correctly.

Append Page

Since I was on a roll, I decided to write another script. This 3rd script, Append Page, is pretty simple: It just copies information from the inactive page to the currently active one. Unlike the page copy in GrafX2, this script appends the copied data instead of replacing the original contents. The result leaves the two pages side-by side for easy comparison. Unlike a normal copy and paste, Append Page preserves layer information. As a result, you can easily compare two variations of the same image layer-by-layer without making several manual copies.

Conclusion

I'm aware that these scripts are fairly situational. Indeed, they're absolutely catered to my specific workflow. Honestly though, I think that brings up a really good argument for non-coders to learn just a little bit of scripting:

When you know the basics of scripting, you can take your tools and make them work just right. Maybe there's one little thing that annoys you here and there, or a minor little convenience feature you wish existed. When you know how to script, and your applications support doing so, there's nothing to stop you from solving your own problems and getting that perfect workflow.

Someday, I want to see a world where DIY scripting is regarded as normal enough for everyone to know just a little bit. It's awfully idealistic of me, but I think it'd be a nice thing to see. Programming can be awfully hard work, but just a little bit here and there can produce great results for relatively little trouble.

"Art"

I've wanted to be good at art for a very long time. I spent countless hours trying to teach myself 3D modeling back in highschool, and I originally wanted to make art posts a regular event on this blog when I first started it. Obviously that never happened, but I haven't quite given up on art yet.

During my break in August, I decided to finally try to get good pixel art. Following through on that, I've been practicing almost every day. So far, I've made somewhere in the ballpark of 60 images. I wouldn't call myself competent yet, but I think I've improved enough to make a little "progress showcase".

Enough talking, let's get to the art

I went through my art folder and tried to find similar pieces that

1. I had considered 'done' at the time (no WIP/unfinished pieces)
2. Had a reasonable time difference between them

Then, I put them into groups and made some nice little comparison images:

Trees

 Rocky Walls

Sand

Foliage

Stone Bricks

So yeah, that's what I've been up to for the past 3-4 months. I'm going to keep practicing pixel art, and maybe do little gallery posts like this on once in a while. I'll also try to take my time making art for any future game projects, so hopefully my practice will start paying off once I'm back to game stuff.

Capstone Update 17: Looking Good!

As the beta milestone (the effective 'due date' for the monster) approaches, I've started filling in the remaining gaps that are left over from earlier in development.

One of those gaps is art. I gave the monster a graphical upgrade several weeks ago, but I've gotten plenty of feedback since then. I've also added more abilities to the monster since then, which require more animations.

The two biggest complaints about the monster were that it wasn't very scary, and that it was still hard to tell when the player was taking damage. The designers haven't had a chance to play with the monster's stats yet, but I still found it odd that my damage feedback wasn't doing enough. One thing that we'd been wanting to do for a while is make it more apparent that the monster was nearby, so I added a noise effect that grows as you get closer to it. In addition, I made the damage effect on the player smoother and slightly reduced the monster's damage. This seems to have greatly improved player reactions to getting hurt.

One of our designers added a nice cinematic introducing the monster, where it leaps down to attack you but is driven away by a flickering ceiling light. We think it's really nice, and much scarier than normal interactions with the monster. Part of this is because the player can fight back, but we've also identified a few other things that could use improvement. First off, the monster is almost always seen from a high angle. In other words, it looks harmless because the player towers over it. Just making the monster taller than the player has added to the monster's scare factor by a decent bit. I also pumped up the alpha and particle count to try and make the monster look a little bit more solid than before.


The last thing to add, which I addressed last weekend, is animation. There were  two main situations where the monster needed animations: Blinking, and slipping under doors. Blinking especially needed an animation, because the player needed a warning that the monster was about to appear. I spent a long time considering how to make the blink look. The blink is probably the most 'outlandish' thing that the monster is capable of, so I wasn't really sure how to make it work visually. Most of the monster's abilities are closely tied to the fact that it's more of a cloud than a solid object, but teleportation doesn't really fit as obviously.  Ultimately, I decided to interpret the blink as the monster slipping into a crack and popping out elsewhere, which I've represented with the monster's particles compressing and flying into the ground, while a second animation has them pop out and expand at its destination. It may not be perfect, but I think it fits nicely nevertheless.

The slipping animation was much easier. I scaled down the monster's particles, then made them stationary and emitted them using a flat disk. The result is a mostly-flat shadow creeping around. I'm pretty happy with the result, and also a little sad because I think a bigger, more elaborate version of it might've made for a creepier design overall. My original idea was for the shadow to be a vague squid-like silhouette that scurried around the floor and walls, and I still kinda regret not giving it a shot.

Capstone Update 7: A Few Grains of Salt in an Overwise Perfectly Decent Milkshake

I have not discussed it on this blog, but I have been responsible for the vast majority of this game's art and art direction. So far, I've produced all of the art documentation for both Sports Game and Dungeon Restocker, including the artist statements and art bible, the the latter of which contains all of the guidelines and details of the art style the game will be taking. Because our team had no artist, I've stepped up to fulfill all of the project's art needs.

It is for this very reason that I feel a little bummed out right now. In what feels like just overnight, I have been rather casually swatted out of my position as artist in favor of my designer. I don't blame anyone for this, nor do I think this was particularly intentional. However, I still can't help but feel a bit used, after defining the game's art style. It's a weird situation all around.

I should stress again that I'm not placing blame or trying to stir up any issues. I know full well why this happened, and it makes sense. Now that Mike has gone and finished the major design work for the moment, he sees an opportunity to keep being useful while also increasing the amount of work being done to implement his design. In that sense, it's a perfectly logical move. It's also not the first time this has happened. I made a similar switch last year as well. The reason I felt better then, though, is that the designer in question was a talented artist with a charming and distinct style, whereas my designer honestly doesn't seem much better or worse than I am.

What am I going to do about it?

Absolutely nothing.
I'm going to go back to programming, and work more on implementing the game's core systems. I have other projects that I can do art for, and I have no intention of creating any unnecessary drama over a move like this. Whoever does our art now is probably getting replaced if/when we go forward to next semester anyway, so I'd be out soon either way.

It's still a little bit sad, though.

AMAZE - 26 - Done!

Changelog:

• Finished the last 2 levels.
• Finished the music for the Title Screen and Zone 2.
• Added two difficulties: Casual and Challenge.
• When loading a new game, the correct music should now play.
• Changing the volume will now have an immediate effect.
• Added some bonus pickups to almost every stage.

Here's the total completion of the remaining parts of AMAZE:

• Levels: 30/30: 100%
• Tilesets: 6/6: 100%
• Music: 7/7: 100%
• Total: 100%

So, that's it! The game is finished!

I'm glad to be done two weeks ahead of schedule, though feels rather odd. Normally, I'm several months(or more) off! Anyways, this will give me a couple of weeks to run tests on the game, and maybe tweak things a bit.

Unlike most of my projects, I will also be publicly releasing the source code at launch. You'll probably be seeing me do this much more often from now on. I think it's time to start giving back to the open source community. In fact, I will(hopefully) have the next versions of AMAZE be open source from the start, letting people see my progress much more closely and even contributing if they wish!

If you read my last post, you might notice above that there's no mention of a Hardcore mode. That's because I've decided to change how the difficulties work. Challenge is the same as Hardcore was supposed to be-exactly as the game was up until now. Casual has been changed a bit. Instead of adding checkpoints, I've decided to start Casual games with the maximum number of lives. I decided to change this mainly because of scope issues. Implementing checkpoints alone would be a pain, but then placing and testing them for every level in the game would be a nightmare. It's a feature that I really want to add, but that I should have started long ago for there to be any chance of it getting in. Anyways, if Casual is too easy, or Challenge too difficult, you can change the setting at any time. Note that you only get the extra lives if you start on Casual, and switching to Challenge will not remove them.

Finally, I'm going to take a short break next week, and I'll be back once AMAZE is released. I want to make some changes to this site, which will hopefully make it a bit nicer. If I'm fast enough, I might even manage to launch those changes with the release of the game!

For now though, goodbye!

AMAZE - 25 - So Close...

Changelog:

• Finished the Final Zone tileset.
• Finished the music for the Tutorial, Zone 1, Zone 3, and the Final Zone.
• Life pickups now permanently increase your max life count, but only if you grab them on your first run of the level. Afterwards, they're just a bonus.
• Finished 2 more levels of the Final Zone.
• Added an end to the game.

Here's the total completion of the remaining parts of AMAZE:

• Levels: 28/30: 93.3% 
• Tilesets: 6/6: 100% 
• Music: 5/8: 62.5% 
• Total: 88.6% 

At my current rate, it looks like I might be finishing next week! After I get the rest of the music and levels, I'm going to take the time to add several difficulty levels. I decided to do this, mainly because of the final levels. Right now, even I have some difficulty getting through the last few levels and I've been playing this game longer than anyone else!  I will be making three difficulty levels:

1. Casual Mode - You'll get an extra hit before death, and you respawn at checkpoints throughout levels.
2. Challenge Mode - You respawn at checkpoints throughout levels.
3. Hardcore Mode - No checkpoints, just as the game is now.

To do this, I'll need to put in checkpoints. These should be pretty easy, just setting where to stick the player when killed. Progress and items will be kept when  respawning like this, but the restart button will still reset everything.

I think this will make the game a bit less punishing for players, especially when they're just playing for the first time.

I've also started screwing around with a new project, but I'll save those posts for after AMAZE is finished.

AMAZE - 23 - Not Much Coding Here...

Changelog:

• Finished all but one level in Zone 4 (The last is ~50% done).
• Fixed some issues with bombs.
• Remade the sprites for: Fireballs, Drills, Bombs, and Explosions.
• Made the tileset for Zone 4.
• Started the tileset for Zone 3.
• Made bombs beep before exploding.

Now that 7drl is over, it's time to get back to work. 

I spent the entire week worried that I was getting nothing done, only to realize today that I'd actually done a fair bit. That makes me rather happy. Seems I haven't lost my touch after all!

Unfortunately, since the game is so close to completion, I've been hardly touching the code at all. I haven't yet decided what to do with the second half of these update posts in the meantime, but hopefully I'll figure something out by next week.

Sprites: AMAZE rework, part 1

As I mentioned a while back, I'll occasionally post new sprites I've been making in Sundays. I've got a few today from AMAZE.

After the recent jam ended, I decided to try and update some of AMAZE's graphics. So far, the game's graphics have been almost entirely composed of placeholders, and they look really terrible. Along with that, I've been meaning to try and improve my pixel art skills recently.

Here's what I've done so far:

First, I tried to make the generic looking 'diamonds' into some kind of cool blue crystal. It looks pretty, but I probably won't keep this. It doesn't really feel like what I was trying to go for.

The next sprite I went for was the awful giant coin. I tried to turn it into a few modest stacks of gold coins, and I think I succeeded very well here. This sprite is probably a keeper, although I may alter it a bit in the future.

Lastly, I started work on the tileset. Ignore the right half-it's just old stuff. So far, I've only redone the floor texture. It looks much better than before, but I'm still not too happy with it for some reason. For now, I'm gonna stick with it, though.






That's all I've got so far. I think I've made some decent progress in terms of art, but I still have quite a ways to go. Hopefully I'll iron out those pixel art skills with the next few projects. In the meantime, AMAZE is still progressing nicely and I should have plenty to write about on Friday.

Update: Building things to build things

The week's over once more, and this time I plan to capitalize on my freedom. The plan is to work on a good, well structured map editor for future games. There are a few things to do:

1. I need a list of features to implement. To be honest, I'll probably start with Halberd's feature list and work from there.
2. I need to create a tilemap format. I could use an existing format, but that would limit me greatly. Making my own lets me pick and choose what things to store, and how.
3. I need to structure it well. If I do a poor job now, It'll come back to haunt me later. Check out my projects page, and see how often I end up refactoring my code. That's something I want to avoid.
4. I need to actually do it! Talk will get me nowhere. That's why I chose to do it now, rather than later.

You might also wonder why I need to make a map editor when I have so many other projects. To continue working on AMAZE, I need levels. My best bet is to write the editor first, and then some loading code. That way I only have to write code once.

While I'm at it, let me post some sprite work for this month:

One of my friends was just grabbing sprites off the web for his Game Tech projects, so I offered to draw him an enemy. It didn't quite turn out how I wanted, but he seems to like it. Also, you may notice that I've begun using some mild dithering in my sprites. I'm not very good at it yet, but I like the look.

Short update

This is pretty late, but I have a few sprites from my last Game Tech Project. Overall, I think they turned out well. The one on the far right is a bit lackluster, though.

My next project is a bit more challenging than the others, so I can't say when I'll be able to get back to my own stuff. I DID spend some time on Textyventure recently, though. Lastly, I'd like to put up a page detailing current projects. I'll try to do that today.

Delete.....Everything.

You know how I said movement would be next? Scratch that for now.

I may have accidentally broken my computer's window borders, menu bar, etc. a couple of days back. Fortunately, I backed up all of my files and wiped my computer. I can work again. Unfortunately, I've now lost several more days of productivity in an already unproductive vacation. Now, that said, I have gotten a bit of work on Chainsaw Deathrace done. I've been writing a new method of drawing autotiles that's better suited to my engine. This allows for walls, corners AND full sized tiles(to a degree). Also, it makes for smaller tilesets. I'll write up a proper post about that later. Another thing that has come from my little wipe is that I now keep Windows in a virtual machine, rather than dual-booting. This means that I may have trouble testing/releasing Windows builds, until I get the hang of it.
I still have a few things left to set up, but I have my code back. I'm reinstalling my libraries right now.

1k

Google Analytics tells me that this blog has somehow reached 1000 pageviews. I'm under the impression that most of these are just web crawlers/bots, but a milestone's a milestone, right? Besides that, I mostly use this as an excuse to stay on track and see my projects to completion. Seriously though-if any of you invisible viewers ARE real, why not leave a comment once in a while? It livens things up.
Now that that's out of the way, have a celebratory .gif and announcement:

Another week, another jam

This may not have been too obvious, but I mentioned wanting try the 0 Hour Game Jam some time ago. Well, the day was today(at 2 am). I would call it a success of sorts. (You can play it here, the name is Zombie Delinquent Shootout)

Here's how it went:

 

What went right:

• The concept
• I came up with something simple right before the jam began. This was very helpful, as I knew exactly what had to be done.
• The engine
• My engine worked quite well! I've really come a long way from when I was using love. 
• The graphics
• I drew them quickly, but they didn't turn out as poorly as I had expected. still not great, but whatever.
• The new scaling algorithm
• I rewrote the code for scaling images literally just minutes before the jam started. Sprites now scale from an origin point(default center) rather than the top-left hand corner. Having said that, it's not perfect. I'll need to play with it a bit more.

What went wrong:

• The graphics
• As nice(ish) as they were, I spent far too long on them. It made the coding more rushed than it had to be.
• The RNG
• It would either always show your cat, or never show your cat. There was no middle ground. I opted for never in the end.
• Porting
• There is no Windows version. I considered compiling the game not to be a part of the jam, so I did it afterwards. After 30 minutes of fighting the compiler, and only getting a white screen, I gave up. I may revisit this, but not right now.
• I ran out of time
• I still made a game, but 10 minutes more would've really helped.

Oh, yes! Here's a screenshot full of Zombie Delinquents! Yes, their arms are guns. No, they cannot fire them. I didn't code that in time. :(

Sketchpad #1: Trees

This is mostly trees, with a plank and a cactus thrown in for variety. I meant to post this yesterday but was too tired to do so.

Let's Play a Drawing Game!

    Last weekend, I thought of a little game for two to try out some time. The game is based around drawing pictures, preferably with a tablet so that you can easily compile the images together on the computer. I've been tentatively calling the game 'Pics or it didn't happen.' Here are the rules:

1. Player 1 tells Player 2 about something that happened to them, or something they found out. This thing must be only one sentence long, and it should be wild, fictitious, and rather absurd.
2. Player 2 must now draw the picture, and then follow step 1. However, the sentence Player 2 chooses must be related to the last.
3. Everyone wins. (Or no one, depending on the contents of the pictures. You decide.)

    This game can be adapted for 3 or more people, where each person must draw. The drawing that Player  1 decides is best gives its artist a point, as well as the opportunity to come up with the next sentence. The winner is the first to reach a set amount of points.

I encourage anyone who reads this to try it out, and tell me the results. I'm going to try it with some friends, so I might put up the result eventually.