It’s Been Busy

Another case of title = TL;DR, because I haven’t posted an update in about a month now. I won’t lie, at this point there’s just so much that I can’t cover all the intricacies, but I’ll cover the big stuff that I’ve been working on.

First and foremost, Save/Load has been my child for the last 3 weeks, and I’ve been repeating the same thing since I started it, “Saving and Loading is criminally underrated in games.” It is so much more complex than it seems. It seems like it would be as simple as just saving entire objects that you want, which would save all the variables about them – and that might be true for engines other than Unreal. But in Unreal, you need to save the variables of objects, which means you need references to those objects, and references, as it turns out, can go awry very easily very fast, especially when the entire purpose of those references is to change around (gateways on hooks do not stay on the same hook all game). Long bit short, it’s been a hassle, and I’m still bugfixing it even now into week 4. Luckily it’s mostly done, just minor kinks.

And uh, wow. I’m at this moment looking over my tasks for the past few weeks and it’s mostly just been saving and loading. It has consumed that much of my time.

Much of the other things I did was just bug fixing of previous systems. The ladders now glide a tad smoother, the menus have been slowly updated to support saving and loading, and the foyer (Have I mentioned we have a foyer? It’s this central hub area of the game that is Tucker’s pièce de résistance – it’s gorgeous) now has narrative playback so you can revisit all the audio you might’ve forgotten.

The big things are finally changing and settling into play in this next week. We’re looking at massive optimization changes, options for graphics, FOV, and other player/hardware goodies, and putting together a trailer for our game (which isn’t my doing, but I will be doing a bit of the dialogue).

In short, a lot has changed in the past month that I haven’t posted, and it’s the culmination of all 8 of us pouring ourselves into this. It’s really coming together, and I’m excited.

As always, until next time.

Advertisements

Mechanics, Vol. 2

Another week, another step closer to ending college. Getting a little short now, isn’t it?

We’re almost done with implementing mechanics. The final bit will be this upcoming week (ignoring bugfixes that will permeate until the end of time).

Last week was also midterm, so I’ll briefly mention the paperwork I had to get done, which involved updating our Technical Specification Document and a Software/Hardware Spec List.

The big mechanic of the week was Linked Paintings, which are super straightforward. They connect one painting to another across any distance, bypassing hook-connectivity requirements. Within each painting, if they are designated as linked, is a door that acts as an interactive object that the player can use to swap between the two paintings.

The other minor mechanics of the week that I worked toward finishing up were the other interactive objects in paintings working with the new paintings we have. Segueing off that, we now have the Study (which included the ladder seen last week), which only goes up (the paintings are referred to as our directional paintings, each one only travelling in one direction, with the interactive objects possibly changing that); the Forge, which goes right and contains our new interactive object, the Bellows; the Attic, which only goes down; and the Alleyway, which only goes left.

I added in cannon interactions which opened up addition paths in some of the above paintings, and the bellows in the Forge painting acts in a similar manner to the cannon, opening up paths from the right hand side, where the cannon acts affects the left area of paintings.

We also have a new Cave painting, that begins with no connections, but can open up in three directions, affectable by the cannon, well, and bellows.

Anywho, we’re close to finishing off mechanics, which means we’ll be able to polish and optimize, and that’s some exciting potential. Until then.

Mechanics Rush

Spurned on by the idea that we can leave the entire last 4-5 weeks to entirely just polishing/putting out content for the game, we’ve designated our direction for the next two weeks to be mechanical completeness.

With that in mind, I was able to (on top of the standard bugfixing and meetings), really only able to focus on two important mechanics, the interactive ladder and chest.

As it turns out, the chest was the simpler of the two, by far. It functions almost identically to the way our current door works, with the exception that the chest in the real world has no bottom, and allows the player to drop down through it. The difference was that functionally I had to show that, and thus there is a little bit of a camera lerp to showcase that. Because there are only two features, and they’re both very visual, I figure this week I’ll include gifs to elaborate my progress (One day I’ll have gifs that aren’t god awful quality).

OpenChest

The ladder, on the other hand, was far more complex than anticipated. I already made the mistake of lowballing the time, but I ended up going from lowballing to completely just misjudging how long it would take. The ladder ended up taking the majority of the week, but overall it turned out pretty well. Few minor kinks keep showing up, but for now they don’t affect performance, so it’ll have to be left for polish-stage (which I think I’m tentatively calling Alpha?).

MoveLadder

Anyway, those were the major bits of what I got done last week, and we’re going to keep advancing with getting the rest of the mechanics in. Until then.

Saving Is More Complicated Than It Seems

This week was adroitly summarized by the title. As it turns out, saving your game is more complicated than it seems in Unreal, which if I may delve into high level terminology, (high level as in easier to understand, not high level as in harder to understand, there’s a weird difference between the two uses when it comes to general speech and programming speech) you can’t seem to store actors into the Unreal save construct and then take those references and load them back into the same actors.

In my circumstance, I wanted to move a gateway, save the actor, and then when loading have that gateway actor update itself to the save state version, copying all the variables (specifically the location vector in this one). But it turns out that just doesn’t work.

I have a workaround that involves giving all the objects in the scene IDs, and then I save those IDs and have the gateway IDs reference the hook IDs and have them swap, and it works. I’ll have to expand it as we expand our game, so more variables get saved. We’ll see how that goes.

Other more minor things I did this week involve putting in a new font for the game, fixing the shake when the painting character lands so players don’t get migraines, removing the checkpoint system – which is just outdated at this point – from the menu, fixing the bug that caused the game to fatally crash when you returned to the menu (it sounds a lot worse than it was, there’s very little need to go back to the menu right now, so it was mostly something players found when they went to quit), and as always, the various bugfixes.

We’ve only got 2 weeks until Spring Break, which isn’t really a milestone or anything important, but it is a date we can anchor progress around, and I believe 5 weeks after that, so we’ve decided to focus our next 2 weeks on getting everything mechanically in that isn’t in yet.

Expect new in painting objects the Chest and Ladder, as well as Linked paintings, and possibly Bursted paintings in the next week. You’ll find out what those are then. Until then.

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.

DesignerTool

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.

Sojourn

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.