SolarLune's Devblog

Start of a new project - I know who I am

2019-05-05T19:37:00.002-07:00

Well, it's been awhile. Yo!

This is an adventure game I've been working on for the past few months, since around the turn of the year. The name is "I know who I am". It's about being an alien and assuming the identity of a human who doesn't want to exist anymore.

Here's some devlog vids:

The game's being made in Golang with Raylib-go; SunVox is what I'm using for sound and music. The game is actually composed entirely of resources external to the core "engine", which I'm making as well. I didn't intend to do this, but now I have the game as well as a core engine for character-based adventure games. I think I'm going to end up selling the game and open-sourcing the engine to allow others to make games with it, as well.

Later!

Discussion: The Importance of Sequels

2017-10-30T11:24:00.001-07:00

Hello! It's been awhile since my last post here, and I thought I'd update the ol' blog with a bit of an opinion piece on the importance of sequels for game developers. Click past the break to check it out!

Sequels and You

To start with, let me ask you: who is this character?

A certain Blue Bomber.

You probably already know the answer - it's the main character from the popular action platformer, Megaman.

Now the question is, why do you know who this is? While the quality of Megaman games is generally high, and Megaman himself does have a great, iconic design, I believe that a large portion of his popularity is due to his frequency. Megaman has appeared in 10 different games in his original series, has landed on quite a few game systems, and has spawned many different spin-offs that span a variety of game genres. Megaman - all of the different Megamans (... Megamen?) - tend to be very fondly remembered.

So, I believe that if we follow Capcom's lead with regards to Megaman (and many of their other popular series), the key to popularity is:

1) Make something good.
2) Get the word out.

Why Should You Care?

Now, why should you care? Well, if you're a game developer, you probably want your game to be popular and well-loved, right? So, let's see how we can apply these points with a modern game.

Let's say you're making something - an action RPG, perhaps. You spend many months on the game, and finally finish it. You put it out there, and it makes a couple of bucks. Nice!

Now that you've gotten the game out of the door, though, you've gotten sick of working on it (naturally), so you've decided to move on to something else. You can do that, of course, but you might consider making a sequel to your RPG sometime in the near future, and sooner rather than later. Why?

1) Our first point above was "Make something good." Now, with the advent of the Internet and the ability to distribute game updates through vendors, you can fix up anything post-release to help make it better and better. However, post-release, the game design is usually set in stone. You can't simply make wide-reaching, arbitrary changes after release like make the main character move faster or jump higher, as that throws off the rest of the game. Some might think that's where DLC steps in. While DLC is definitely useful for expanding a game, I believe it serves its purpose best for expanding an existing, fixed product, not building an entirely new one.

For example, look at the difference between Zelda 1 and Zelda 2, or Megaman 6 and Megaman X. These games are wildly different from one to another - sequels that are so different that it probably would be best to do them as sequels, even if DLC is an option for distribution.

With a sequel, you have an opportunity to essentially make the game again while improving on the same basic formula. You can test out and refine gameplay mechanics, experiment with level design and puzzles, and expand on the universe. You can do more in a different way than your original game, and with the same core game idea. You can also, of course, read reviews of your original work to see what worked, what didn't, and so on. You can stand on your own shoulders to see further, so to speak.

You might even be able to reuse assets between games (or just expend a little effort to update them a bit). In addition, since the game is a sequel, you already have months of experience with the game's design. What might have taken you 16 months with the original might take you 9 with a sequel, because you've done it all before. With a sequel, you're never starting from scratch.

A certain Blue Bomber, but in 1998.

As an aside, look at the above pic of Megaman. It's the same character, but the design has been iteratively updated over the course of 11 years, going from the original Megaman in the picture at the top of this article to the one for Megaman & Forte, 11 years later. Capcom kept updating the character and the game.

2) Let's think about the second point, now - "Get the word out." If you make a sequel, getting the word out naturally leads back to the original. If you say, "Hey, I'm making Legend of the Foresaken Soil 4", people naturally know there were 3 other LotFS games out there. If you put the fourth one out there, and people liked it and want more like it, they might look for the 3 other entries in the series. When you put your games out there on stores, it also feels more likely that any recommendations would be for games you made, since they share a developer, a genre, and even most of a title. This is effectively free, honest, and organic marketing. I don't think this is something to be under-stated, especially if we're thinking about game development with a view towards the long-term (i.e. over years - even decades).

Anyway, these are just some points to keep in mind. Sequels are a core part of games in general. While the ability to update a game to bring more content to it does enable developers to expand their games, I believe sequels remain a core tool for expanding a game beyond its first iteration. What do you think? Feel free to post any comments in the... Well, comments section.

Thanks for reading!

You Already Have Motivation

2017-07-21T14:00:00.000-07:00

Yo, 'sup!

It's been awhile since my last post here on my devblog - that's something that I need to change. Here's a quickie little article that I wanted to write about - motivation.

"How do I keep my motivation in the middle of a project?" is a question that is frequently asked around in the game development community. I feel like when people ask this question, they think of motivation as some kind of inspiration - some kind of above-average, long-lasting desire to work on and complete a hard and long project. As someone who has been working on a single project for the past 1.5 years that's nearing completion, I think I've gotten a bit of perspective on what helps you keep motivation. I think having a goal, or even financial needs that you hope the project will fulfill can help keep you on track. Also, nobody other than you will make your project, no matter how similar it might seem to other games out there. However, I think there's more to motivation than that.

I think most successful developers (heck, most successful creators) don't really have that kind of "magic motivation" most people think of - the kind of ardent passion for working on something every single day, regardless of difficulties encountered or the creator's moods. I think most successful developers just take it one day at a time and just keep going. They have a goal - a desire to create something, and they keep plugging away at it, which, fortunately, is something anyone can do. In other words, I think it's not about generating motivation, but rather using it wisely.

Think of motivation as some kind of resource, like money. You wake up every day and automatically earn a certain amount of motivation, and you can spend that motivation in different ways on different things. If your project is smooth as butter, then you don't really spend anything - it's like driving in a brand new car. Super easy to get where you want to go, and do it pretty quickly. Making new gameplay systems, integrating art, making the assets - nothing's difficult, and everything's coming together according to a plan.

However, if your project is prone to bugs, has lots of systems that aren't coded as well as they should be or aren't very easy to work with - those are the kinds of issues that cause stress. They're the kinds of things you have to spend motivation on. Those issues add up, and they become something like driving in a busted-up junkyard car. It may still run, but it's uncomfortable, slow, and you have to spend more and more to keep it going.

So you want to avoid spending your motivation, as spending too much kills your momentum and overall desire to work on your project. The act of game creation is a large task, but it's not too hard to keep going if you keep plugging away at it and remove any obstacles to your process. If something in the project is suckin' the life out of you, fix it, improve it, get rid of it, work around it, whatever you have to do to "pave the way".

If you're doing it right, you won't need to push harder - you already have motivation.

Greenlit and Further Progress

2016-12-14T02:13:00.001-08:00

Yo!

So it's been quite awhile since I last posted here (YET AGAINNNN~), but things have been going rather well. Gearend was greenlit a couple of months ago! Here's an older devlog that I posted that shows a bit of what I worked on since then.

There's some more details and further videos after the break below.

Anyway, as of late, I've been cranking away on finishing the game - it's getting rather close to completion. After it's done, I have to consider when to release it - it's currently approaching the time around where Steam usually has major sales (the Winter / New Year's sale), so unless I can get the game done and out in the next couple of days (which I probably won't), it probably would be wise to wait until later, possibly in January, to put the game out.

I think I heard that it's good to have 1k people that have reserved the game on their wishlist before release to build up hype. Not sure if I'll be able to hit that (or if it's a particularly important target to hit), but I'll see how it goes from now 'til release.

As for the game, I'm waffling between adding another zone, or calling it done and just finishing up what I have. I don't have time to add another zone, really, but I don't really feel like the amount of areas I have is "good enough". I guess it's OK, though - it's a small game. Maybe I can just add some smaller intermediate special areas and bosses / events to help make the zones feel less "standalone" and less monotonous.

_____

Here's a song, Skygear, that I made for a sky / weather-releated zone. I think the concept could've been fun, but alas, time fails me. Oh, well - the song will still go in there, haha.

I also made this intro for when you first boot the game up - I think it turned out pretty cool (if a bit on the long side of things):

Anyway, that's about it in terms of visual progress - all the other stuff has been either secret, or just changes through code. Thanks for reading!

To finish things off, here's an animation of one of the bosses, the Purifier, doing a slashing attack.

Devlogs And Greenlight Preparation

2016-08-02T01:13:00.002-07:00

Yo! Sorry for being so tardy on keeping this up to date - I've been really busy the past few months (as to be expected, I hope?). Here's a bit of news, and after that I'll dump the rest of the devlog videos I've yet to post here.

So, I'm GEARing up (haha) to put this sucker up on Steam Greenlight soon, so we'll see how that goes. I'm finishing up basically enough to get a trailer out (which means some boss mechanics and some NPC stuff, I think). I've been thinking about working on just the stuff I need to finish the game at this point, rather than being distracted by feature creep - I wanted to add one more zone, but maybe I won't have time??? I'll have to figure it out - I wanted to be done by the end of July, I think. Now I'd like to be done by end of August.

_____

I've also been doing stuff to work on my website, since that's something I proooooobably should do something about. The previous site I had was made using a program called OpenElement, and it's one I would advise you to use if you're doing some website work and wanna try it out on Windows. Since I moved to Linux, I looked around at the alternatives for website design and found that there aren't really any, for some reason. So, I decided to just go the manual route - I downloaded Atom, grabbed a couple of plug-ins to do some live HTML reloading, and started learning HTML and CSS. It's just a programming language, so it's pretty easy to learn - I think I like web design, haha. Kinda wish I had started writing sites in HTML earlier, I guess.

Anyway, thanks for reading! I'll upload a new video showing my progress soon. For now, here's a dump of the remaining devlogs I've forgotten to post here! :O

Sorry about that!

Thanks a ton, again, for watching!

Shieldin' and Selectin' / Rusting Over

2016-05-23T10:56:00.003-07:00

Hey, there!

I've been making new devlog videos for Gearend, my 2D Metroid-like in development, and forgot to post anything here! I actually have something interesting that I wanted to write-up, but before that, here's the new devlog videos.

In this one, I outline some of the changes I've made since the last devlog video. You can catch a quick changelog in the description of the video.

This one is a new song, Rusting Over. It's kind of a pensive, thoughtful, sad, driving track that I think fits in rather well with Gearend. But I've got a lot more good (hopefully) music I'll show, too! Please look forward to it, haha!

Anyway, thanks for reading!

Gearend Devlog Video Dump

2016-04-23T19:36:00.001-07:00

Yo, there!

I've been making a lot of progress on Gearend, but haven't actually shown any of it around here! So first up, a devlog video dump!

Here's a song that was in the old Gearend that I'm going to use for the new Gearend, after spiffying it up some.

And some more devlogs after the break!

In this video, I show some of the new enemies that I've created; the first is the Top Woman, a robot who was originally supposed to be a greeter for the facility that now turns her hostile arms on any who approach. Also, the SecCams readjust to point toward you, and fire when they can. In the video, I also look through the AI Director system that shape the enemies' behaviors.

In this video, I show some of the music I created, specifically going for a "Chrono Trigger, Zeal"-ish feel. My computer also went down, so I explain a bit of what was going on here.

In this devlog video, I show some more enemies; one of them is a razor sharp robot who goes by the name of "Grinder", who moves on a set path and is very predictable, though extremely dangerous. Another is a radical radish known as "Radishal" who gets crabby when he wakes up!

And finally, in this video, I show some GUI that I finished up; health and energy. Little warning prompts appear when you run low on resources, and it's now possible to die and have the game restart, which is cool!

Whew! Well, that's basically all of the progress that I've uploaded on YouTube; I'll see ya later with more progress soon!

Gearend Devlog Video #6 - AI Theory

2016-04-01T14:04:00.001-07:00

Yo! Here's a quick devlog video showing how I'm approaching AI for Gearend.

The idea is to base everything around tracks that you can turn on or off, and that control which behaviors are being executed at any given time. It's basically lines of Finite State Machines strung together.

Each Track will have only one active Behavior at a time, though you can have as many Tracks as necessary. Each track also will have its own mode (Normal, Choice, etc) and its own controls (for reversing, toggling, clearing, copying, etc). The general idea is to make reusable behaviors simple and easy to use across the different games I make.

Anyway, that's it for this one. Thanks for reading!

Gearend Devlog Video #5 - Loadout and Location

2016-03-30T08:09:00.001-07:00

Yo!

Here's another development log video post showing some of the stuff that I've changed / improved!

And here's a text dump in case you don't wanna watch!

Apart from new art, cameras now lock to room objects I place in Blender, enabling me to position camera views where I want. Now I can, for example, lock the view to a single area in the game. When the player moves to another location, that room becomes active, and the camera now is fixed to that room. Each room object is exactly the size of the camera view, and if a room object is scaled, then the camera will slide around to the boundaries of the room object.

This room system will be integral to any maps I put in the game, since I can just plot squares and rectangles on a grid in the same setup as I place objects in Blender to represent the game world. Easy-peasy!

I also zoomed in the view a bit to make it easier to design the game world (since you see less, I don't have to create as much) and to just make it simply easier to see the game.

I implemented the animations for the weapons, and added a new rocket launcher weapon. Before I added the launcher, I thought a handheld bomb would be cool, but it didn't really feel fun, so I changed it to a rocket launcher. I really like this a lot more, as there's more I as a developer can do with it. I implemented this same weapon for the first Gearend, too. No reason to mess with success, I guess!

Anyway, sorry for the choppy footage; my HD Game Caster's kinda weirdin' out, so I used OBS for this.

And yeah, I see the small graphical errors here and there (small one-pixel large gaps between tiles, for example); I'll fix them up later.

Shoulders, Shots, and Shclouds

2016-03-25T23:31:00.004-07:00

Yo! Here's a quick GIF update dump!

Above, the shoulder parts moving back and forth in time with the walk cycle. Done in code, of course, so that it'll transfer to other part setups.

I animated the first two arm parts recently; when you use melee attacks, you can strafe backwards. Not sure if I want to give the player this option at all times or not (maybe through a button they can hold down or toggle...?).

The world as it stands currently (incomplete, of course; still gotta make more graphics and stuff).

Also! Something that's not shown in these GIFs is that you can communicate with NPCs, and when you do, the camera zooms in to focus on you both. When you're done, it zooms back out.

Speaking of camera changes, the camera is now locked to specific zones, each at least a screen size large. This'll allow me to do single-room views easily, as well as get a good idea of how the game world is laid out. It should also enable me to actually have a map system that works halfway decently.

Gearend Revived

2016-03-22T02:38:00.001-07:00

Yo! It's been awhile, hasn't it? Well, then. Lemme explain:

Airgrift is being paused for the moment, as I've decided to go back and start and finish Gearend.

As you might recall, Gearend was a 2D Metroid-like that I was working on a couple of years ago, and subsequently abandoned because I thought it was too big of a project for me. Since then, I've figured that the game's not gonna get done unless I started on it, and so I started planning out how I'm gonna start and finish the game. I believe I've grown leaps and bounds since then (or maybe I just know a bit more about how to get myself to get stuff done), and now I'm working on it again. Hurrah!

More info after the break!

So what is Gearend? Well, essentially it's a 2D Metroid-like where you control a robot named Epsilon-98, or "Eps", for short. As a helper-purpose robot, its job is to assist humans and aid in household chores. To facilitate this, it has a special body-type that allows it to swap out its parts to deal with the different jobs it might face. It would appear, however, that the Epsilon line was never fully completed. Time passes, and Eps now suddenly awakens, unsure of the year. It now seeks the truth about humanity, facing the traversal of a long-forgotten and out-of-control robotics facility. "Run around, shoot bad-bots, talk to people."

Here's a pic of Eps talking to an NPC, which is just a cutout. The general idea behind this is that the game takes place in an abandoned robotics facility, so the cutouts were meant to be points at which a human touring the facility could interact with the AI and ask about the area, or just get access to an AI for assistance. The AI is linked to each cutout wirelessly, so it's the same character in all of the places, despite the fact that the cutouts themselves never move. There will be, of course, other kinds of NPCs; this is just one of them.

Like in the original Gearend, the hero robot Eps can wield two weapons at any given time; in this case, it's a melee weapon and a ranged weapon. I still have to get the weapon attacking animations in there, as the weapons are at the "debug" level at the moment, but the mechanics are there.

In addition, today I spent time refactoring the code a bit and got the walking animation in there and animated. I'm now using a hashmap of animation frames to positions that indicates where the arm and core parts should be offset when the legs are moving. This means that when the robot walks, for example, the arms and legs can bob up and down (through code). Otherwise, I'd have to make bobbing animations for those parts, which is a bit unnecessary. Also, when you jump or walk, the arms rise and fall slightly out of sync with the body and legs to make the entire robot feel "heavier".

Recently, I got the grass waving through a vertex shader; attacking near the grass disturbs it, making it flutter. It feels a bit "cheap" right now, but it's a cool effect, nonetheless.

I've been doing lots of enemy design, which is pretty key for a Metroid-like; I have around 11 designed so far, which is a pretty good amount for a Metroid-like, I think. Most of them are new, but a couple are pulled from the original Gearend in one way or another. It's been fun just coming up with some random enemies, but I probably should work on specific, themed enemies (i.e. fire-themed, lightning-themed, whatever). The idea is that each unique zone'll use a couple of the "common" enemies I have so far, and a couple of hazards, enemies, or interactables that are unique to each zone. Hopefully I'll be able to get enemies created and implemented in-game rather quickly!

Here's a video series on YouTube showing my progress so far (not counting this post); I'll put up a new video soon. Thanks for reading!

Airgrift Devlog #2: Gooey!

2015-10-19T23:43:00.002-07:00

Yo!

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!~

Airgrifting All Over The World

2015-09-07T01:39:00.002-07:00

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!

End of Shakecan Games - Start of A New Project

2015-08-08T23:19:00.000-07:00

Hey, there. It's been awhile.

*Sigh*

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.

Because of this, even small games like Kyro'll take longer than just a few weeks.

Behold! The relatively simply projects that will now take years of my life to complete!

So, I think this'll be the end of "Shakecan Games" as a label (until later on, I suppose). In the meantime, I'll try to carry out the same concept and make small, compact, fun, and functional games that really just focus on the fun of core concepts rather than getting bogged down in other things.

The current game I'm working on is called Airgrift. It's a rather simple concept, which is a mixture of Pac-man with other maze-like action arcade games.

The plan is to make the core concept play like Pac-man, but add additional features and elements like hazards, enemies, and different manuevers to kind of update the gameplay and keep people playing it.

Since most maze-like games tend to focus on action, I think I'd like for the game to have puzzle aspects available as well to help mix up the gameplay. The basic gameplay loop is something like this:

Enter stage, notice all stage gates are closed
Collect all money bags / "necessary" collectibles
Stage gates open
Head into next stage

When starting, the game will spawn one of a random selection of maps for you to play on next, and the game progresses by you clearing those maps (obviously). Overall, this should mean that the game won't feel stale as you continue to play on different maps and experience different challenges and progressions.

The items you pick up will most likely be money bags that will be points that directly contribute to your score. In normal games, this mechanic does stuff, like how large point denominations give you 1-ups in most arcade games. However, in Airgrift, the money bags you pick up will serve a secondary (primary?) purpose of currency. You'll be able to spend the bulk cash you get to upgrade and improve the game overall. For example, you'll be able to purchase different characters or additional map packs to add variety to the game.

I'm not sure if the game will have a definite end to it any more than Pac-man really was just designed to be played infinitely, more or less, but if so, it'd probably be at the end of a number of levels, like after you progress through, say, 25 maps in a single run.

Anyway, that's the general idea that I'm thinking about and working on. Thanks for reading!

No Man's Sky Mixtape Game Jam

2015-06-03T16:03:00.001-07:00

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

Recently, I joined an indie game jam "mixtape" that has a bit to do with the upcoming indie game, No Man's Sky. The theme of the mixtape is exploration, but rather than do something like a Metroid-like or another kind of typical exploration-based game, I decided to try something different.

The game will take place from a top-down perspective and will be about actively solving and completing "rooms". You'll start at one door of the room, and your goal is to reach the other exit door in the room. These rooms will have various hazards, traps, or puzzles in them that will challenge you, and the goal of the game is, of course, to get through as many of the rooms as possible.

I started the game in BDX, and it's been going pretty well. It's only been a couple of days so far and I've spent some time writing and improving maze generation algorithms to generate some rooms for the game, as well as some time on a bit of art.

A random maze generation in the game. The weighting can be
adjusted to make for more straightaways, for example.

However, after playing it a bit, I'm not sure if I'll use them. I want to try some different, well-defined gameplay mechanics, and random generation doesn't play so well with that idea. I might use some random maps, but I think I'll go with pre-made rooms that are randomly placed and chosen as you progress through the game. The idea is to continue moving through as many rooms as you can. Perhaps it will end after so many rooms, but the core gameplay loop is pretty simple, and will hinge on a couple of types of exploration:

Spatial Exploration - Exploration of your surroundings. On entering a room, you see where all objects / interactables are and what they do.
Logical Exploration - Exploration of thought and gameplay mechanic. You explore how, where, or when to reach the room's exit. Some rooms might be simple, but rely on puzzles, while others will be more action-based.
Linear Exploration - Exploration of the entire game. When you complete a room, you move into another one that is physically revealed to you as you enter. This will hopefully give the effect of each room feeling fresh and unique, but also unknown, in a sense.

What the game looks like as it is in the randomly
generated maze.

I only have a couple of weeks to get everything done (the mixtape ending on Sunday the 14th), so I'd do well to hurry it up, haha!

'Till next time!

The Next Game

2015-04-03T01:57:00.000-07:00

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!

Visual Improvements

2015-02-21T02:33:00.000-08:00

Yo!

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!

Shakecan Game #3 - FamiDet (tentative name)

2015-02-14T00:44:00.002-08:00

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!

KYRO'S DONE!

2015-02-09T02:27:00.003-08:00

Yoooooo

Kyro's done!

Check it out here!

Here's a video for ya!

Thanks for watching development!

Kyro's Almost Done

2015-02-01T02:05:00.002-08:00

Hey, there. So Kyro's coming along nicely; not completely done, but not far away. I'm sitting on around 13 levels (screens) so far; I'd like to break the 20-puzzle-mark, I think, considering there are some "introductory / tutorial" rooms that just introduce mechanics over actually being puzzles.

Hopefully I'll finish it soon (I wanted to get it done before a certain date a few times, but kept passing it up). The game should turn out pretty fun, though.

Anyway, (in addition to other things and working on the engine the game's based on), I got swapping in. You can swap locations with certain objects (usually ones that can move on their own) by throwing your gem next to that object.

Fans are also implemented - they can be triggered with a button press (if they're not on already) and can lift lighter objects (not the main character, haha).

Also, "switchable" objects turn green when they're triggered, which is helpful when you're looking to see what a button does.

Anyway, thanks for reading!

Kyro - Day Something Oruther

2015-01-27T02:17:00.000-08:00

Yo! Soooo I missed the week deadline that I was aiming for, unfortunately (I should have been done around Friday the 24th). Oh, well; I think I've learned to adjust my expectations according to how much I (by now) know I'll work on my projects. So, I think I'll just try to make something every two weeks or so, since it seems like I can hit that pretty reliably. I will finish Kyro, though; I hope to have it done by the end of this week (at the LATEST before the end of January).

As far as development actually goes, it's going well. I do some additions and work on the engine I'm building Kyro on (BDX) while I'm working on Kyro itself as well, so it's kinda slow in some respects. However, it means that I have pretty good control over how things work and have a goodly amount of knowledge of how the engine works, which is cool.

I've gotten teleportation done and looking pretty spiffy with some particle effects, along with an enemy that just kinda waltzes around. Touch it, and you die, though in the tradition of Lolo games, it's not particularly dangerous looking. I plan (planned) to have multiple enemies, but I'm not sure, as I don't want this to grow into a full-blown game that takes a lot of time to create. I actually also planned to have simple combat, but wisely slashed that outta hand to focus on the puzzle gameplay. I already have five levels done, and making more shouldn't be difficult at all, so I should be able to hit my target time. There's not too many game elements that I've implemented yet that really "change" the gameplay, but it's already looking and feeling like a cool little puzzle game. Although, I'm already looking forward to the next game, haha. :d

Anyway, thanks for reading! See ya!

The Continuing Continues

2015-01-24T08:46:00.001-08:00

Really short post, but I got the teleportation mechanic working, which is good. You press a key to throw a teleportation gem (a dimensional quartz enhanced by a lost technology), and can press the key again to teleport to the position the quartz hits. You can recall the quartz as well, in case you screw up a throw.

The game's shaping up, though I've, again, already passed my mark for a week. Still have a ton of stuff to do, but it seems like it's not that much since most of it is just placing stuff I've made already. :o

I'll continue as best as I can until it's done, though! ≖‿≖

Kyro - Day 4 Or Something Like That

2015-01-21T02:16:00.001-08:00

Today I implemented transitions into the next rooms:

And restarting after you mess up royally.

I also got the teleportation mechanic working OK; it just needs to be polished and refined. Welp, more news or GIFs next time.

Kyro - Day 3/4

2015-01-19T21:12:00.001-08:00

Hey, there. So, I'm a ways into Kyro, the second ShakeCan Game I've been working on. If you don't already know, my ShakeCan Games label applies to games I'm making with a goal of finishing in a very short period of time - generally just 1 week.

So far, I have a couple of the basics of the game down - you move around and can trigger switches. Each switch can trigger any number of other "switchable" objects. Your goal in each level is to get to the stair-set, as that will allow you to move on to the next room.

(I think) I've yet to show or explain the "gimmick" behind this game to not make it a pure "Adventures of Lolo"-like production, but it's turning out well nonetheless. Now, "gimmick" can kind of sound like a bad term, but I think it can just describe a trick or additional ability to traverse a puzzle that isn't present in other titles. I think many good puzzle games employ gimmicks, especially ones on PC after the popularity of Portal 1 and 2. Those were two good games that really developed and expanded upon the portal-hopping gimmick to be interesting and engaging. It wasn't too difficult to grasp or work with, and even relatively simple puzzles required a good amount of thought to work through. So in other words, I hope the gimmick in Kyro will be simple, interesting, and fun to work with for players in the end. Anyway, I hope I can keep up the pressure! Thanks for reading / watching!

A New Week-long Project - Kyro, Day One

2015-01-16T22:30:00.001-08:00

ALAS

I wasn't able to get the previous game (Lodemen) done in under a week, and I found it rather difficult to continue. Newer game engines nowadays aren't really made for tile-based gameplay, and Lode Runner's physics system is rather finicky and kind of requires such a tile-based approach. Excuses, excuses. Bottom line, it proved difficult to reproduce for me, so alas (again with the alas) I decided to break it off. I've started on another Shakecan Game that I aim to finish in a week. I'm attempting for this to be much simpler - it's going to be an "Adventures of Lolo"-style puzzle game.

In Adventures of Lolo for the NES, you controlled Lolo as you cleared a series of single-screen rooms. Each room would have a puzzle, usually, and you'd have to figure out how to move blocks, avoid enemies, or traverse the landscape in order to leave.

This game, Kyro, will be similar, but in my game you'll control a monster woman named Maxelena who has the ability to teleport by throwing a device. The game will revolve around using this mechanic to traverse and clear the puzzles in a similar manner as the Lolo games. The game is, again, being created in the (still in an incomplete, pre-alpha status) BDX game engine.

While I do think I should be able to handle the gameplay fairly successfully, I'm not sure how many rooms and puzzles I'll be able to make before the week ends. Given that puzzle games require, well, puzzles to work, I might not be able to get very far with this one. Guess I'll see. :1