Monday, October 19, 2015

Airgrift Devlog #2: Gooey!


Here's another devlog video for Airgrift! In this one, I talk a bit about some new GUI stuff, some new enemies, a new camera system, and s'more stuff! Making games is fun, but it can be hard work too, haha.

Here's a bit of a write-up that's also in the video description:

I've been working on Airgrift for a little while now, and I've implemented and added quite a bit to the game and engine it's working with (BDX). So hurray!

I've added some GUI elements - mainly the Cash counter, the portrait and name in the top-left corner, and the camera icon in the bottom-right. These elements still need to be positioned to work more in the favor of the gameplay and to be streamlined, but overall, they look nice and work well.

I've added downsampling for a smoother, more efficient bloom filter (hopefully, anyway), and a couple of enemies, as well. The enemies aren't finished as of yet, but the core ideas are definitely there and working. The Discharge slowly follows the player and fires electricity straight downwards. The strikes are periodic, but they hurt when they hit!

I also wrote that music in the background. It's not really for any project in particular, but it might work well for this game. I have, however, written some other music for Airgrift that sounds really awesome, I think, so that's something to look forward to implementing.

Thanks for watching!~

Monday, September 7, 2015

Airgrifting All Over The World

Hey, there! So today, I managed to get some more done with Airgrift.

I finished the first few sprites for the first enemy, known as the Grinder. The idea is to make something simple, slow, and predictable, but also dangerous in tight corners or when you don't have room to breathe, like the ghosts from Pac-man. I think I want this to be a one-hit-kill kind of enemy, but I also think that it should be a beginner's enemy, so it can't be too hard. Perhaps a happy medium is that it will literally grind your health down gradually. So staying at high speed, boosting away, or whatever else you can do to help get away would be a fine strategy and makes them easy to avoid.. This is all tentative, of course. And yeah, I know the sprite's not perfect when it comes to perspective. Gotta pick your battles.

Anyway, I also put particle systems in when you bounce off of walls, which adds a bit of (needed) polish, I think. Not sure if I'm going to keep the "Ow.", since that might make people think they're taking damage. Maybe I'll save those particles for when the player character actually gets damaged.

The particle system itself is one of my own design. I started it months ago, and operates a bit similarly to an old particle system I wrote that was known as the X-Emitter from when I was using the BGE. The new particle system is in component form, and is just known as Emitter and Particle in my BDXHelper package. Here's some example code that sets up the emitter to work:

partEmitter = new Emitter(g); partEmitter.addTemplate("SmallParticleCross"); partEmitter.addTemplate("SmallParticleCross"); partEmitter.addTemplate("HitVoice"); partEmitter.spawnTime(0); partEmitter.friction = 0.025f; partEmitter.startingVelocity.z = 2; partEmitter.randomVelocity.x = 2; partEmitter.randomVelocity.y = 2; partEmitter.colorStages.add(new Vector4f(1, 1, 1, 1)); partEmitter.colorStages.add(new Vector4f(1, 1, 1, 1)); partEmitter.colorStages.add(new Vector4f(1, 1, 1, 0)); g.components.add(partEmitter);

As you can see, the process is all rather simple, as I'm just creating a new Emitter and then customizing it to fit my needs. Pretty simple and easy to manage - even easier would be a GUI. Maybe I'll manage that later.

Anyway, in the above example, I add a template (the GameObject to spawn that represents the particle), I set up different properties like friction and velocity, and then add color stages. Color stages are basically "keyframes" of color; it starts off white, and then turns invisible.

The two "white color" vectors basically means that it stays opaque for half the particles' lives, and then fades out over the second half, rather than fading over an entire second (like it would if one of those 1,1,1,1 Vectors weren't there). Anyway, it's rather simple to use, which is fun. If you want to actually catch the code that makes the particles work, it should be up to date over here.

In any case, here's a devlog video to show the game as it stood a couple of weeks ago (gasp!).

So what else have I been really doing for the past couple of weeks? Mainly, replays.

I think I've finally gotten input-based replays working and finished for the game engine I'm working with. It's been a pain because we weren't sure the physics engine was entirely deterministic as the replays were playing out completely differently when we'd run them - sometimes it would run correctly, other times kinda close, and other times it would be horribly wrong. However, it seems like the physics are deterministic to a point (at least, the way we're running it). I think it's just a matter of where and in what state the game objects are that influences the replay's process. When I'd play the replays, the game objects weren't in the exact same positions, and I didn't start the replays on the same frames in game time as the recording started on, which means that it boils down to a different situation, even if it looks the exact same.

Anyway, I think I've sorted it out, and if so, then it'll be merged into trunk, which is cool. Attract Modes for everybody! The code's here, in case anybody wants to take a peek.

Anyway, that's about it. Thanks for reading!

Saturday, August 8, 2015

End of Shakecan Games - Start of A New Project

Hey, there. It's been awhile.


I really should stop writing that at the start of my posts.

In any case, I haven't been doing much game development recently, as I got a full-time job, which has been taking up a lot of my time, in addition to my other rather important pursuits.

Wednesday, June 3, 2015

No Man's Sky Mixtape Game Jam

Yo! It's been awhile since my last post, and I thought I'd post a bit about what I'm working on now.

Friday, April 3, 2015

The Next Game

Yo! It's been awhile since my last post; sorry about that! I've decided to pause development on that murder mystery game I started, as my writing skills just aren't up to snuff. Hopefully I'll be ready to re-tackle that next time.

For now, I wanted to try something with more solid, pure gameplay. This game will have a focus on exploration and combat, and hopefully be a smooth, slick Metroid-like game.

Anyway, today I worked on the starting area, which is a blank "space between dimensions". Basically, the game takes place in a big jumbled up maze that can pull things and environments from all through Earth's time and space (which means a lot of rooms, but that can be outside, inside, on fire, snowing, etc.) I suppose it'll mainly just be for variety over actual game mechanics; there's a lot I could do with the idea, but I probably won't get around to really having top-notch level design, haha.

I got movement and jumping working OK. Stair-climbing also works pretty well. The idea of this game is to be a Metroid-like with smooth movement, where the game doesn't really get in your way as you traverse and explore the environment. Not sure if I'll be able to pull it off, but it's worth a shot, I think.

I have to work on the GUI some more, but it's OK for now. I'll have to keep iterating it over and over to get something that I'm satisfied with, but I think I have a good core idea for how it should look and work.

Anyway, I'll have to get to work!

Saturday, February 21, 2015

Visual Improvements


So I've made some progress over the past few days.

The game is going to be built on a series of if-statements. I'm going to directly wire the gameplay of what happens directly to the save game data flags, which is a hashmap (dictionary) of strings (flag names) to strings (values). So, for example, your inventory starts off as a blank string (""), and adding something to it is just adding whatever the object's name is to the save data's "inventory" key ("pieceofchalk"). When I want to save, I just need to save each flag and its corresponding value out to a file. It's trivial for a player to cheat and change the game, but I don't really mind about that; this game is being made over a couple of weeks, after all!

Anyway, I haven't been doing too much with the actual game development, as some things have come up that could be good for me that I'm working on. Most of the game is writing, though, so just thinking about it is making progress. I've been drawing different scenes and characters as well; the top-right scene isn't finished.

The characters have gotten a bump from 64x64 to 96x96 in their sprite sheet size, and I'm using perspective grids to draw the scenes, rather than going freehand. They're really, really useful to map out and plan the shape of a room. I'd be having a lot more trouble without it, for sure.

Anyway, thanks for watching. Hope the game'll be fun to play!

Saturday, February 14, 2015

Shakecan Game #3 - FamiDet (tentative name)

Hey, there.

So the next game that I'm working on is going to be a Famicom Detective-like game, where you have to solve a murder that takes place in a school (so far, that's the plan). The "codename" for the game is "Famidet" for that reason; I'll probably change it soon once I get an idea of the plot. The idea at this point is that you're a teacher at the school, but that definitely doesn't make a lot of sense. Then again, it doesn't really have to, haha. It just has to be fun and engaging.

As usual (kinda), I'm making this game with Java in the pre-alpha LibGDX-based game engine, BDX. It's going okay so far; I've got a couple of the commands working. You can talk with the person about different topics that they know about, and I built it to be easy to change that depending on the state of the game. This should allow you to learn more about the crime at hand, gradually growing in understanding what the situation is by talking to different people and taking what you learn to others still.

Speaking of flags, the game state (what you've done) is comprised almost entirely of string pairs; one for the flag name, and one for the flag state (i.e. "talkedToGymTeacher", "true"). This should mean that it was trivial to set up saving game data (just save the name of the flag and the value to a text file), and it should be easy to handle the game state as well (no need to transfer save data to the game and back; the save data is the game data, in a sense). This would make it easy to edit the save data to cheat at the game, but this is a game made in a couple of weeks - I've gotta cut myself a little slack, at least, haha.

Much like the Ace Attorney games, I've built the underlying framework in such a way that the character you're talking to can emote heavily depending on what they're saying. Rather than simply setting dialog, each character has a behavior list that they step through when talked to, which means that they should be able to support a lot of different actions (saying something, setting their emotion, spawning an object or flashing the screen, disappearing, slowing down the message speed, etc). This'll make it a lot more interesting to talk to the characters, hopefully.

Above is an example character "idling" and talking in both normal and sad states.

The "Think" command will be used to process what you learn and continue the plot, if you reach a point where you have gathered all available information. At least, that's what I think it'd be used for. You can also use it to be reminded of what, in general, you should do next. I might trim this feature down (or even cut it out) in the future depending on if I want to press on with it or not - limited time, and all that.

This indeed is looking to be quite the challenge; I'll see if I can succeed in just another week or two!

Anyway, thanks for watching and reading!