4 Hugues Ross - Blog
Hugues Ross

9/13/15

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.

9/8/15

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!

9/6/15

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.