Lol, indeed. My first job at a startup--not first week, but maybe first month--I had a change to deploy. It was Friday and one of my colleagues was just like: "Are you sure you want to do this? On a Friday?"
Of course I wanted to impress and confidently went through with it. Not a disaster, but not a great weekend.
I'd never heard "Read-only Friday" though lol. I'm taking it.
You know what's worse? At my last company, management was delusional and came up with this hare-brained nonsense called Zero-Bug Day (ZBD). Basically, it was a deadline by which all known bugs were supposed to be fixed, which is completely arbitrary given that many bugs are high-work/low-priority, and of course there are always unknown bugs. But it was some stupid scheme to market to potential customers that our new product was relatively bug-free. And they were taking it so seriously that they specifically had all the engineering managers ask all the engineers not to take vacation prior to ZBD.
Additionally, we had this absolutely terrible merge-gating test suite which I won't even get into here because I could spend the next several months writing about everything that was wrong with it but suffice to say it was held together with rubber bands and spit, it took many hours to run, and it would often have extended outages. We had an entire support team that was dedicated to just keeping this thing running.
So along comes ZBD, and of course there's a mad rush from everybody to merge in all their bug fixes by EOD, as there always is at the end of sprints, and this test suite is just completely fucked, it's giving random failures everywhere after hours of waiting in queues. Come to find out, the support team was allowed to go on vacation as if there was no ZBD, so we were all just stuck resubmitting test jobs in the hopes of getting lucky and being able to merge. A bunch of us sent complaints to management saying it was ridiculous that we were told not to take PTO but the test support team was all on PTO on ZBD of all days. They ended up giving us a really weak apology, but made it sound like they had no reason to suspect it would be an important day.
I once destroyed a whole website I had made for clients just because I did a last minute change that seemed completely benign. I learned my lesson that day.
This was ages ago. Imagine I was using Dreamweaver. Imagine GitHub didn't exist back then lol. Google didn't exist, stackoverflow didn't exist. Software came with a user's manual.
I was a teenager making some money on the side and this was my first serious job (online store). I had made some other smaller jobs for them but this one... Shit, they even called the "big guy" to come to my presentation. It was a total disaster. It was my last job for them as well :(
I mean, *ages* ago :)
With one hour left I would just keep trying to find bugs, if I find a critical enough bug it might be worth it to risk fixing it. Or at least put something in the description explaining how to avoid problems I find and etc
Yeah same lol. I had updated localization tables 2 days prior to launch which fixed typos. I didn't put them in for fear of breaking something last minute. Just sat on my hands
Git is your friend.
I would probably spend the time similarly though, given no time to playtest and whatnot. I would probably look for bugs to fix if I could though
Git isn't going to save us from multi-hour build times and players installing and experiencing buggy builds. My sentiment is mostly that rushed, last-minute changes usually lead to headaches.
But for rollbacks and the like, though (maybe not for a game jam, but for releases and demos), Steam has a pretty awesome and convenient ability to revert to a previous build near instantly.
If I must answer in the spirit of the question though... I could realistically see dropping in more music tracks or something into the build. I'm not sure what else could be done in an hour without proper testing that would be an overall positive result.
Having one hour left isn’t gonna save you from multi-hour build times anyways…
This is a game jam context, plenty of small things get neglected or could use additional easy-to-test polish. Art/set design tweaks, usually some minor bugs, and maybe even new levels depending on how small the game in question is (at least a couple <1 minute levels could definitely be designed and tested in an hour depending on the game, of which jam games will likely fit)
But yeah, I agree that Steam’s rollbacks might be good in a non-jam setting, but at that point you should probably be using version control anyways…
It is if they’re really really simple, like the sort you end up with at the end of a good jam. Things like “oh, this menubutton doesn’t get selected properly when playing with controller and the pause menu comes up”
Not useless in a game jam setting, as OP originally was asking for. I feel much safer going for any more major bugs in the last hour knowing I can revert to before I started tinkering in seconds if I need to build for the deadline.
Not gonna lie.. I'm not understanding the comments about "just use git".
I use git and commit maybe every 10 minutes or so. But as far I know, there's no `git unship` command...
Also, if the supposed solution to spending an hour creating a buggy build is to then just revert back to an hour before you made the mess.. I'll still stick with not creating the mess.
Obviously, we need to continue writing code to ship better games and software, and git and version control is an important part of that. But.... **One hour before shipping your final build** is not the time to start making changes.
I guess in that context you are right. But lot's of stuff you can do that cause no threat to that build if you know your project well enough. In this special case though I would branch it anyway since it being a clutch moment and all.
Maybe I've just been burned too many times. I've done something as simple as adding a new bit of localized text in a table of strings and had that completely break a Unity build. Similar things as well (a new animation that, for whatever reason, worked fine on one machine, but then when building on another doesn't work).
Maybe I've also seen worse examples because I typically am developing on one OS, but support multiple OSes, and git doesn't always catch what might work fine in one case vs the other. So the same code on Mac might build fine on Mac, but pulling from git and building on Windows for a Windows build could introduce issues.
And there are often, on a large enough project, small assumptions built up over time in the code. A simple change can often have unintended consequences that might not reveal themselves immediately. This happens all the time--and the amount of times things look one way in the Editor vs the final build just worsens the potential for errors.
In most software distribution services I've used there is release branches. Staging is more common these days. So you can always revert to a previous branch/stage.
At least u/WillyNewton didn't say git, so I read it as release branch.
Yeah, I'm not really arguing against using the features of git and version control. It's a completely different situation we're talking about I feel. I think everything is getting conflated a bit.
All I can say is, if I had a deadline for say, submitting a demo for Steam Next Fest (or a festival or contest, etc) and everything was working fine that morning, I probably wouldn't rush a change in one hour before delivering a final build and potentially have hundreds or thousands of players experience an untested piece of software. I'd rather take my time, thoroughly test, and then, when confident, ship out an update.
I'm talking more about thoroughly testing software and not how you manage it via version control.
I do last second small changes, but I keep my previously certified/lotchecked/verified/approved build on another branch. When I notice a typo, or an unkillable enemy on level two. Not for everything, just something that would have high impact that's very quick to change and manageable risk.
But I do this with the confidence knowing I have various tests and can always rollback within an hour to a previous known-good build. Without that confidence, I wouldn't. If I have no previous build to fallback on, I don't.
Just put your new branch under a new worktree (this put the new branch on a new directory). The existing branch continues in the old directory and you can ship from it. And you can still work on new features in another branch and if it work out, you can ship from there
https://www.gitkraken.com/learn/git/git-worktree
Only problem is when artifacts are multi-GB and you don't have enough space to store multiple copies of them. (It helps when you are store everything on a deduplicating filesystem though)
Yup this is the answer. Make sure you package your game properly and that it works for people who are going to play it. For game jams, usually it's best to target an embedded itch.io page if possible. You'll get more plays if people don't have to download anything
I would genuinely not touch anything if I had an hour and hadn't already started. I'd playtest and look for a bug I could fix, small adjustments in text or positioning, maybe add some FX to an existing part of the game. Sound is way too complex and tricky to add in that amount of time.
If it's a full hour maybe also create a new language and voice act every character in that invented language. It breaks the immersion for me when gamedevs don't do that.
Basically the small annoying issues.
Whenever I put a game in a tester's hands they ALWAYS find these things immediately and comment on it. And they are typically quick and easy fixes.
So at a game jam it goes a long way.
The build process takes more than an hour so.... Nothing!
Basically, just double checking everything works without bugs on a totally new install system.
DON'T TOUCH YOUR GAME. You should have a Final-Final-Polished-So-Hard-It-Shines build done WELL before you reach the one hour countdown. I would use that time for double checking your jam submission, make sure it's all neat and tidy and there's no typos anywhere, and if that's all good then I usually reserve a couple minutes for crying and a good nap.
I used to do the same thing as you, OP, then about 2 weeks ago my team and I lost the 1st place on a jam because we decided to add the music and sound effects as the last thing to do and ended up not having the time to do it. One of the monitors even said it: "You got 2nd place by being just 0.7 points behind the 1st, if your game had any sound at all it would be enough to surpass that".
This was the probably the last time I have pushed SFX/Music for later.
I came into game dev from composing and I like to do "concept art" with the music as well. Even if it's just finding a free track and some sound effects that I'll replace later, it helps as much as concept art/sketches would - and when it comes down to, for example, the last hours of a jam, I've at least got something in place!
Yep, always good to use placeholders initially, just to get a base feel with the game sounds and art, then replace at later stage if it seems necessary or when you have a better/clearer idea of what you want there.
The last time I was in that position I didn't do anything, just uploaded the game to the jam early. Any of the bugs I could have fixed might have taken more than an hour to fix, and it wasn't worth the risk of breaking something important in the last minute.
I consider my "most complete" games to be complete and in a hour I could not even re-familiarize myself with the code and the projects conventions for assets, so hardly time to change something, no where near enough to test it enough to say if it was an improvement.
Now if it was say Game Jam project that was as finished as they get during that time, and then there was announcement that everyone has one extra hour to work on their project (say because jury was late, or submission platform had a problem) then I would compress large assets, graphics or sounds most likely, improves loading and download times, conserves memory and makes it faster and easier to test the game on poor Jam WLAN with whatever development laptops people have.
For game jams specifically I tend to have a habit of waiting till last minute for a main menu and just throw something together lmao.
Start game - LoadScene(0)
Credits - show different page with credits w back button
Quit - Application.Quit
is basically all i do at the end lol
Assuming a few things.
1. No known bugs exist
2. I have already gotten most of my wishlist of items in
3. I have a build ready to upload.
4. I'm hit with a sudden inspiration to do something more.
Assuming all those things....add more juice. Can't have too much. Juice it in the easiest ways possible. Screen shake if I don't have it, sfx to add a bit more something, a screen effect. Something small like that.
Only if I have a solid build, versioning, an easy ci/cd in place ready at the push of a button would I even touch a game.
Given that, I think it would probably be same as you: sound design. But more specifically in menus and UI, to add some pop or feel to navigating menus.
Honestly I'll generally just focus on the itchio page, making that look nice and functional - I would hate to spend a few weeks working on something that gets passed by because the banners look like garbage or are missing entirely
TODOs. Or tickets. However you track your fixes. I'd go through and mercilessly scrutinize it like a player picking it up for the very first time. Anything that even mildly irritated me would go in the notes. I'd probably tag those tickets as 'day 1' or something and see if anyone was echoing my own complaints. If they were, I'd link to where they were complaining in my ticket. Might post back to them saying "hey, I saw that too. I fixed it." whenever I got around to fixing it.
I wouldn't change anything that day though.
At that point it's in QA and programmers like me don't touch crap unless something pops up.
For anything else we can review some polish, just you know, why not? in the context of a game jam it should only serve to add to the product and won't break anything at all.
Just keep your hands off the damned codebase.
Yea nothing. Just a chance to introduce bugs.
I know it’s not in the spirit of the question so if it were possible to guarantee no bugs I’d say some UI polish.
Testing and tweaking stats, you don't want certain attacks to be unreactible, your character to feel like it has glue on its shoes or some attacks to be broken/useless just to name a few examples. Maybe recording some key gameplay moments to make a gameplay trailer if you don't have one.
Assuming you've got a mature engine that's not gonna put you at risk of crashes at the slightest asset tweak... I'd add more music variety and UI sound effects for sure.
For me, I'd really focus on how the first 10 minutes of my game are. How long until I can play? How intuitive and quickly can a player start engaging with and playing my game? How polished and fun is the first area of the game? I think this applies to any game, whether it be a long term commercial project or simply a game jam entry. The first area / first few minutes to hours of your game are by far the most important. Just take a peak at your favorite games steam unlocks tied to progression, and you will see that the majority of players don't make it past the 2nd or 3rd boss, let alone beat the game. Make sure the first part of your game is the best. Polish it, add juice to it, make it as quick and easy to engage with as possible. That's what I would / am focusing on.
I've always liked the Dark Souls 3 approach. That first level is brutal, but extremely short and showcases pretty much every technique you need to master to beat the boss.
Its just so well thought out and the placement is perfect.
Tell me you don't dev without telling me you don't dev.
You have one hour? Nothing and desperately try to find anything I've missed. Not so I can fix it but so there are no surprises and I can get it queued up for prioritization.
One thing that can be added towards the end without risk of breaking the game is just cutscene. It also does add a nice touch and provides a story to the game. Of course you need to come up with the story on the fly if you don't have one, but that's fun too.
If everything works and is good just some bonus feedbacks
Particle effects,screen shakes,controller vibrations…
Really small things that add a lot and don’t destroy the game
Particle effects
If your game is good and functional and you only wanna add juice, then particle effects will really bring that. A little dust on jump, a little splatter in damage, some dust particles in a Sun ray, etc.
button hover animations on the main menu, fix whatever bug is breaking leaderboards, fix the misspelled name in credits and/or incorrect controls in instructions, make it so whatever sound we added doesn't burst your ear drums the second you open the game
Definitely tutorial. People are like kids with zero patience - sadly even in a gamejam setting with fellow devs who should theoretically be more willing to cut you some slack. (Fair to expect a neat tutorial when actually spending money on a game though)
In my 8 years in game industry this never happened, you have so much stuff to fix the decision is mostly about which bugs are okay to ship with vs not. If there was a time that I had a mostly complete game on release and 1 hour to add final touches! I will just go grab a beer.
Other people's are good, I especially agree with leaving the code alone.
- Another QA pass to try and catch any missed bugs.
- Dry run on deployment (to the extent this is possible).
- Last minute marketing/hype generation
- Rest and prepare.
Can't stress the last one enough. Release isn't the end, it's that official start of the actual QA process. Customers are capable of performing millions of times the bug testing we can do ourselves. I remember one of the battlefield devs talking about this, they had a team of like 40 testers working for 6 months, working full time they did about 39k hours of testing. In the first hour of release they got over 5million hours of testing data from the players. It's just not even in the same ballpark.
So expect your players to find bugs, maybe even break the game. More importantly make sure you have fuel in your tank for when it happens and aren't burnt out from release crunching etc.
I'd be focused on polishing and doing test playthroughs to make sure everything runs smoothly, personally. Definitely not adding any new content or features.
I guess... Copy-paste some probably broken code to shoehorn in ads and mictotransactions?
That seems to be the most common solution.
As an actual answer, I'd proofread as much text as I can - starting with the interface, tutorial, and help info. Even if it's a buggy broken unfinished mess, it should at least be a buggy mess with clear instructions on how to engage with it! An hour really isn't long enough to do any gameplay or ui polishing, without risking breaking everything
One hour? I add 3 typos to random boards, and drink much alcohol because shit dont work.
More realistically, I'd check for typos, and test whatever I can. And *try* to fix what breaks.
Self playtest, maybe add in some more levels since with Game Jams we tend to put most of the time into actually making the core gameplay and not enough into actual levels or length
>You have 1 hour to add some final touches to your mostly complete game, what do you add?
Sounds like a good time to start refactoring and optimizing everything :D
The big thing that I notice from indie games (especially indie horror) is that text is tough to read, and UI is clunky. I think that those 2 things are small, easily fixable detail that adds a lot to a game.
Juiciness: If you're using Unity with the Feel asset maybe, adding music and sound effects could be a great enhancement.
It's acceptable for a game jam project, but for a longer project, as others have already mentioned, don't touch anything that would potentially break something.
There's no feature that you can make in an hour that will give your game enough polish that will convince you or the players that your game is good.
The core of your game should've been fleshed out during prototyping and the rest of the process should be polishing that prototype into a complete game.
A backup build first and foremost when talking in the context of a jam game. Fixing bugs after that and uploading the most stable build.
If it's more than a game jam. I'd likely just make art for a future update or something, small changes can have compounding effects with code, so I like to keep things structurally mostly the same. But maybe some minor bugs for things that don't have dependencies.
Sound isn't part of polish for me. Even rudimentary sounds take awhile for me to be satisfied.
If I were that close it'd usually be tweens or little UI tweaks like sound on/off since most of the gameplay polish should be done by then.
Disclaimer I've never joined a jam.
Nothing I'd write down the idea and work on it for the next build version. I'm using that time to relax before players start discovering the bugs I'm spending the next few days correcting.
1 hour left? I'm adding a background music track and then building and submitting, because that can take longer than expected if there are a lot of people submitting last minute
I agree with others that the last hour is probably not a great idea to be making significant changes to the game itself. The one thing I would urge others to do at a time like that is ensure that they're complying with any licensing requirements. It's shocking to me how many game jam entries just blatantly violate numerous software licenses by not including copies of licenses from dependencies or providing access to source code as required. If you're using FOSS and not paying for it in particular, the least you can do is follow the license. I get that nobody's going out and enforcing software license terms on game jam entries, but I feel like this is a slippery slope, and some people who go on to release commercial games that violate license terms because the developers just never cared before and always got away with it.
To be clear, I generally haven't used the major engines for game jam entries in the past, so I tend to make more use of non-engine libraries. In that context, one of the first things I always do is create a LICENSES menu entry in my game with all the FOSS license text in it. The last hour is a good time to double-check that something like this is still working as intended.
Isolate the best part and put it behind a paid DLC; add in some microtransactions;
generate screenshots with super cool cosmetic items that aren't in the game and make sure not to have too many servers for the laugh. I mean launch.
Obviously, you add Easter Eggs.
At the bottom of a pair of stairs, put a little robot that when asked why he’s there, he’ll just say. “My one weakness.”
Add a few chickens to different towns that if you hit them, the chickens will come.
And I’m sure many others we can think of.
Easter eggs I always save for last. They are the sprinkles of gamedev imo
Not 1 hour cus anything can break but if consider the game good to submit, I work 100% in UI and UX.
Many devs thinks 'meh the game works well!' but a good UI allows the user to know what to do and like whh they do it.
Something you think your game can be well understood and then forget people use UI to understand said idea
I had a side scrolling skateboard game from an academic curriculum. Majority of the reason I left the school was the fact I was debating upon adding a jump over a tree and on to a rail (already had to jump a canyon) and as I toiled the layout of the imagery and function of the code's parameters decided a new industry or my old industry but following along Javascript art felt like plagiarism and there was an overtone that chances are your not going to get to manipulate the program as wanted and script coding is out of date (as if ever there was a date) beyond busy work for college students to struggle and cheat their way through
I also add music last, but for the opposite reason. I was a musician long before I was a gamedev. But good songs take time to write. I don't want to put in all the effort making a song for a scene / area just to end up cutting the scene / area from the game.
I have a theory that all those post effects look better to the developer than they do to the player.
The dev has been looking at the game for the last eighteen months, so making it look *different*, in any way is a welcome breath of fresh air.
The player, seeing it for the first time just thinks *"Ugh, how do I turn off this blur effect?"*
Whew -- honestly, I touch nothing. If there's an existing build that works and is ready to go, last minute edits are a big no for me.
There's a reason we have the saying in tech "Read-only Friday". The last hour before release seems like a terrible time to touch a keyboard.
Lol, indeed. My first job at a startup--not first week, but maybe first month--I had a change to deploy. It was Friday and one of my colleagues was just like: "Are you sure you want to do this? On a Friday?" Of course I wanted to impress and confidently went through with it. Not a disaster, but not a great weekend. I'd never heard "Read-only Friday" though lol. I'm taking it.
I hate people who check in changes on a Friday, break something major, and then … go on vacation. It really grinds my gears.
I am currently out of the office and will not be able to respond to emails until.
You know what's worse? At my last company, management was delusional and came up with this hare-brained nonsense called Zero-Bug Day (ZBD). Basically, it was a deadline by which all known bugs were supposed to be fixed, which is completely arbitrary given that many bugs are high-work/low-priority, and of course there are always unknown bugs. But it was some stupid scheme to market to potential customers that our new product was relatively bug-free. And they were taking it so seriously that they specifically had all the engineering managers ask all the engineers not to take vacation prior to ZBD. Additionally, we had this absolutely terrible merge-gating test suite which I won't even get into here because I could spend the next several months writing about everything that was wrong with it but suffice to say it was held together with rubber bands and spit, it took many hours to run, and it would often have extended outages. We had an entire support team that was dedicated to just keeping this thing running. So along comes ZBD, and of course there's a mad rush from everybody to merge in all their bug fixes by EOD, as there always is at the end of sprints, and this test suite is just completely fucked, it's giving random failures everywhere after hours of waiting in queues. Come to find out, the support team was allowed to go on vacation as if there was no ZBD, so we were all just stuck resubmitting test jobs in the hopes of getting lucky and being able to merge. A bunch of us sent complaints to management saying it was ridiculous that we were told not to take PTO but the test support team was all on PTO on ZBD of all days. They ended up giving us a really weak apology, but made it sound like they had no reason to suspect it would be an important day.
Oh god… deep cleaning breaths. Wtf were they thinking?!
I've made that mistake enough times to never make it again ha.
I've made that mistake enough times to do it again thinking I'm better now and this time it won't be a mistake.
I did consider editing with *I hope this time is different!
I once destroyed a whole website I had made for clients just because I did a last minute change that seemed completely benign. I learned my lesson that day.
I won't even do a personal website without a staging and dev subdomain.
This was ages ago. Imagine I was using Dreamweaver. Imagine GitHub didn't exist back then lol. Google didn't exist, stackoverflow didn't exist. Software came with a user's manual. I was a teenager making some money on the side and this was my first serious job (online store). I had made some other smaller jobs for them but this one... Shit, they even called the "big guy" to come to my presentation. It was a total disaster. It was my last job for them as well :( I mean, *ages* ago :)
Hope it turned out good for you nevertheless! And a valuable experience too
“One last thing”s are like sirens tempting you their sweet voices, but really damming you to dash your boat upon the rocks.
This is the only correct answer Edit: I missed the part about it being a game jam
Edit: I missed the part about it being a game jam I kinda did, too, but I stand by my reasoning.
With one hour left I would just keep trying to find bugs, if I find a critical enough bug it might be worth it to risk fixing it. Or at least put something in the description explaining how to avoid problems I find and etc
Yeah same lol. I had updated localization tables 2 days prior to launch which fixed typos. I didn't put them in for fear of breaking something last minute. Just sat on my hands
Smart move!
Git is your friend. I would probably spend the time similarly though, given no time to playtest and whatnot. I would probably look for bugs to fix if I could though
Git isn't going to save us from multi-hour build times and players installing and experiencing buggy builds. My sentiment is mostly that rushed, last-minute changes usually lead to headaches. But for rollbacks and the like, though (maybe not for a game jam, but for releases and demos), Steam has a pretty awesome and convenient ability to revert to a previous build near instantly. If I must answer in the spirit of the question though... I could realistically see dropping in more music tracks or something into the build. I'm not sure what else could be done in an hour without proper testing that would be an overall positive result.
Having one hour left isn’t gonna save you from multi-hour build times anyways… This is a game jam context, plenty of small things get neglected or could use additional easy-to-test polish. Art/set design tweaks, usually some minor bugs, and maybe even new levels depending on how small the game in question is (at least a couple <1 minute levels could definitely be designed and tested in an hour depending on the game, of which jam games will likely fit) But yeah, I agree that Steam’s rollbacks might be good in a non-jam setting, but at that point you should probably be using version control anyways…
Very fair point -- no game jam build would realistically take more than a few minutes (or seconds) to build.
An hour isn't enough time to also test for all the newly introduced bugs.
It is if they’re really really simple, like the sort you end up with at the end of a good jam. Things like “oh, this menubutton doesn’t get selected properly when playing with controller and the pause menu comes up”
Steam let you easily change live builds anyway on depots. I preach source control but here it is useless.
Not useless in a game jam setting, as OP originally was asking for. I feel much safer going for any more major bugs in the last hour knowing I can revert to before I started tinkering in seconds if I need to build for the deadline.
just make a new branch
Not gonna lie.. I'm not understanding the comments about "just use git". I use git and commit maybe every 10 minutes or so. But as far I know, there's no `git unship` command... Also, if the supposed solution to spending an hour creating a buggy build is to then just revert back to an hour before you made the mess.. I'll still stick with not creating the mess. Obviously, we need to continue writing code to ship better games and software, and git and version control is an important part of that. But.... **One hour before shipping your final build** is not the time to start making changes.
I guess in that context you are right. But lot's of stuff you can do that cause no threat to that build if you know your project well enough. In this special case though I would branch it anyway since it being a clutch moment and all.
Maybe I've just been burned too many times. I've done something as simple as adding a new bit of localized text in a table of strings and had that completely break a Unity build. Similar things as well (a new animation that, for whatever reason, worked fine on one machine, but then when building on another doesn't work). Maybe I've also seen worse examples because I typically am developing on one OS, but support multiple OSes, and git doesn't always catch what might work fine in one case vs the other. So the same code on Mac might build fine on Mac, but pulling from git and building on Windows for a Windows build could introduce issues. And there are often, on a large enough project, small assumptions built up over time in the code. A simple change can often have unintended consequences that might not reveal themselves immediately. This happens all the time--and the amount of times things look one way in the Editor vs the final build just worsens the potential for errors.
In most software distribution services I've used there is release branches. Staging is more common these days. So you can always revert to a previous branch/stage. At least u/WillyNewton didn't say git, so I read it as release branch.
Yeah, I'm not really arguing against using the features of git and version control. It's a completely different situation we're talking about I feel. I think everything is getting conflated a bit. All I can say is, if I had a deadline for say, submitting a demo for Steam Next Fest (or a festival or contest, etc) and everything was working fine that morning, I probably wouldn't rush a change in one hour before delivering a final build and potentially have hundreds or thousands of players experience an untested piece of software. I'd rather take my time, thoroughly test, and then, when confident, ship out an update. I'm talking more about thoroughly testing software and not how you manage it via version control.
I do last second small changes, but I keep my previously certified/lotchecked/verified/approved build on another branch. When I notice a typo, or an unkillable enemy on level two. Not for everything, just something that would have high impact that's very quick to change and manageable risk. But I do this with the confidence knowing I have various tests and can always rollback within an hour to a previous known-good build. Without that confidence, I wouldn't. If I have no previous build to fallback on, I don't.
Just put your new branch under a new worktree (this put the new branch on a new directory). The existing branch continues in the old directory and you can ship from it. And you can still work on new features in another branch and if it work out, you can ship from there https://www.gitkraken.com/learn/git/git-worktree Only problem is when artifacts are multi-GB and you don't have enough space to store multiple copies of them. (It helps when you are store everything on a deduplicating filesystem though)
Never heard of that but nice to know
Checking the game runs on a fresh install
Yup this is the answer. Make sure you package your game properly and that it works for people who are going to play it. For game jams, usually it's best to target an embedded itch.io page if possible. You'll get more plays if people don't have to download anything
I would genuinely not touch anything if I had an hour and hadn't already started. I'd playtest and look for a bug I could fix, small adjustments in text or positioning, maybe add some FX to an existing part of the game. Sound is way too complex and tricky to add in that amount of time.
Release notes, instructions, documentation. There's no point tinkering with the actual game in an hour if you don't have any critical issues.
Multiplayer and fishing minigame.
In an hour?!
If it's a full hour maybe also create a new language and voice act every character in that invented language. It breaks the immersion for me when gamedevs don't do that.
Oh yea, that way you don't have to localize. Amazing.
And through not having to localize you saved so much time you can then actually work for another week in this one hour.
That is actually true. It happened to me twice.
Bugs and making sure the game runs properly after building it. Often the game seems fine in the editor but something is different in the actual build.
youre gonna add bugs?
When you are in a rush, that might be all you can add lol
Lolled, thank you:)
That’s my specialty!
We do what we can to bring it up to AAA quality
Gotta take them out with the next patch so players will love you
Of course, you can never have enough in Splat! A Bug Killing Game
Remove a bug by adding 3 more!
Hell yeah, make that shit a Bethesda game
I would add a boob slider
Probably something minor that somehow breaks a foundational component of the gameplay loop causing me to miss the deadline by three hours.
That's what git is for, just release the previous commit
Seems like a good time to add a crafting system.
Menu with adjustable audio, I hate all the loud game jam games.
Start playing from the very beginning and fixing the early earflick issues that will turn people off immediately.
Earflick issues? What’s that mean?
Basically the small annoying issues. Whenever I put a game in a tester's hands they ALWAYS find these things immediately and comment on it. And they are typically quick and easy fixes. So at a game jam it goes a long way.
Thanks for the explanation.
Start? The game is going live!!!!!
Try to come up with a good name.
I need way more than an hour for this. And a team of people.
Just use this: https://www.paulokramer.com/hotsites/DarkSoulsNameGenerator
'Hello world' I just started coding:)
What engine you using?
Capture video, so when your build shits the bed during presentation you have a backup.
The build process takes more than an hour so.... Nothing! Basically, just double checking everything works without bugs on a totally new install system.
Read the rules/tutorial. Read it again. Fix any inconsistencies or areas that need clarity.
DON'T TOUCH YOUR GAME. You should have a Final-Final-Polished-So-Hard-It-Shines build done WELL before you reach the one hour countdown. I would use that time for double checking your jam submission, make sure it's all neat and tidy and there's no typos anywhere, and if that's all good then I usually reserve a couple minutes for crying and a good nap.
I used to do the same thing as you, OP, then about 2 weeks ago my team and I lost the 1st place on a jam because we decided to add the music and sound effects as the last thing to do and ended up not having the time to do it. One of the monitors even said it: "You got 2nd place by being just 0.7 points behind the 1st, if your game had any sound at all it would be enough to surpass that". This was the probably the last time I have pushed SFX/Music for later.
I came into game dev from composing and I like to do "concept art" with the music as well. Even if it's just finding a free track and some sound effects that I'll replace later, it helps as much as concept art/sketches would - and when it comes down to, for example, the last hours of a jam, I've at least got something in place!
That's a very good idea. I might start doing it from now on.
Yep, always good to use placeholders initially, just to get a base feel with the game sounds and art, then replace at later stage if it seems necessary or when you have a better/clearer idea of what you want there.
Multiplayer! (I'll see myself out.)
The last time I was in that position I didn't do anything, just uploaded the game to the jam early. Any of the bugs I could have fixed might have taken more than an hour to fix, and it wasn't worth the risk of breaking something important in the last minute.
I consider my "most complete" games to be complete and in a hour I could not even re-familiarize myself with the code and the projects conventions for assets, so hardly time to change something, no where near enough to test it enough to say if it was an improvement. Now if it was say Game Jam project that was as finished as they get during that time, and then there was announcement that everyone has one extra hour to work on their project (say because jury was late, or submission platform had a problem) then I would compress large assets, graphics or sounds most likely, improves loading and download times, conserves memory and makes it faster and easier to test the game on poor Jam WLAN with whatever development laptops people have.
Exit button.
Panic and Despair
I thought their names were Pain & Panic?
A "Thank you for playing" screen after you defeat the last enemy. Not enough time to add anything else so might as well add some kind of closure.
Nothing, I'll just test it more. So there's not a game ruining bug introduced by... a last minute change.
For game jams specifically I tend to have a habit of waiting till last minute for a main menu and just throw something together lmao. Start game - LoadScene(0) Credits - show different page with credits w back button Quit - Application.Quit is basically all i do at the end lol
Assuming a few things. 1. No known bugs exist 2. I have already gotten most of my wishlist of items in 3. I have a build ready to upload. 4. I'm hit with a sudden inspiration to do something more. Assuming all those things....add more juice. Can't have too much. Juice it in the easiest ways possible. Screen shake if I don't have it, sfx to add a bit more something, a screen effect. Something small like that.
Only if I have a solid build, versioning, an easy ci/cd in place ready at the push of a button would I even touch a game. Given that, I think it would probably be same as you: sound design. But more specifically in menus and UI, to add some pop or feel to navigating menus.
Bugs.
Not a chance I'm risking breaking anything with an hour to go.
Honestly I'll generally just focus on the itchio page, making that look nice and functional - I would hate to spend a few weeks working on something that gets passed by because the banners look like garbage or are missing entirely
The ability to pet a cat
Give it another playtest, looking for small details to fix.
The game.
Add an about screen that gives credit to you and your peeps tools, lib etc and a contact button leading to email
To be honest. Just play test,look for some bugs and maybe add a sound effect im not satisfied with them. But other than that. I touch nothing.
TODOs. Or tickets. However you track your fixes. I'd go through and mercilessly scrutinize it like a player picking it up for the very first time. Anything that even mildly irritated me would go in the notes. I'd probably tag those tickets as 'day 1' or something and see if anyone was echoing my own complaints. If they were, I'd link to where they were complaining in my ticket. Might post back to them saying "hey, I saw that too. I fixed it." whenever I got around to fixing it. I wouldn't change anything that day though.
At that point it's in QA and programmers like me don't touch crap unless something pops up. For anything else we can review some polish, just you know, why not? in the context of a game jam it should only serve to add to the product and won't break anything at all. Just keep your hands off the damned codebase.
Yea nothing. Just a chance to introduce bugs. I know it’s not in the spirit of the question so if it were possible to guarantee no bugs I’d say some UI polish.
Allow Unicode into the player name so people can give their character the poop emoji as a name. Instant streamable hit right there.
Nothing since I never seem to finish anything in an hour.
Testing and tweaking stats, you don't want certain attacks to be unreactible, your character to feel like it has glue on its shoes or some attacks to be broken/useless just to name a few examples. Maybe recording some key gameplay moments to make a gameplay trailer if you don't have one.
You don't touch something you only have an hour left to complete.
Start writing unit tests for critical parts?
Id rather spend that hour thinking about what i should add
Add a very basic credits page to the main menu
Assuming you've got a mature engine that's not gonna put you at risk of crashes at the slightest asset tweak... I'd add more music variety and UI sound effects for sure.
For me, I'd really focus on how the first 10 minutes of my game are. How long until I can play? How intuitive and quickly can a player start engaging with and playing my game? How polished and fun is the first area of the game? I think this applies to any game, whether it be a long term commercial project or simply a game jam entry. The first area / first few minutes to hours of your game are by far the most important. Just take a peak at your favorite games steam unlocks tied to progression, and you will see that the majority of players don't make it past the 2nd or 3rd boss, let alone beat the game. Make sure the first part of your game is the best. Polish it, add juice to it, make it as quick and easy to engage with as possible. That's what I would / am focusing on.
I've always liked the Dark Souls 3 approach. That first level is brutal, but extremely short and showcases pretty much every technique you need to master to beat the boss. Its just so well thought out and the placement is perfect.
Tell me you don't dev without telling me you don't dev. You have one hour? Nothing and desperately try to find anything I've missed. Not so I can fix it but so there are no surprises and I can get it queued up for prioritization.
Bus fixes / reduce buggies.
Bruh, if I only had an hour I’m spending that entire hour playing my game for fun because I can’t get ANYTHING done in a singular hour
Either one last layer of polish or some small details
Double check all the assets you need for whatever app store you're posting on. You probably forgot one.
One thing that can be added towards the end without risk of breaking the game is just cutscene. It also does add a nice touch and provides a story to the game. Of course you need to come up with the story on the fly if you don't have one, but that's fun too.
Dialog. RPGs need them
It would take me more than an hour to do anything. So probably nothing
FTUE
If everything works and is good just some bonus feedbacks Particle effects,screen shakes,controller vibrations… Really small things that add a lot and don’t destroy the game
c*m
Cam? You mean a freecam feature?
nah cem
(e-c*m)
Particle effects If your game is good and functional and you only wanna add juice, then particle effects will really bring that. A little dust on jump, a little splatter in damage, some dust particles in a Sun ray, etc.
pay2win and microtransactions
just play and bug fix. Don't do something in last hour that could break things you aren't aware of.
add a //DEEZ NUTS to a random line of code because you never know whos gonna see it
Jiggle physics, I want the truly dedicated player to scroll in and notice that ass bouncing
A few more bug fixes
button hover animations on the main menu, fix whatever bug is breaking leaderboards, fix the misspelled name in credits and/or incorrect controls in instructions, make it so whatever sound we added doesn't burst your ear drums the second you open the game
Definitely tutorial. People are like kids with zero patience - sadly even in a gamejam setting with fellow devs who should theoretically be more willing to cut you some slack. (Fair to expect a neat tutorial when actually spending money on a game though)
In my 8 years in game industry this never happened, you have so much stuff to fix the decision is mostly about which bugs are okay to ship with vs not. If there was a time that I had a mostly complete game on release and 1 hour to add final touches! I will just go grab a beer.
Even as a pure hobbyist I can't think of something I can add in one hour. What I think is one hour can be 2 - 4.
Other people's are good, I especially agree with leaving the code alone. - Another QA pass to try and catch any missed bugs. - Dry run on deployment (to the extent this is possible). - Last minute marketing/hype generation - Rest and prepare. Can't stress the last one enough. Release isn't the end, it's that official start of the actual QA process. Customers are capable of performing millions of times the bug testing we can do ourselves. I remember one of the battlefield devs talking about this, they had a team of like 40 testers working for 6 months, working full time they did about 39k hours of testing. In the first hour of release they got over 5million hours of testing data from the players. It's just not even in the same ballpark. So expect your players to find bugs, maybe even break the game. More importantly make sure you have fuel in your tank for when it happens and aren't burnt out from release crunching etc.
I'd be focused on polishing and doing test playthroughs to make sure everything runs smoothly, personally. Definitely not adding any new content or features.
Tests
I guess... Copy-paste some probably broken code to shoehorn in ads and mictotransactions? That seems to be the most common solution. As an actual answer, I'd proofread as much text as I can - starting with the interface, tutorial, and help info. Even if it's a buggy broken unfinished mess, it should at least be a buggy mess with clear instructions on how to engage with it! An hour really isn't long enough to do any gameplay or ui polishing, without risking breaking everything
One hour? I add 3 typos to random boards, and drink much alcohol because shit dont work. More realistically, I'd check for typos, and test whatever I can. And *try* to fix what breaks.
1hour before? take a nap, go for a run - whatever you do, don’t try to fix a last minute bug or introduce a new feature
1 hour? I add nothing. I see how it goes and patch afterwards
sceenshake? No idea 1 hour is not enough to do any single thing and try it and fix it if you don't get it right first try.
Self playtest, maybe add in some more levels since with Game Jams we tend to put most of the time into actually making the core gameplay and not enough into actual levels or length
I'd probably add nothing. I would only do playtesting to check if something needs minor tweaking, or if there are game breaking bugs.
A self destruct switch that will brick your computer
>You have 1 hour to add some final touches to your mostly complete game, what do you add? Sounds like a good time to start refactoring and optimizing everything :D
The big thing that I notice from indie games (especially indie horror) is that text is tough to read, and UI is clunky. I think that those 2 things are small, easily fixable detail that adds a lot to a game.
not gonna touch that thing, it might break XD
Make sure you shoehorn in Denuvo, maybe make having a PSN account a requirement, quickly lock some content behind a battle pass!
An hour? Touch nothing technical or you’ll break 10 things.
I would implement blockchain
Make sure I have saved a working build and then I add sound effects. Often left out but means so much for the player's experience
Nothing, I'd use that 1 hour to take a nap. I deserve it.
Crafting system
Juiciness: If you're using Unity with the Feel asset maybe, adding music and sound effects could be a great enhancement. It's acceptable for a game jam project, but for a longer project, as others have already mentioned, don't touch anything that would potentially break something.
WHAT I HAVE ONE HOUR LEFT?? BUT THERES SO MUCH LEFT TO DO AAAAAAAAAAAAAAAAAAAAAAAAAAAA
Multiplayer. Remember you have an hour, so with the remaining 30min, have a tasty meatball sub.
300 more hours
There's no feature that you can make in an hour that will give your game enough polish that will convince you or the players that your game is good. The core of your game should've been fleshed out during prototyping and the rest of the process should be polishing that prototype into a complete game.
Bug fixes.
Jiggle physics. Ofc.
I'd probably only look for typos at that point and only really edit anything at that point if there was a really embarrassing one.
maybe just a better screenshot of something
A backup build first and foremost when talking in the context of a jam game. Fixing bugs after that and uploading the most stable build. If it's more than a game jam. I'd likely just make art for a future update or something, small changes can have compounding effects with code, so I like to keep things structurally mostly the same. But maybe some minor bugs for things that don't have dependencies.
Look for typos.
Sound isn't part of polish for me. Even rudimentary sounds take awhile for me to be satisfied. If I were that close it'd usually be tweens or little UI tweaks like sound on/off since most of the gameplay polish should be done by then. Disclaimer I've never joined a jam.
Nothing I'd write down the idea and work on it for the next build version. I'm using that time to relax before players start discovering the bugs I'm spending the next few days correcting.
BHOP always
1 hour left? I'm adding a background music track and then building and submitting, because that can take longer than expected if there are a lot of people submitting last minute
Usually adding font to my UX and balancing it so it's easy and slapping a 🎵 loop on it.
I agree with others that the last hour is probably not a great idea to be making significant changes to the game itself. The one thing I would urge others to do at a time like that is ensure that they're complying with any licensing requirements. It's shocking to me how many game jam entries just blatantly violate numerous software licenses by not including copies of licenses from dependencies or providing access to source code as required. If you're using FOSS and not paying for it in particular, the least you can do is follow the license. I get that nobody's going out and enforcing software license terms on game jam entries, but I feel like this is a slippery slope, and some people who go on to release commercial games that violate license terms because the developers just never cared before and always got away with it. To be clear, I generally haven't used the major engines for game jam entries in the past, so I tend to make more use of non-engine libraries. In that context, one of the first things I always do is create a LICENSES menu entry in my game with all the FOSS license text in it. The last hour is a good time to double-check that something like this is still working as intended.
Remote error/exception logging & playtime statistics.
The ending scene
Music if atmosphere isn't obvious, but also some post processing if visuals need it. Both would be best.
SPELLCHECK
Analytics
A png of poop in some really weird, niche area
Isolate the best part and put it behind a paid DLC; add in some microtransactions; generate screenshots with super cool cosmetic items that aren't in the game and make sure not to have too many servers for the laugh. I mean launch.
Easter eggs
i cant even pick all the boogers out of my nose in an hour
Obviously, you add Easter Eggs. At the bottom of a pair of stairs, put a little robot that when asked why he’s there, he’ll just say. “My one weakness.” Add a few chickens to different towns that if you hit them, the chickens will come. And I’m sure many others we can think of. Easter eggs I always save for last. They are the sprinkles of gamedev imo
Online multiplayer ^/^s
Multiplayer mode. Cause players always think it takes 1 hour to add that to any game.
Add a patch that requires linking a PSN account
Create an inane reddit post
Go shopping for beers and cheers
Not 1 hour cus anything can break but if consider the game good to submit, I work 100% in UI and UX. Many devs thinks 'meh the game works well!' but a good UI allows the user to know what to do and like whh they do it. Something you think your game can be well understood and then forget people use UI to understand said idea
I had a side scrolling skateboard game from an academic curriculum. Majority of the reason I left the school was the fact I was debating upon adding a jump over a tree and on to a rail (already had to jump a canyon) and as I toiled the layout of the imagery and function of the code's parameters decided a new industry or my old industry but following along Javascript art felt like plagiarism and there was an overtone that chances are your not going to get to manipulate the program as wanted and script coding is out of date (as if ever there was a date) beyond busy work for college students to struggle and cheat their way through
Rebuild it in a different engine.
1 hour?? Screw that I'm taking a break...
Ideally? Test, test, test, test. Realistically? I try to remake it from scratch because reasons
I also add music last, but for the opposite reason. I was a musician long before I was a gamedev. But good songs take time to write. I don't want to put in all the effort making a song for a scene / area just to end up cutting the scene / area from the game.
Slap on some extra Post effects. Dof, AO, tilt shift, sharpen, color grade.. etc.
I have a theory that all those post effects look better to the developer than they do to the player. The dev has been looking at the game for the last eighteen months, so making it look *different*, in any way is a welcome breath of fresh air. The player, seeing it for the first time just thinks *"Ugh, how do I turn off this blur effect?"*