Update: 1 month of college edition

If you've been reading this blog, you may have noticed that I haven't made very much posts apart for the capstone ones. To be honest, I haven't made too much headway on most of my projects recently. This is caused by several factors:

1. Capstone - This one's obvious. Capstone, being the final piece of my college career, has to take priority over my other projects. There's always plenty of work to be done, so I don't have as much time for personal projects as I'd like. Thankfully, this generates plenty of posts
2. Sickness - If you're a student right now, this might also make some sense. Going back to school tends to result in the entire student body catching a cold, so it's no wonder. I've been taking it unnaturally well, but it still makes me a bit slower on the work front
3. Too Many Projects - I started this semester with 2 major projects: Halberd and DFEngine (Eventually AMAZE and Space Douchebag too). I'm currently sitting on.......9 projects. Brainstorming for capstone and a general creative mood has led to a bit of an explosion. This particular deluge of ideas seems to be over now, but I still have to split my work more now. None of these newcomers are ready just yet for a post, but they will be soon.
4.  Work - In addition to all of this, I have a part-time job. That's going to be over(ish) pretty soon, but that currently eats close to 15 hours a week, when factoring in travel times.

Those 4 factors are the main reason that the posts have dried up a bit. With that said, let me give you some quick updates on some of the things that I'm working on.

1. Halberd - I've fixed all of the bugs that I pointed out in my last post! My next goal is to figure out how to set up a decent GUI for the editor. I'm leaning towards using an established library such as Gtk, but I'm not entirely certain yet. That decision is the main delay in the project, and once I've made a decision I'll probably post about it.
2. DFEngine - I'm occasionally working on this on and off, mostly trying to set up a better logging system. I'm also working on a post about that as I go.
3. Tutorials - I'm finally back to my ncurses game tutorial, with one opf my new game projects. I've started writing the post for that, and hopefully you'll see it soon.
4. Software - I'm currently cleaning up one of my personal projects, and once that's done I'll be releasing it on Github. I'm pretty excited to get another piece of normal software out for use, and hopefully that'll also be ready soon.

Last but not least, I'm teaming up once again with my good friend Peter Orzell. For the unacquainted, Peter is a bit of a mad scientist and the composer who's made most of the music in my games. (A Wheelie Good Time, Diamond Rush, Space Douchebag, and Doomsday Darren Goes Fishing)
Two years ago, we made a little 'gem' called Duke Spookem 3D for Game Architecture class. It was a big hit with the people we showed it to, and now we're back together working on it again! I'm currently working on getting the game to run on Linux machines, and then we'll start swapping out the assets and fixing up the engine. With any luck, you'll be seeing some more posts about that in time.

Capstone Update 3: Sports Game!

The first phase of our development is nearing its close, and now we've started all of our demos. We've got 3 more concepts that we've begun to prototype, and I'll be covering them all in general next week, but today I want to focus on my prototype: Sports Game.

Sports game is a very odd concept that I came up with during one of our brainstorming sessions. A question formed in my head, along the lines of "What would Calvinball look like as a video game?" (This, of course, refers to the made-up game that occasionally popped up in Calvin & Hobbes comics) From these roots, the idea formed for an actual game. The general concept of Sports Game is an absurd one: The game starts out like soccer, but every 30 seconds the rules change randomly. This usually means the addition of a new element to the game, such as half the field falling into a pool of bubbling lava, a prisoner being dropped into the field for public execution, time travel, or maybe just hundreds of regulation Sports Balls spewing into the arena. Also, everyone is riding around on office chairs, because at this point, why not make things a little more interesting? The office chairs actually came from a different game idea. We couldn't find a good way to make it into a proper game, but we really wanted to keep some of the concepts. Sports Game, being built around silly and arbitrary concepts, seemed like the perfect fit.

The 'normal' start of the game

In my vision for the game, Sports Game(or Sports for short) is a huge thing in society, much like sports are in the real world. Stadiums use newer and wackier devices to try and woo the crowds with their rules.

The prototype is going well at the moment. I have the most basic mechanics of rolling around and scoring goals working, and now I'm working on the multiplayer and rule-changing elements.

The Multiball rule duplicates all the balls on screen

As you've seen in the above screenshots, I've also made a basic chair model for the players to sit in. Here's a closer image of the model:

It's basic, but I think the simple aesthetic looks good for a game like this. I still want to make some improvements to it, but now isn't really the time for that. Maybe you'll see this again if we go through with this game!

Halberd Update 2 : Scrolling Around

Just as promised, here's a short update on my progress with Halberd. I've started to adopt a new strategy for work that spreads my work out more, so work on individual projects has slowed down a bit. On the other hand, I think it's more fun, and I've been making more progress on projects that had been sitting by the wayside for a while.

A couple of things have been done for this project since this summer. The biggest update has been to map loading and scrolling. Just like I originally explained, maps are loaded as the player walks between them. To ensure that the game world can grow to any size, actors in the world use 3 sets of coordinates. The first one refers to the map that the actor is in, the second is the tile that the actor is on within the map, and the last set is the position used for rendering. Using this setup, we can allow actors to move smoothly between tiles, and while also having enormous maps without any extra tricks.

This update is pretty short, so I'm also going to leave a couple of screenshots showing off the current status of the editor and game.

Here's a view of the test player standing at the intersection of several map segments. The unsightly seams will be going away shortly, but in the meantime they do a good job of showing how the maps connect nicely.

Now, here's a second view of the area, from the map editor. As you can see, multiple map segments work even in the editor now, as does zooming. However, the editor doesn't yet support map streaming like the game does. I also need to get the grid to draw on more map segments. It shouldn't be hard, but the multiple segment feature is still a work in progress for the editor.

Lastly, I just finally got the code for this project up on Github. If you're wondering how much duct tape is involved holding this engine together right now, you can finally find out! My next goal is to clean up some of the little bugs here and there, and polish the editor up a bit more. After that, I can get back to adding more gameplay features.

Capstone Update 2: The 1st Concept

Now that capstone is underway, our group needs to begin prototyping some of the many ideas that we've been throwing around. The first idea that we've decided to use plays off of a common trope in many games. Have you ever wondered, in a dungeon, why none of the traps are sprung? Have you considered where all of the gold and treasure chests dotting these caves actually comes from?

Enter the restocker.

The point of this game is to enter dungeons and restock them, by resetting traps, refilling chests, and strategically placing corpses with loot. At the end, your performance is graded based on various criteria, like the time it took you and the distribution of the treasure.

Mechanics: Scoring

I'm not going to talk too much about the gameplay itself, since the first prototype isn't even done yet. However, I want to address one question that I was asked while we were discussing the game. The issue that came up was how we could actually grade the player's treasure placement, and I came up with an interesting solution for us to try. Using a technique sometimes referred to as Dijkstra mapping, we can generate heatmaps of important elements in a level. From that, we can analyze how well the player placed treasure, and we can tell whether it's too spread out, to clumped up, or even. We can also theoretically make our own heatmaps of how we think treasure should be distributed, and compare them to the player's results.

Dijkstra Maps

I'm going to go out on a limb here, and assume that you likely don't know what a Dijkstra map is. If you have any experience with game AI, you probably know about Dijkstra's algorithm. Variants of this algorithm, such as A*, are used for pathfinding. Essentially, it works by starting at one point and expanding outwards until the destination is reached or the map is filled up.

With Dijkstra mapping, we perform a version of this from multiple starting points and with no destination. In addition, we can give each starting point a value and make it count down as it radiates outward. If we keep the highest values, then the result is a heatmap generated from the points used. From here, there are a variety of things we can do with the resulting data. One option is to check if lowest value is above a certain threshold, which ensures that no part of a map is too far from a point. Here are a few examples:

1 emitter, no walls

1 emitter, walls

3 emitters, walls

If you compare examples 2 and 3, you'll notice that the values are much higher (redder) as a whole in the latter. This is the general goal here. By spreading out multiple emitters (chests), the resulting values will be much higher than if we place just one in an area or bunch them up.

Capstone Update 1: Introduction

Another year of college has begun. With it, something new has started as well. For those of you who've been counting, you might notice that this is my senior year of college. What that means is that my college capstone has begun.

In Champlain's game majors, the capstone is similar to other game production classes, except that it has a larger scope and runs for the entire year. Each production team starts with 4 members, and a number of teams are eliminated at the halfway point. While doing all of this, students are also expected to blog about their work regularly, which is the reason why I'm writing this post now.

For now, I'll leave the explanations of capstone at this, and leave a little hello to anyone who came here from my class. Expect more soon!

Ads

I've removed all ads from this blog. To be honest, I'd been halfheartedly meaning to remove them for a while, but I never really got around to it until now. The ads were a bit of an experiment to see if I could make a tiny little bit of money on the side with my blog, even if it was only enough to buy a snack once in a while. However, in the past couple of years they've made so little it may as well be statistical noise on an otherwise flat line. It makes a lot of sense, given my general lack of visitors.
Since all they do for anyone right now is get in the way and take up space, I've removed them.

Halberd Update 1: First Revival Well Underway!

DISCLAMER: I wrote this 2 weeks after this post, and then completely forgot to hit the publish button. As such, the project has advanced a bit since this was written. Rather than spend time to edit and extend this post, I've decided to publish it and make a followup. The next update post will be coming out shortly with newer information.






Hello again, readers.

It has been about 2 weeks since my big announcement, so I think it's time to lift the veil on project #1, Halberd. I've been hard at work getting the project up and running, and it's approaching the point I left off at right on schedule! This might be the second time I ever get a deadline right. But enough rambling, if you want progress then it's progress that you'll get.

What's Done

Overall, most of the foundational pieces of the engine that I had before are in place again. On the editor side of things, I've only made a little bit of progress, just enough to get up and running. You can place and delete tiles, and I've also added autotile support.
However, the game is much farther along. You can already walk around and interact with objects, and I've even got some nice textboxes popping up. The textboxes in particular are a very nice feature, because I've polished them up quite a bit. When you tell the game to display text during the game, it automatically handles word wrapping for you based on the size of the text and the size of the box. That's not all, though! If your text takes up too much room for one box, the leftovers will be split up over extra boxes automatically. This one-size-fits-all approach will be quite helpful if I ever decide to change the size of the text(or the boxes, for that matter). It will also be doubly useful for anyone who needs to deal with localization, since all calculations are done based on the size of the text.

What's Left

Of course, this doesn't quite cover everything. There are still two major features left to implement back into the game, as far as I can remember. The first feature is the inventory system. While the game didn't have much to do with it at the time, there was already a basic inventory that could hold(and use) items. I'm not convinced that I'll be doing this yet, since it touches a lot of other features that I would want to address first, such as menu navigation. The other feature, map scrolling, will likely be my next target. As basic as scrolling to follow a character may seem, it's a tad more involved than it sounds. The old game had its' map system set up to allow a large world with no clear barriers, and it achieved this by streaming in map data as the player moved. In addition, reaching one end of the world would wrap you back to the other side seamlessly(as far as I remember, at least). This allowed the game to completely lack any arbitrary 'map edges' that are so common in top-down RPGs, instead mimicking modern open-world games in this respect. This is something that I plan on adding, of course. I don't think it'll be too hard to remake, but since it's such an important feature I want to make sure that I do this right.

What's New

If you've been following this blog for a while, you might have noticed that I tend to add interesting new things when I'm rewriting a project. Just as always, it's true with this project. The biggest, most interesting thing that I've been doing so far is the new animation system. This setup is designed to make adding lots of animations to characters and objects easy on the code side of things. To better explain this, let me walk you through the process of adding animations to a character.

1. First, the artist produces spritesheets for each of a character's animations, in each direction that they can face. For the uninitiated, a sprite is a 2D image-based representation of an object in a game. In a game like Pacman, Pacman's sprite would be the iconic little yellow pizza-like thing that represents him. A spritesheet is an image containing each frame of a sprite's animation(s), usually side-by-side. In Halberd, each spritesheet contains exactly one animation, but it has 1, 4, or 8 versions for each direction the object might face. More on that later.

   

   A spritesheet of AMAZE's explosion animation

   

   The resulting animation

2. A 'spriteset' file is created, with parameters for each animation(things like the name, speed, and whether or not it loops). Note that spriteset is just internal jargon referring to a collection of these animations, I don't know of any widely-used terms for this. In-game, the spriteset's animations are collected into a texture atlas. The latter concept is complicated enough to warrant its' own post, so I'll leave it as an exercise to look the term up.
3. Because each animation in the spriteset file has a name attached, a scripter can make an object play any animation from its' spriteset, just by giving a name. That alone is incredibly powerful, since we can just some thing like 'animation("attack")' in a script to make a character swing their sword, then return to a neutral posture when done. That isn't even the best part though...
4. Remember when I mentioned that each spritesheet has a version of their animation for multiple directions? That means that you don't need an "attack_north", "attack_south", etc. to make a character animate in different directions. The directions are a part of the animation, and the game tracks every object's direction, so you can use the same animation script call no matter where a character is looking at. My hope is that having a system like this will make creating dynamic and expressive characters a breeze. With any luck, I'd like to see characters that can laugh shrug, point, or just sit down on a nearby bench during a conversation when I make my game. I've seen enough RPGs where characters just stand still or walk around, and do absolutely nothing else, regardless of their supposed reaction to what you say, and I'd love to see that change.

As you can see, the process is quite simple. Just draw an animation, toss it in a spriteset, and you're done. I'm hoping to continue improving this system further, to make it easier and easier to give characters lots of actions.

Closing

As I mentioned in my last post, I have my last month before college starts again free. In that time, I'm also hoping to complete Akradion and a 1 game a month game, I can't guarantee they'll both happen, but that's still my goal. As for this project, I mostly want to finish up a couple of basic things, clean the code up, and get it up on Github. Once that's done I'll be taking a break from it for a couple of weeks, then getting back to it once I begin gearing up for AMAZE 2. My last post just made me much busier, but I feel like I'm getting a lot done so it's definitely worth it!

General Update: Not Dead, Just Forgetful

I've been quite busy working on projects this past month, but you wouldn't know it from looking at this blog.

About 2 weeks after my last post, I made a 1000+ word update post for Halberd and promptly forgot to publish it. After that, I started remaking Akradion and totally forgot to even write any posts! I'll be posting the Halberd update(with a disclamer indicating its age), but I felt the need to put together a general update post now. This is a pretty good time to do it, since it has been about a month since the big post, and a few deadlines have passed.

The Goal, and the Results

The goal for the rest of this summer was to work on 3 things: Akradion, Halberd, and a One Game a Month entry. I wanted the OGaM entry and Akradion to be finished by now, and Halberd to have caught up with it's previous incarnation, possibly with a demo.

That was a pretty tall order, and I certainly didn't complete all of that, but I don't think I did too poorly either. I've made a decent bit of progress on Halberd, and most of the time lost comes down to figuring out and implementing things that the last version had simply left out. It's a little like finding an old todo list and realizing that half the entries still need to be finished.

As for Akradion, I actually did finish it before the start of the semester, but I don't want to release it just yet. I haven't had a chance to test out the Windows version on any actual machines running Windows, so I can't guarantee that it'll even run! It seems fine from testing it under Linux, but I still want to ensure that it works in its natural environment.

Coming Up

Obviously, I need to make a few posts. First, I'll be posting the old Halberd update shortly. Afterwards, I'll see if I can put together another update post for the project. Once I've finished testing Akradion, the game will be going up here as well. With any luck, I'll get a chance to run the testing next week, so you can probably expect it around next Friday. I also need to make one more post, specifically about school, but I think I'll leave that one to explain itself.