Physics is a Blocker, And It Has Nothing To Do With Capstone

So I spent a large portion of my time this week coding for my Game Physics class, which pulled me away from doing Capstone.

The upside is that I have many tasks on my log for this week to make up for that, and the downside is that last week’s attempts at QA were a bit of a dumpster fire.

A lot of it had to do with pushing things to the last moments before QA, so that definitely won’t be happening again.

Anywho, had Greenlight this week, which is basically just a shorthand for, “Have all your documents in.” I updated our Technical Specification Document.

Only two big features this week (and a slew of minor bugfixes related around them but nothing unusual).

The first was Voice Over Implementation, which was expanding our narrative and allowing our narrative designer, Sarah, to put in dialogue audio and subtitles. We broke it up in sections of story, with a story for each painting type. The idea is aimed at telling segments of a story at a time, room by room. So the Forest painting has a narrative, the Snow has a narrative, etc., and each gets doled out in bite sized chunks until the player reaches the end of the game. The stories will be divvied up properly so each full story appears approximately by the end of the game.

The second big feature was an improved design tool for level building. We already have the room tool, which generates an X by Y by Z room, made by Brandon, our other programmer. My tool allows for the creation of a hook-gateway-painting chain when clicking a wall.


The designer can choose the types of hook, gateway, and painting, and the chain of them will appear in the correct spot on the wall.

I’ve got a bunch of tasks planned for next week, so until then.


The Weekly Capstone Update

Titling titles can be hard. Or you can really just not try and yet somehow you still get a title, it’s just that simple.

This week (or was it last week by now?) I had some work to get done in other classes, so I wasn’t able to do as much as I normally do, but it all seems a little relative. Either way, the game is still improving bit by bit. We almost have a new set of levels in the game! Which is exciting because we’ve had the same six levels since like, October.

I made a Discord bot for our channel. Very boring, just does posts a daily update to remind everyone to post hours, but always kind of fun making tools that see real use.

I improved the Audio Manager, so it now has a soundscape, which is what we’re calling our background effect track. We only have the soundscape for the forest so far, which has bird sounds and other woodsy noises, but its nonetheless more background sound that didn’t exist prior.

I also upped the Audio Manager to swap music tracks at a percentage of the time the track is played, so people don’t want to rip their hair out hearing the same opening 10 seconds to every track. Hopefully it’ll help with the frustration aspect that is the natural byproduct of being a puzzle game.

Last major thing I did was begin the designer room tools. Right now it just automatically creates a painting after you’ve placed a gateway, but next week’s goal is to improve it even further so they’ll only need to click on a wall and then it’ll spawn the entire hook, gateway, and painting chain, with appropriate settings for all.

And of course there were a slew of minor bugs and organizational fixes that always consume chunk of my time. No major bugs fortunately, game continues to run without breaking down. Although that reminds me that we need to fix the menu/level/checkpoint systems which absolutely broke down when we switched to level streaming. Game is still playable, but going back to the main menu or using checkpoints is a bust.

Goals for the future perhaps. Soon we’ll have new art and new levels, and it’ll be real exciting. Until next week.

Capstone Begins Again

Little late, and technically it’s called Senior Production now, but either way in the end it is still developing Sojourn further.

Thinking back to last semester’s blog posts, especially toward the end, I felt like I was saying very little. It’s not very pretty, but I prefer the more text heavy pictures less post style. I’ll still cover what I did, but maybe I can be more clear in why we’re taking the direction we are, and what the strides I’ve taken are.

Two weeks have gone by already, so allow me to catch you up on what I’ve done so far.

First things first, week one was all about level streaming. Before level streaming, the entire level was loaded all the time, and it really slows down weaker computers. Honestly it even slowed down powerful computers. It was bad. But with level streaming, we can load and unload various bits of the levels as the player travels through them. Much more efficient.

That subsumed most of my first week. I’m also running QA this semester, so that’s always a fun time getting feedback on the game.

The second week, the one that just concluded, involved a more spread out choice of objectives. First, I made room timers for QA feedback. That allowed us to get an accurate read on how long each puzzle takes, and how long the game takes. The room timers were the major feature of the week.

Minor features of the second week were multiple, including a fix to the reticle system (buttery smooth), a bugfix to the tree in the forest painting after it gets knocked down by the cannon, a scalar shaking amount for the in-painting character’s jumps, a more viewable glowing of interactable objects, and increasing the ability to jump around on the splatter painting. A lot of feel-good changes.

It’s not important what exactly all those features are. What is important is that I was able to fix a lot of small issues that work toward a better player/designer experience.

All in all, a slow start to the semester, but we have an entire narrative AND art overhaul, so we’re deciding on that and waiting for them to be created, so programmatically, we’re mostly just creating the backend design features that make it easier for them to do their jobs.

Until next week.

The Beginning of the Console Foray

Another semester, another class. It’s been some time since I’ve last written a blog post. I’ll be writing one again at the end of the week for an update to Sojourn, along with hopefully a new style that’s more engaging for readers, but also is less monotonous on myself to write.

With that quick intro out of the way, let me give the rundown of what Console is all about. Not surprisingly, Console Programming is just that – programming for consoles: Xbox, Playstation, Nintendo, or mobile, as the qualifications for this assignment generally fall into anything that’s not a PC game or application, although plugins that relate to consoles for Unreal or Unity count.

Above the console bit though is the fact that this is mainly a portfolio class. It’s going to be very self driven, so I’m hoping that once I begin work I’ll get swept away and really pulled into it.

It’s funny, I look at the development of my favorite games, and one thing they all have in common is that the time they all took to even get to the publishing stage tends to be 3+ years. It makes working on these short 4-5 month projects feel very constricting.

I know that a lot can be done in that time, and strong game concepts have been done in weekends, but even for Sojourn, which will have approximately 9 months of development, it still feels like a situation of “if only we had more time.”

I guess that’s my precursor for “I’m gonna do this thing but I don’t know if it’ll come out how I want because time is limited.”

That said, the aim is to make a single player roguelike wherein you play as an entire planet. The main focus of the game will be resource management, whether that be preventing the multiple governments of your planet from infighting, stopping the ecosystem from being torn apart, or defending your atmosphere against natural disasters from space.

There are a lot of avenues to take this. To satisfy the programming area, I’ll work on making it procedurally generated, but my main goal with this project is to showcase my ability to design within limited design space.

Ideally, the benefits to the development of this game will be in the adaptability of the expansionism of game content. That is, if after 3 systems (ex. Management of Governments, Atmosphere, and Oxygen supply), the game is still too simple, I can add more systems. If I reach a point where the players are managing a lot, I can move to either remove systems or balance further. And on top of it, all of the systems need to be coded, so I’ll be busy determining how exactly I want it all to work.

As stands, a lot of a it is very loose in plan right now. I hope to have a more solid plan soon. More to come in this area… eventually. Capstone at the end of the week, stay tuned.

Capstone: The Aftermath

I kinda disappeared after the last post. I meant to post more, I did, but it all got so hectic. Honestly, I wasn’t even aware we had to do a postmortem, so here I am, late as all hell, but hopefully it counts for something, and to anyone reading that might be curious, it gives some closure to the semester and what we’ll see going into the next.

I don’t quite know if there’s anything particularly expected out of it, so I’ll just cover what I know from my end.

First and foremost, our game went through. There were 23 teams, 18 of which presented, 16 of which demo’d (demo night was where teams that chose to show off their games actually showed them off, presentation night was just a final pitch to the faculty and other students; 2 of the teams that presented wished to show their progress but not attempt to go through), and 11 of which went through.

If you’re tracking other blogs, the 11 that went through are:

  • Breakout Brew
  • Dawn of the Celestialpod
  • Forsaken Fish Fighters
  • Frog Snatchers
  • Keeper
  • Lucha Megadrive
  • Nautical Nonsense
  • Protocol Aurora
  • Re[mod]
  • Sojourn (That’s us!)
  • Toybox Shooter

We were incredibly happy to have made it through. A premature thanks to my entire team: Matt Makuch, Tucker Cole, Mike Andreula, and Ren Golis who were all so instrumental towards making this game to the state it is.

The following week was then scrambling to find people for our team. I won’t sugarcoat this post, it’s been me just free flowing my thoughts, and I’m going to keep it that way. We had a really tough time finding people who wanted to work on our game.

We had a lot of people who liked to PLAY our game, but not work on it. I’ve had time to think about why. I figure that it’s because a) it’s a puzzle game, which scares designers, and b) it’s not terribly exciting. It’s a slow paced thinking game, with design heavy work, and a lot of art assets required (to fill out the real world).

Long story short, we had a conflict with Protocol Aurora over a member. That led to a hectic weekend. But we solved it. They have 3 excellent level designers who are going to assist us making levels. It’s a joint venture in some regards, and certainly risky, but I feel confident going into it, it’s going to help both teams.

Finally, we figured out our new team. We went from 4 official team members (I say official because Ren is not “technically” on our team) to 8. We added 2 new designers, Sarah Weber and Joey Zika, as well as Amanda Ledwidge, our new artist, and Brandon Cote, my programming partner in crime.

We have a lot of big plans for Sojourn in the upcoming semester, including an art overhaul, expansion of systems and levels, and tentative plans for publishing. It’s gonna be a longer journey than the one we just took, because at least this time we’re starting with a project in mind, instead of choosing it by week 5.

I guess this was kind of a “looking forward,” but I think that’s alright.

Last thing to do is let you try Sojourn out for yourself. From everyone on Tierceron, we hope you enjoy.

But fair warning, it’s not too well optimized, so slower computers may experience some bugs. Gotta make some sacrifices with small amounts of time.


The Tank Battler: The Wrap Up

Results are… varied. And by varied, I mean, well… let me explain the project further.

First off, it was overscoped. Not anyone’s fault honestly, it was a really cool idea, have a variety of players with a team of tanks to drive around and fight each other. But it took second priority to capstone (the student who programmed it was on one of the capstone teams, so he had trouble finding all the time to do both I’m sure), and didn’t have a designer looking over it.

We’ve been told this project will take a hiatus for a year, and may just get scrapped altogether, or get moved to Unity, which would fix a lot of the technical issues and make it easier on us developers.

That said, results came back varied because of a number of the above issues, mainly with people’s DLLs hitting breakpoints or otherwise not working, and the fact that with just a few people actually able to play, it was difficult to determine an exact winner (on top of a scoring system few of us paid attention to at all).

I didn’t go overboard on mine. It does well for what I made it do, which was mainly pathfind around. It moves around the map at random coordinates, mainly with the intention of getting away from the others. The idea being that if I could stall the match out, back myself into a corner, I might be able to take them down before they take me down.

I kind of wish I had gone more into it, but between the system problems (the unit circle was backwards and it was so so awful to work with, but that is apparently just part of SDL (which in itself baffles me)) and capstone, my drive for this final project was lower than it normally is.

Looking back at the semester, I’m still super happy with how minesweeper turned out, and I think my Gin Rummy did better than what it “scored,” so overall, on the two more structured projects, I did fairly well.

I think the class can only get better, and because our professor is really good at listening to feedback (both for this class, but he’s also the head of the game programming division, so hopefully the feedback we gave will actually change the curriculum as a whole for the better down the line), I think it turned out alright.

Our entire class has just kind of been a step behind in it’s own right. We learned flash, which got phased out for Unity the literal semester after us, and we had an entire class on XNA, which I doubt I’ll ever touch again, but in the end we’ve still put out some of the best work this college has seen to date. This should probably go in my postmortem for capstone, but I’ll put it there as well.

I guess to wrap up, all in all, it went well. Little bumpy at the end, but a good semester. And when it comes down to it, I don’t actually mind being a guinea pig, as long as the future will get better for it.

Guess Who’s Been Busy

That’s right, it’s me. Capstone has been very taxing on my time, leading to a backup in blog posts.

Quite honestly my preferred method of blogging would just be to update you on everything we’ve done in a style more fitting of “Here is our game as of now, there are many changes,” but I’ve got to have a certain number of blog posts for the class. As such, I’m just gonna keep doing what I’ve been doing, but with updates for each week that we’ve done so far.

That said, week 10, wherein I:

  • Culled NPCs
  • Added a sound manager
  • Allowed vertical movement (for our ship painting, you can climb on the nets to go up)
  • Added functionality for a variety of painting interactions, using the cannon present in the ship painting and the well in the farm painting.
  • And yet more bugfixing

It was on the lighter week, and unfortunately because of how much more work needs to be done this week (presentations on Monday), I’m not going to do pictures.

It’ll be a little dry and boring, but there are more pressing matters to attend to.

So I culled NPCs, which basically means there’s an NPC system set up. For our game, it’s simplistic, we don’t have many NPCs, but if the forest painting has the potential for an NPC, he only appears in designated paintings, thus preventing every forest painting from having an NPC.

Nothing terribly exciting about the sound manager, that was just my first attempts at putting a wrapper on Unreal’s sound system to make it a bit more designer friendly and centralized. Has a play sound function, real fascinating stuff.

The vertical movement was the first iteration of allowing our player to travel up and down. It involved a lot of switches to gravity and movement before I decided on using Unreal’s character movement modes, and just setting the character to flying. Later we created a space painting that utilizes this mode.

Now the painting interaction functionality was the big one for that week, and core to the game. To properly have it so puzzles weren’t just used to travel between each other, we had to have the meta puzzle of the room, and then mini puzzles that you use to solve a larger puzzle. So the cannon interacts with all the different paintings – blowing open new passageways in the farm and snow paintings, tilting an adjacent ship painting, tipping a tree in the forest painting, etc, and the well does things like puts out the campfire in the forest painting, creates an ice block in the snow painting, and recursively triggers wells below it.

There’ll be more updates on how the week’s have gone soon, but as of now, sleep is pretty necessary to retaining a stable headspace. Until then.

The Tank Battler, Combat: Prep

As stated in the last post, our Artificial Opponents class is wrapping up with an in house tank battler.

We already completed the movement part of that (kind of). Honestly, Capstone’s been eating away at most of our times (“our” being the collective class, including myself), so the quality of my movement AI and others was significantly weaker than it would’ve normally been.

Luckily (or unluckily, depending if our Capstone game makes it through), the final presentation is next week, so we’ll have more time to work on Artificial Opponents as Capstone moves to the backburner for the end of the semester.

As for the actual tank game, and plans – well, the first step is to fix the movement and actually get it working properly. That’ll be critical.

For the combat section, I figure I’ll be casting map-wide lines to check for friendly/enemy tanks in front of me. Fire if enemy, don’t fire otherwise.

I was imagining I’d have all 4 tanks line up in a diamond-square formation and just rotate as a massive supertank, covering all four 90 degree directions, that way the time to rotate in a circle is automatically cut by a quarter. It’s a big demand, I don’t know if I’ll be able to do that, especially if two tanks at different angles demand my attention, and I need to break them out of their supertank formation, destroy their enemies, then reform and continue moving.

I haven’t yet decided if this strategy will be best for attack or defense, but that will depend on how the scoring system is determined. If it’s best to go out, destroy tanks, pick up cash and spend it for better parts, I’ll go for that loop. If sitting in a corner and killing anyone who gets near using a spider-like supertank works best, I’ll go for that.

Only time will tell really, but for now, it’s all coming up Capstone, gotta get back to that. Until next post.

The Tank Battler, Movement: Prep

The final project for this semester’s Artifical Opponents class is a custom-made tank battler, wherein you control 4 tanks all at once and attempt to take out 3 other teams of tanks on the map (for a total of 16 roaming tanks).

For the first part, we have been tasked with getting the tanks to move. This ends up being more complicated than it sounds because the tanks don’t move on a standard “I want to go from position A to position B,” where you just follow the path. Instead, the tanks move using two treads, which each have a power level that you alter.

To turn with the tank requires uneven amounts of power, but either way, that will take experimental time to basically nail down how much power is required in each tread to get it to move as I want.

The plan as stands is to use A* for pathfinding. It’s a popular, strong, and simple pathfinding algorithm to use, and because the tank battler as a whole also has things like shooting and buying equipment, I don’t want to get bogged down in just the movement system. For this first part, movement is all that is necessary.

As for determining treads, I figure I’ll create a function that takes in the degree that the tank wants to turn, and from there factor that into two workable power tread levels, for a period of time. To turn 90 degrees to the right, I’d want to power the left tread forward at full and the right tread backward at half. Or so I think.

As of now I don’t see a reason to not make turning as fast as possible. If I can mange to spin my tanks 180 degrees in a quarter of a second, I would imagine that gives me a tactical advantage than doing it over 2 seconds. But if I manage to do that, others will too, so it might determine how I create AI later, when shooting and inventory come into play.

Anyhow, next up is to actually create it. See you in the report post.

Make It Snappy

A lot of work was done this week, and it was a bit of gameplay, a bit of feedback, and we have so much more to do to fully flesh it out, but I’m feelin’ good after this week.

Let’s hit the checklist of what got done:

  • Implemented a walking character animation
  • Gave the gateway on the loose hook a swing “animation”
  • Gave the gateway falling off a loose hook a full camera transition, including screenshake
  • Added a raycast blocking wall for puzzle design
  • Implemented a top tier Programmer Art™ pause menu complete with two entire buttons (very advanced)
  • Added a transition upon activating a real world connected interactive object within a painting
  • Added bidirectional asset attachment for design ease
  • And a lot of bugfixes (which I won’t cover because they don’t exist anymore, which is good)

And now for the visual part!

Walking character animation


Gateway Swinging


Gateway Falling Transition


Raycast Blocker (The painting on your side of the gate is accessible, but painting through the gate is not)


Pause Menu


Interactive Object


And the bidirectional asset attachment is nothing fancy. It’s basically that when a gateway is assigned to a hook, the hook is assigned back to the gateway. It cuts out the time the designer has to hunt through the objects and set them all to each other, and instead only has to set one object.

There’s a lot more getting done every week, and next week will have even more. Until then.