I mentioned in my intro to RPG Maker scripting post (and in the panel that’s based on it) that you can use source control systems like Mercurial or Git with RPG Maker VX Ace, allowing you to take periodic snapshots of your work.
(First, you’ll want to read a tutorial about how your chosen source control system works, such as hginit.com for Mercurial. This post will make a lot more sense once you do.)
What I neglected to mention is there’s two big, easy-to-forget gotchas with this setup.
MTAC, April 14-16, Nashville, TN
MomoCon, May 25-28, Atlanta, GA
If you happen to be following by RSS and caught the last couple of posts… I’m back.
As dire as it sounds, there was apparently a WordPress vulnerability discovered recently that allowed anonymous users to create and edit posts. As I don’t regularly touch the site, I didn’t see the updated version that fixed the issue, and so this (and several other sites I host) were affected.
My last post was basically an info dump on what I’d learned about RPG Maker Ruby scripting during Ludum Dare 37. From the comments I got on it, I realized “info dump” is not an exaggeration–it’s literally a bunch of abstract, raw information without any examples, and so it’s confusing if you haven’t messed with it before.
So, let’s walk through how we’d think through a very simple change.
Ludum Dare 37 was the first time I’d really, truly built a finished product in RPG Maker rather than tinkering, and I learned a lot. Given that RPG Maker scripting doesn’t seem to be a well-known topic among more casual users, it seems like a good idea to try to summarize a lot of what I picked up.
Continue reading
This is a follow-up to my last post, Building a Procedurally Generated Platformer, which (not being a disciplined blogger) I’d sort of forgotten about until a comment about an off-hand remark I’d made about another blog post popped up in my RSS feed. Then (again, not being a disciplined blogger), I forgot about that half-finished post until I started thinking about writing a new post and checked my WordPress admin.
In the last post, we discussed one way you could randomly generate a two-dimensional array of values representing ground, platform, and trap tiles. For example, it might look like this:
The trick, of course, is to convert each of these chunks into actual Unity objects, and to do so in a way that performs well.
Because we’ll be adding new chunks as needed, we want to make sure we don’t freeze play due to adding large chunks that are costly to instantiate. Because we want to restart the level quickly (without reloading the scene), we want to minimize the cost of creating new game objects.
Continue reading
Over the course of the last two Ludum Dare jams (and subsequently developing Shifty Shapes and Retrofuture into full-fledged games), I’ve started thinking about user interface as a significant part of the design process. I won’t say it’s a grand unified theory of inputs, more like a checklist of where I’ve been bitten in the past.
Continue reading
Recently, I’ve been playing around with a “procedurally generated endless runner” game concept in Unity. It’s really meant to be a set piece for Knox Game Design–a multiplayer game that we can show off that’s both quick to play and has a lot of replay value. Here’s an explanation of how I accomplished that procedural generation. Continue reading
Here’s a quick rundown of the ups and downs of my compo entry, Shifty Shapes, which was written in Unity. (You can play it on itch.io.)
Usually I make some notes about the top themes in each round of voting, but this time I went in cold. (Honestly: I have a few different game ideas floating around in my head right now, so I was open to doing something off-the-cuff.)
Once I decided to go with the “shape” wordplay, I had all of the rules for the game written down within minutes.
The sliding concept was inspired by a board game called Ricochet Robots that I played in analog gaming at Geek Media Expo, plus standard match-3 mechanics which I’d already figured out an algorithm for in Ludum Dare 30.
I knew I wanted this game to have some nice visual effects, since I envisioned it as one of those shiny mobile puzzle games.
Fortunately, there weren’t a lot of moving pieces in the concept, and I started building the effects early (even before I’d replaced the placeholder art).
Animation is something I don’t tend to think about (or I think about so late in the jam that it’s complicated to implement), but a little bit seems to go a long way.
Bouncing UI elements and blocks/items flying to their respective counts were easy to implement. I feel like my biggest win was making item and score counts only increment when the block/item reached it.
The main riff was based on something I’ve played around with before on guitar–variants of C, with Am and Em thrown in, followed by a quick “bridge.” It worked pretty well, which means I spent about 10 minutes working out the tune, leaving most of Sunday for recording and mixing.
Because I wanted new blocks to fill in like a circular progress bar, I ended up having to mess with Unity UI early (as it supports “filled” images). I’ll confess, it’s something I’ve avoided for the longest time, because it’s intimidating.
Rather than mess around with the large block of numbers that don’t seem to change anything (Unity just recalculates the X and Y positions when you change them), I’ve preferred to stick to world space, Camera.orthographicSize and Camera.aspect, 2D Toolkit, etc.
However, I feel like I’ve made serious progress learning Unity UI thanks to this game. And because I didn’t need to dip into 2D Toolkit for text, I think this is the first Ludum Dare where I’ve had no Asset Store dependencies.
There are few things more satisfying as a coder than being able to call a “Reset” method after a Game Over screen (as opposed to “screw it, I’ll just reload the scene”).
One of my big plans for visual effects was to have blocks “fill in” like a pie chart. That’s actually pretty complicated if you’re using Unity’s Sprites, and I spent more time than I’d like trying to make it work. Once I realized sprite masking was going to require shader code, I gave up on this approach.
Even though I was reluctant to mess with Unity UI, UI Image supported this exact feature, and I got the effect I wanted. However, I wish there was a way to do this via Sprites, and I spent more time than I’d have liked chasing that solution. (Although, I did do this first thing on Friday night so I could budget my time.)
I’ve been playing around with Krita recently, and because of some of its pen and paint effects, I initially picked it over GIMP. However, the art I created didn’t feel right–it had a dark, hard-contrast feel.
This wasn’t Krita’s fault, I just wasn’t familiar with it. It was definitely a case of thinking a tool based more on physical mediums would magically produce something “painterly” without me having to understand how it worked. I ended up redoing everything (except the cloud particles) in GIMP, and was pretty satisfied with the result, despite spending a lot of extra time on unused art assets.
Because I guess I have something to prove, I decided to try to mix in cajon, banjo, and mandolin in with guitar. I can’t tell whether it works or whether it’s all out of tune, because my first impression changes each time I listen to it.
I suspect part of the problem is I changed the speed on the guitar part in Audacity, and then tried to increase the pitch by the same percentage to compensate. Also, I’m not enough of a musician to pull this sort of thing off with consistent quality (which is why you’ll note all of the non-guitar tracks are mixed very low and silenced in places).
To be fair, it went OK, but this is the first time I’ve been frustrated with myself for not planning in advance.
I always go in building for the default Unity 960×600, only to remember on Sunday afternoon that it’s slightly too large for the LD site’s embed (and even a little awkward in the browser alone). I really need to standardize on a resolution and aspect ratio before I go into a jam. I tend to just jump in the preview window and forget about this part.
Also, given that WebGL builds seem to take somewhat longer than Unity plugin builds did, I need to start planning for this in advance. Luckily, I did a release to itch.io on Saturday, so I was able to iron out some WebGL issues with particle effect sprites early, but it would’ve been stressful if I had waited until Sunday.
Slide decks for my panels:
I didn’t get in until late Thursday night, and didn’t make two of my panels. Here are the slide decks for those: