18,776 Words Later, I Figured Out The Story I Was Telling

Yup. That sure is a lot of words. They are good words, too! I'm proud of many of them. Most of them! Here's the problem: they don't really tell a story. I went into this project with a great setting and a decent character and a vague feeling that maybe I should have a plot. I decided that I would figure out the plot as I went. And I did! After nearly nineteen thousand words and four and a half vignettes.

My original plan to deal with this was to go back through the vignettes I'd already written and add plot. I'd just put in a few extra scenes, throw in some choices, and voila! - a story. I've realized that that's not quite how it works. Often, the best way to improve a work of writing is to take stuff out, not put stuff in. Plus, it turns out that the IF platform I've been using, Inklewriter, makes it incredibly difficult to go back over stuff I've already written and add more choices.

I Can See The Finish Line (And A New Website!)

Hi all! This week's vignette was fairly short, a little less than 2000 words. But I had a good reason for slacking off, I promise - I built a website! Maybe you are there right now reading this blog post.

It turned out to be kind of a huge project. I decided to code it from scratch rather that use a website like WordPress, because I need the web development practice. It took me maybe ten to fifteen hours total? Some of that time was learning to use the tools. I used a CSS framework called Materialize. It's a great library, with lots of tools to align elements properly, really good responsiveness (i.e. sites that look good on mobile and on a computer), and cool effects and transitions. It wasn't too complicated to use, but I had some problems making my vision for the website conform to what the tools let me do. The back end (the server) is written in node.js, a well-known JavaScript server-side environment. I used a module called Express to handle HTTP requests, which actually lined up nicely with what I'm learning in Computer Networks class.

Onward and Upward

This week's (and last week's!) vignette was a lot of fun to write. It focused on the main characters relationship with his teacher/father figure, a historian and sociologist named Karl. As I laid out last week, it was actually three distinct stories that can be played in any order, just as the entire project will be a series of vignettes that can be played in any order. I had planned to add branching options that change each story based on the decisions the reader made in the other stories, but I ran out of time. I will still put that branching in, but it will have to wait until after I've written the rest of the vignettes.

Evolving the Plan

I really tried to think of a clever title for this post. Something involving evolution and adaptation. Eh, what are you gonna do?

So, here's the deal: I was too ambitious in my plan for the semester. School is really kicking in now, and I simply don't have the time to write a vignette every week. Luckily, the way I organized the project makes it very easy to switch things up.

The original plan was to have 10 vignettes, with some level of branching between them but with a mostly linear narrative. Last week, I detailed a design structure that would let me have more branching without actually having to write completely separate branches - the vignettes will be playable in any order, and the decisions the reader makes in one vignette will change plot points and enable branches in the other vignettes. That way, I can have high replayability without having to write tons of unique content.

Why Writer's Block Isn't An Excuse

Well, two weeks in and I'm still on schedule. That's a good sign! I wrote another vignette this week, about the main character's arrival to the great city of Adriata. Honestly, it was a bit of a struggle. I procrastinated early in the week, which led to a crunch later (hence the Sunday night blog post).

I feel like writing is difficult to schedule. Sometime I sit down to write and my mind just blanks out. There are certain ways to cope with this, like diagramming a scene or conjuring a concrete image in my head and trying to describe it, but it's not like a coding project where I have a clear list of tasks to accomplish and I can just push through it until I've accomplished them.

This makes it very easy to justify procrastination. "I've got writer's block, I can't work right now." Here's the thing: I don't really have the time for that kind of leniency. Not that I'm beating myself up, because things happen and schedules change - but the fact is, I have until the end of this semester, and then I'm starting my senior project and my independent study and my life gets too busy to do development on the side (although I am brainstorming ways I can fit bits and pieces of projects I want to do into that schedule). Anyway, the point is, I have 11 weeks left to write this thing. I'm proud that I finished this week, despite the slow start.

Branches of the Past Project Announcement

I am taking a class called Software Engineering, and I think it's changed my life. In that class, I am working with a group to develop and release a software project using a technique called Agile methodology.

Now, the life-changing part isn't the project I'm working on. It's not Agile methodology specifically, either. It's the simple idea that to get a project done requires concrete goals and a real plan.  In other words, business 101, but I'd never really thought how to put that idea into practice. In this class, we developed a vision of the final goal, then broke it up into achievable tasks and scheduled the semester to plan when we will complete those tasks.

A Game(?) A Week(?): Dungeon Generator

You know, I'm running out of quirky ways to say "this took me more than a week, huh". Turns out that going to school full time and working on weekends doesn't leave as much time as I thought I had for game development. Anyway, this project, which is neither a game nor took a week to build, is a dungeon generator! For a rogue-like. I was actually hoping to build a full rogue-like this week but this is all I had time for. I'm quite proud of it.

Rogue-Like Dungeon Generator - total development time 2 weeks

What it is: A program that procedurally generates dungeons in the style of Rogue. There is a player character who can walk around the dungeon, but all the important features of rogue-likes - combat, items, treasure, stairs, field-of-view - are not currently implemented.

A Game A Week(ish): Zombie Slayer

On Venus, a week is 1701 Earth days, or 4.65 Earth years. So on Venus, this game would have been made in 0.0111699001 weeks!

Yeah, okay. 19 days is a little longer than a week. Midterms intruded, then fall break. In total, I probably spent about 10 days working on this game. I won't be able to do a detailed breakdown, but I will give best estimates on how that time got spent.

Without further ado, the next game! It's called Zombie Slayer.

Zombie Slayer - total development time ~8 days

What it is: A game about shooting zombies in a procedural town. There is no win condition, just try to shoot as many as you can before they overwhelm you.

A Game A Week

My attention span needs work. I have a tendency to get excited about a BIG IDEA, start prototyping and blogging, and then losing steam a few weeks later when I get excited about THE NEXT BIG IDEA.

To solve this problem I've decided to never spend more than a week making a game!

Okay, that's not really the solution to my short attention span. And it's not really the plan for the rest of my life. But at this stage in my game development career, the two most important things for me to do are 1) get experience making games, and 2) build a portfolio of finished* projects to show prospective employers, teammates, and my legion of devoted fans.

A Game A Week: Dungeon Runner

The first ever game-of-the-week™ is a game about running. And jumping. You do that too. It's called Dungeon Runner.

Dungeon Runner - Total Development Time 12 days


What it is: A game about jumping over gaps. Run all the way to the end of the dungeon to win.

Coding Beauty: Part 2

Last time, I talked about the level and art design of Ori and the Blind Forest. I spoke of the two broad steps to creating its sumptuous platformer levels: first, design the basic platform layout; then texture it and add details to bring it to life. I've begun implementing the algorithm that will achieve step one of that process.

Here's what the results look like so far:

Coding Beauty: Part 1

Look how beautiful Ori and the Blind Forest is:

I mean, that's gorgeous. The dilapidated tree trunks in the background, the ominous foreground, the interplay of light and shadow -- not to mention, if you actually play the game it's all animated. The grass sways, leaves blow through the air, mist snakes through the trees. It's really freaking beautiful.

Pixel Pushing

Hey all! It's been a while, hasn't it. Last post was shortly before finals week, I believe, after which May term classes and a new job ate up most of my time. That doesn't mean I haven't been working on game development, though!

In my last post (long, long ago), I talked about procedural generation. Procedural generation (proc gen for those of us In The Know) means using algorithms to create levels, enemies, worlds, characters - anything, really - instead of making those assets by hand. It allows for a single developer to develop A LOT of content quickly, as all he (I) have to do is write an algorithm. Now, I don't want to minimize that - those algorithms can take months (if not years) to develop. But once the code is working, it can literally generate an infinite amount of unique content. That's pretty sweet.

How To Make A Cube In 81 Easy Steps

Hi all! It's been a couple of weeks since my last post. I've been very focused these couple of weeks on trying to generate buildings from an algorithm. It's been slow going. The basic algorithm goes something like this:

1) Generate a shape.

2) Do stuff to the shape.

3) Texture the shape.

Screw Tarzan

This week: finished implementing the grappling hook, kind of. Completed a tutorial on the basics of procedural generation (the link will probably just prompt you to buy the tutorial, unfortunately, although I'd definitely recommend it to anyone interested in developing games in Unity).

The swinging mechanic, briefly: I corrected my naive implementation (detailed in this post) with the help of the Sparknotes SAT Physics prep guide. In particular, I found this helpful diagram:

A First-Person Cyberpunk Rogue-Like Hacking Action Platformer

I'll keep trying to think of more superfluous adjectives I can add to that game description. How about, "A First-Person Shooting Platformer Hacking Action Game With Rogue-Like Elements"?

Huh. I'll work on it.

So, the new game! As you may have guessed, it will have a first-person perspective, involve hacking and jumping/jetpacking/grappling-hooking around, and (hopefully) feature procedural elements and permadeath.

I Should Have Been A Physics Major

You ever play the Spider Man games? I never played the spider-man games. I watched the Spider Man movies though! Spidey has some pretty sweet web swinging moves, huh:

Apparently, the Spider Man games have some pretty sweet swinging moves too. As it turns out, the guy who designed those swinging moves wrote a tutorial about how to put moves like in your own games. Which was perfect, since for my FPS the player gets a grapple gun thingy so he or she can do some pretty sweet swinging moves themselves.

Back To Business

Wow, it's been a long time since the last post! From now on, back to weekly entries.

The strategy game crashed and burned. I was trying to merge two tutorials I was following and they didn't play nice together. Then I tried to fix it, and broke the code some more, and from there things pretty much spiraled down hill. At this point, I'll have to start from the ground up to rebuild it.

I bit off more than I could chew, so instead of diving right back into the strategy game, I'm working on some simpler projects. I've created the first level of a mario-style platformer, and I'm working on implementing the movement mechanics of a fast-paced first person shooter (think Unreal Tournament).

Finding the Path

Pathfinding! It's what makes units go around obstacles instead of through them, and it's something that is now in the game.

I used something called the A* algorithm to implement pathfinding. It's a bit complicated, but basically it calculates the shortest walkable route between two points. The algorithm itself is generic, of course, so I had to figure out how to implement it specifically in Unity. Unity does include a built-in navigation utility, but word on The Internet is that it doesn't always work very well. Plus building it myself gave me a much better understanding of how it works and how I can customize it to my needs.

Laying the Groundwork

Progress continues erratically. I'm taking a learn-as-I-go approach, which means that I often have to go back and change some previous work to reflect new knowledge.

I've been spending most of my time following a tutorial about 'traditional' real-time strategy games à la Age of Empires. I've implemented camera controls and a lot of background code laying the groundwork for players, units, buildings, traps, and other world objects, as well as a basic UI. Right now, the game knows when you select something and can tell you what is selected: