Revamped Games Page

Last week, I discreetly pushed a new update to my website. I've completely redone the games page, improving the look and adding a few titles that weren't there before along the way.

I started work on a new site last year, but got too bogged down with Capstone to finish. Then, I got a job almost immediately after graduation (In fact, I'm starting soon. I'll make a quick post about it once that happens.). As a result, I haven't really had a time where I felt that improving my site and building a proper portfolio was really necessary, and the site has remained half-finished. Hopefully, I'll be fixing that problem in the coming weeks.

I decided to start with the games page for a few reasons. The biggest reason was that it was a horrible, disgusting mess of boxes, but I also felt that the games page was one of the most important parts of the site. While I make software and do other things, I am primarily seen by my peers as a game developer. Furthermore, the vast majority of the work that I've shared is game-related in some form.

So, what's new?

• I've moved from the previous design (boxes with a small icon and some text/links) to a cleaner, more responsive design with tiles representing each game.
•  Game information is now hidden; clicking a tile brings up  a popup with a description and links.
• I've fixed the previously scrunched-up icons.
• I've added controls to most game detail popups.
• I've greatly fleshed-out each description. I would highly recommend reading through them all, as I've added some fun never-shared-before tidbits.
• I've added The Last Light, Core Breaker, Cloudy Climb, and Growgue to the page.

That list of changes kept me busy for about a week, but the result was well worth it. I recommend taking a look at the new page here.

Space Douchebag! - 2 - The Story Thus Far

First off, apologies for not posting this earlier. I meant to post this last weekend, but then I guess it slipped my mind. Anyway, I'm going to use this post to talk briefly about what I've done on Space Douchebag! so far.

1. Week 1/2: Our beloved hero, the mighty douchebag. 
1. First off, I came up this weird concept. I wanted to do something simple, like a shooter, but I didn't know what to do for a story. I then realized that most of my shooters are just a dude who shoots everyone ever-regardless of anything. Figured that was rather douchey, and the concept was born.
2. One of the main game mechanics came from laziness. I wanted to make collision simple, so I stuck a circular collision area on the cockpit. I then realized that I could put it in the story. His ego is so big, that his invincible ship can no longer hold it and it physically manifests itself. Unfortunately, his ego will shrink when shot, and we don't want that. Thus, I got a cool concept: a hitbox that shrinks as you take damage.
3. Shooting was next. I wanted to do something different, and this ended up manifesting itself in an aiming mechanic. As you move up or down, your ship turns, moving both your ego and making you fire in a different direction. this has led to several cool maneuvers, like rapidly tapping up and down to spray bullets.
2. Week 3: Boring menu week.
1. Last week was a little on the boring side. We needed to make a menu system, along with a few other things. In the end, I chose a cool pane based layout for the menus. It looks terrible right now due to time constraints, but it'll look much nicer soon enough.
2. I also came up with a new concept: Fanmail. Space Douchebag has many large hordes of fangirls who love him for his huge...ship, and they send him intergalactic fanmail. He can only hold so much, but reading it is a huge ego boost. That's how I'll handle health pickups, methinks.
3. Finally, I made the player's shots grow ever so slightly as they move. It's a subtle, but nice effect.
3. Week 4: The next step.
1. Week 4 will be next week, but I've got my assignment already. It looks like it's all about depth effects, so the game may get some nice new graphical sheen. It is a graphics class, after all.
2. I'll also try to add a basic form of enemy.

So there we have it. Next week will definitely have pictures, and I may post about the art style and such sometime. The nice thing about this project is that results will be much more visually obvious, so there's that. It's all Xna, though, so it's probably going to stay Windows only. 

Amaze - 7 - Meet the Protagonist

Now that the base framework is finished, I'm itching to make some actual game content. However, this week I'll resist that urge in order to make this project run smoother in the long run. Besides, we haven't had a design post in a very long time.

To start things off, I decided to make a list of things that the player should be able to do in AMAZE. Here it is:

Move - This is probably the most obvious one. In a game about getting your character to the exit, it'd be difficult to make a game where they can't even move in the first place!

Push - Pushing things around is the kind of mechanic that can get a lot of use. It lets you open paths, close others off, hold down switches, complete circuits and more. There are entire games built solely around the mechanic of pushing things.

Collect - Like in AMAZE's original iteration, I'd like to have various things that can be picked up, be it as a part of a puzzle or a bonus. Pickups, especially in the form of bonuses are certainly another staple of the genre. I'm not really trying to break new ground with AMAZE, so I have every reason to rely on a few simple, standard, common mechanics.

Activate - This is a more complicated and nebulous action than the rest. I'd like to have various things, probably machines/control panels that can be interacted with in general. These would do all sorts of things, like moving stuff around, opening and closing doors, or otherwise changing the layout of the level. This lets me make some wildcard type objects, which can do unique things when necessary.

Dig - I don't think this action will be available by default, but I think the player should be able to dig through certain weak walls. Either I'll add this as a mechanic later on, or it'll show up as a powerup of some sort.

Bomb - Of course, one cannot just dig through everything. tougher walls will require the use of explosives to break. These items will be usable only once, so you'll need to grab several to blast through thicker barriers. They may also destroy other things, like some hazards.

Unlock - Another straightforward one here. Doors and keys are good for making multistage puzzles, where you need to solve each section before moving on.

3 Others - I wanted to prevent myself from bloating the project by adding new things partway through. I've therefore marked this list as final, while still intentionally leaving 3 spaces blank. This will let me add new features, but force me to choose them carefully and set limits.

Now that I've nailed down most of the main character's abilities, let's talk about what they're like.

Above are the four player sprites that I've gone through so far. The one on the far left is the original player sprite that I've been using from the beginning. When I decided to make a player sprite for this version, I felt that the original looked just a bit too small and bubbly, so I started messing around with the bigger, blockier designs in the center. I thought those would turn out even worse, so I scrapped them. Finally, on the right, I came up with a new design. Instead of some huge machine with a guy inside, I made a funny-looking robot. I also changed the view so that this little guy was being seen more from the top, and gave him a face. His sprite is obviously not done, but I like the little guy. I'm keeping him.



In my last post I promised pictures, so I guess I should add another. Here's a screenshot of how Singularity v1.5.4 looks(I've made a number of minor updates since 1.5):

Click to enlarge

As you can see, it still looks pretty terrible. Hopefully I'll be fixing that(and finally actually releasing it) in v2.0, coming either late this year or early next year. Eithr way, it's still going to be while before I get back to it.

AMAZE - 2 - Data

Recently, it's been pretty slow going working on AMAZE. Currently, the two biggest obstacles are collision detection and asset handling. I'll cover collisions in a later post, as it's a bit lower on my to-do list. In the past, I dealt with assets in a very simplistic way. I'd toss a bunch of PNGs, WAVs, and OGGs into a folder, then call it a day. I'll be the first to admit that it's not a very professional solution. From now on, I'll be using custom data types for assets, with various extensions. The first of these is SPA, for SPrite Asset. In the past, I'd make a PNG file with each frame next to each other. Surprisingly, it was quite a pain to make these, and that's why I use so little animation in my games. I'm writing a simple conversion program right now that'll convert a bunch of PNG files into a single SPA file, along with some simple pieces of data, like the sprite's origin point, and some options for making collision masks(I'll cover those in greater detail later). Right now, I'm writing the code that parses the PNG files, and it's rather boring. that's the main reason why I'm taking so long. Once that's done, it'll be easy to add sprites to my engine, and then I can tackle the problem of collision detection.

Chainsaw Deathrace Design #3: Speak up!

Wow! My last few posts were kinda depressing. Let's brighten things up with a two post day: Design post now, status update later. Enjoy!

So, this also has nothing to do with speed. That's because I'm currently rethinking how I want to handle that. Let's instead talk about a new feature that I want to implement: Sound.

In version 1, getting Billy/Sammy close enough to the Chainsaw Killer would  bring up the message: "[name] hears a chainsaw revving!" This worked alright due to the lack of sound in the game. To tell you the truth, prior to my second Sprint project, I didn't have any sort of audio system in place. I do now. However, that's a little unrelated. I want sound, ingame or not, to be a gameplay mechanic of its own. Here's how it works:

Let's say Billy falls down some stairs. That would be fairly loud. If an enemy was close enough, they might hear Billy fall and know where he is, even if he can't be seen. However, let's also say the Chainsaw Killer is chasing him. Now, the chainsaw could possibly drown out most other sounds. The enemy would not be alerted. This works for the player too. If they hear something, like a chainsaw, they'll also be told what direction it came from. Be forewarned: If the sound is too faint, the direction may not be accurate! Depending on the sound's "strength," the direction may be offset. Also, keep in mind that the chainsaw you hear is just a chainsaw, not necessarily the killer himself.....

How do I plan to add this to the game? Things will create a sound, with a position and strength. Depending on the strength, it will reach everything with ears within a certain range. Then, on something's turn, it compares all that it "hears." Currently, it works like this:  take the strongest sound's strength, and halve it. Everything with less strength cannot be heard. Everything else loses half of the minimum strength. Then, the directions are determined by strength. Let me bring you a visual example:

Let's pretend that the Killer's sound reaches ??? with a strength of 400, and Billy's sound is 155.

1. 400 is highest, so we halve it to get 200.
2. Since Billy's sound, 155 is less than 200, it is drowned out.
3. ??? hears the Killer quite clearly, but that's it.

But what if Billy's sound was 255?

1. Same as before
2. Billy's sound is now higher than 200, so it stays.
3. We take half of 200, 100, then subtract that from Billy's sound.
4. ??? hears the killer's chainsaw with a strength of 400, and Billy's trip down the stairs with strength 155. It now knows where Billy is, and probably goes in to attack. Billy crawls off to the left.

I hope this post wasn't too confusing. The next design post will probably be what I wanted to write about before. Later today, I'll be posting a quick update on what I've actually gotten done.

Chainsaw Deathrace Design #2: The Grid

This is my second post on the design of the new version of Chainsaw Deathrace that I'm working on. This one will be about the grid and the placement of various objects. The previous one was about the characters. Read it here.

If you've played my game at this point, you might ask "What's wrong with the grid now???" The answer is, of course, nothing. The grid isn't what I'm worried about. Walls, on the other hand, are a gigantic pain in the rear to deal with.(You may want to skip this next paragraph, which is a gigantic rant about walls)

Chainsaw Deathrace Design #1: The Characters

Now that I'm back to regular development, I'm planning on writing several posts about designing the next version of Chainsaw Deathrace. Obviously, since the original version was the quick and dirty product of a game jam, the whole thing needs to be remade. However, beyond the code, thought must be put to the design to make sure it's well balanced and fun. During the jam it was about quantity; now it's about quality. Now that that's been said, on to the first topic: the characters.

The original concept behind the characters in Chainsaw Deathrace came from the jam's theme: "Disadvantage." After all, what's a bigger disadvantage than missing limbs? Unfortunately, I didn;t spend much time on balancing. In the end we had:

• Billy, who was slow. Anyone who ran into the Chainsaw Killer was dead anyway, so he had no real downside.
• Sammy, who could only carry one item at a time. Occasionally this turned into an issue, but blood bags could be used immediately anyway, and there was no "health" cap, making his disadvantage nothing more than a minor annoyance.
• Fred, who couldn't see, couldn't use blood bags, didn't know what any items were, and couldn't know when the Chainsaw Killer was near. Also, he had far less health than everyone else. This was an enormous disadvantage.

In this remake/next version, I'd like to rebalance this. In the end, I'd like to see each disadvantage bring some sort of unique unforeseen advantage as well. On harder difficulties, these would be more pronounced, leading to a more careful and strategic game. At the moment, here's what I'm looking at as a more balanced way of doing things:

• Billy who can't run. I'm adding a running mechanic to allow you to escape traps/the Chainsaw Killer. However, Billy won't be able to do so. His advantage is his(lack of) height: As I plan to add combat mechanics of some sort, Billy will be harder to hit, and may have some other combat-related perks.
• Sammy, who(again) can only carry one item. This is similar to the first version, but he'll also have trouble climbing, if he can at all. As an advantage, he'll be faster at running and capable of breaking down doors easier.
• Fred, who can't hear, can't really see, and dies quickly. However, he will have a sort of "Instinct" from what little brain is left. This means he can sense things, even through walls. Also, his random lashings out may grant him some advantages in combat. Also, I have another idea for him. Suppose he couldn't use most items correctly, but they had some alternate purpose only he could find? For instance, blood bags could change from healing to bait, leading enemies to a certain place while he went elsewhere. I'm still toying with that.

Obviously, none of this is final. I'm going to spend a long time testing their traits to make sure that none of them are too hard or easy. This does give me a nice guideline to go with, though. That ought to be a big help moving forward.

Next post: Walls, Floors, and Ceilings!


Also, I should mention this quickly: The album for my last game, A Wheelie Good Time, can be found here. 
I plan on posting more images as I go into Chainsaw Deathrace's album here.