I recently participated in Xbox Game Studios (XGS) Game Camp Sweden 2023 (XGC), which started at the beginning of April and ended Wednesday the 21st of June. I was part of the team Alien's Dozen (find my teammates) and together we developed Alien Bakery. This post is a dev log containing thoughts on the XGC experience and the thought process behind many of our decisions.
"What is Alien Bakery?" I hear you asking? Well, check out the trailer below for an overview. After that, continue reading to know how we ended up there.
Before the post starts proper, I want to preface the it by saying that this dev log is very much written from my perspective. I wrote down as much as I could remember with regards to contributions and of what was discussed during meetings, but for the most part it focuses on my personal contributions to the project. Just know that everyone in the team contributed to the final game. Without them, Alien Bakery wouldn't be what it is. Much love to them. Also, you can read our Game Design Document here . A summarized post about the Game Camp experience can also be found here.
Week 1 (3-9 April)
An introductory presentation was held, and later that week we had our first meeting as a group together with our XGS contact which was mostly an introduction to the whole thing as well. We decided on the tools we would use, and so we settled on Unity for the game's engine, Trello to track tasks, and Discord for communication. We went over what would be sent in at the end, being a trailer of our game and a Game Design Document (GDD). Not much else happened during the first week development wise, so instead I'll go over how a typical week went so that I don't need to include it for every week.
Live presentations were held where we had the opportunity to ask questions to the presenters afterwards. These were really the only scheduled things apart from deadlines and group meetings (which were booked independently by us as a group. Some pre-recorded presentations were also made available. Each presentation was about a different topic and provided tons of neat info, so you really got both the breadth and depth of the provided information.
We usually booked a meeting with our XGS contact/mentor at the end of each week to get feedback on our current progress. Aside from these, the work was done in our own time.
Logo for Xbox Game Studios Game Camp Sweden 2023.
Week 2 (10-16 April)
The week started with a get-to-know-each-other meeting where we discussed what we wanted our game to be. We started a Trello board where we each created a card containing a couple of potential ideas for the game. After going through each card, we decided to write down our top two ideas of the bunch to see what ideas were most popular. When that was done, we created a cohesive idea out of them, managing to incorporate some ideas from each person. We decided on a 3D platformer, featuring puzzle elements, and stealth elements, starring a small Alien who had crashlanded, inside of a bakery.
Ramiro wrote down his thoughts on how this idea could become a reality, detailing potential mechanics and enemies, and some structure the game could have. With this detailed, the first thing we did was create a repository on GitHub so everyone had access to the same project from the start. I took on the role of developing the character controller, and so development of the game had begun. I started out looking for inspiration in some of the character controllers I've worked on for my personal projects, which themselves were mostly inspired by the Super Mario games 64 and Odyssey. These older character controllers were developed using either Rigidbodies or CharacterControllers, so when deciding on which approach to use for this project, while I felt that CharacterControllers had some great benefits, I decided to go with Rigidbodies for its potential.
As it would be a 3D platformer at its core, I decided to implement buffered inputs and "coyote time" from the get-go. These are necessary for a platformer to feel good, in my opinion. Buffered inputs allow the user to e.g. press jump slightly before landing and still be allowed to perform the jump upon landing without having to re-press the jump button, which makes the game feel less rigid, more smooth. Coyote time lessens the frustration when playing, as it allows the player to perform their first jump for a brief period of time after running off an edge. Both of these mechanics were implemented in the same way (each being lists containing timer values that continously count down, with the action going through if the timer is above 0), and in a way that allowed me to use it for any input - read more on my implementation here.
A Constants script was added to make it easier to get certain values, like enums that should be accessible from anywhere, and a global instance-able script for functions was added as well. For character values, I added a separate script using ScriptableObject, which allows us to create assets for character values and simply add it to any character we want, making them easier to maintain.
During a meeting later in the week, we decided to update the Unity project to utilize Universal Render Pipeline (URP), and to look into Cinemachine (CM), as well as coming up with the "pick and throw" mechanic, meaning a slight change in direction of the project from our initial thoughts. We also brainstormed some ideas on the story, theme, and enemies, and later Felicia showed us some of her concept art. This featured various designs for the Alien and its potential weapon, art of a Cake enemy, art of a Gingerbread Man enemy and art of a Mouse/Rat enemy with a mounted Gingerbread Man. She also shared an idea for a story we could tell in the background via environmental storytelling. These thoughts were written down in our ideas page.
Felicia's concept of a Gingerbread Man riding on a Rat.
Week 3 (17-23 April)
I also had an idea for an enemy, being the Punschroll. It could either be based on its Swedish nickname of "dammsugare", meaning vacuum cleaner, where it would suck up the player's picked up item, or it could take inspiration from its international name and become the "punch-roll", a boxer enemy. After that, Felicia shared her idea of having a cookie chase after the player, rolling on its side, which in turn was followed up by my idea of Swiss rolls acting as stage hazards that roll back and forth in place. Meanwhile, Paulina had started work on the model for the Rat enemy.
I uploaded the initial version of the player movement to the shared GitHub repository. In this version, the character had all previously mentioned features. The character moved according to the camera's rotation, like a typical third-person game. I'd also added a pretty robust ground checker (something CharacterControllers come with, but not Rigidbodies) using SphereCast, and also made it so we could input any amount of jumps we wanted the character to be able to do (initially planned amount being 2, a.k.a. double jump). Finally, I'd added taking damage and dying, but didn't have anything to test it with yet.
I had developed the character controller in a way that would hopefully allow us to use it for our enemies as well. The character controller script is used as base for the player script which is then attached to the player object. The player script itself just reads the users controller inputs and sets the desired value to the base class' buffer timer list, and since those timers have values the base class runs the desired functions. The base script could therefore in theory be used for enemies as well, with the main enemy script calling on the base script's functions.
We started looking into the things discussed during the last meeting. I updated the project to URP, while Akash imported the CM package. After a brief look at CM we couldn't nail down a satisfying camera, so I imported a camera script from a previous project of mine and used that for the time being. I then looked into adding pick-and-throw to the game, creating a system where there's a point the object moves towards when picked up. While there's a picked up object, it can be either dropped or thrown. Dropped objects just fall down, while thrown objects' velocity is set toward the direction the camera is looking. The object closest to the character within a certain radius is the one that'll be picked up, and it is highlighted through the use of its material's Emission property. Also, the character's speed changes depending on the picked up object's weight, with lighter objects increasing their speed and heavier decreasing it.
During this week's meeting we realized that the character should have audio, and as I had an idea involving ScriptableObjects I took on that challenge and ended up creating a ScriptableObject which has variables for both voice and sound effect for the various actions a character can perform. A function to play the audio was yjem added and set at corresponding places in the character controller script, so it would just be for us to create a ScriptableObject for a character containing its sounds and it would play when the character performed the desired action.
By the end of this week, I was curious if the character movement could be used for our enemies' AI. I therefore decided to start working on one of our enemy ideas, being the Rolling Cookie, and tried creating its AI. Seeing it work as theorized was thrilling, and after fixing some wonky movement, we had our first enemy! This meant that we could re-use the movement code and only adjust the stats for each enemy and that they could use any functions added to the base characters moveset.
Felicia posted some of her latest concept art, including potential movesets for the Cake enemy, Cookie enemy, and Rat enemy, as well as her idea of a design of our bakery. Later on we had a meeting where the current progress was described, which was followed by Felicia posting some ideas for level designs. Our ideas page was also worked into a one-page GDD.
Image from 23rd of April, displaying how the initial prototype looked. Capsule in the middle is the player, the pink cube and its neighbors are pick-ups, and you can see the Cookie enemy in the distance to the left.
Week 4 (24-30 April)
Knowing the character controller could be used for enemies as well, I used it to create a base script for each AI to use, which included functions for sticking around the player's last known location for a while, and going back to its starting position after having lost track of the player for a long enough time. I also added an interface for functions each enemy would use, such as waking up and going to sleep, and then added said functionality to the Rolling Cookie. How it should wake up when the player approaches, doing its thing when awake, and how it went to sleep after reaching its starting position was then also programmed.
I'd also recieved some feedback on the throwing of objects, so I updated the mechanic to set a force instead of velocity so that the object's weight decided the distance it would go, for a more expected feel. How the closest object was found was also updated to use tags instead of layers to determine what objects could be picked up.
After we had settled on a design for the Alien, Felicia drew it and its color palette, after which Paulina began working on its model.
With both an enemy and character audio, it was now possible to get a reaction from the player when they took damage from an enemy. As they were damaged seemingly multiple times per hit, I realized damage immunity was missing. This was something I had developed for another project, so that code was found and improved upon. "Flash of pain" was added at the same time, which is when the character is blinking while immune to damage. Similar to how buffered inputs and coyote timers gives the player a bit of leniency, the damage immunity lasts a bit longer than the "flash of pain" in order to give the player time to react to the immunity ending.
For this week's meeting, it was time to decide what we wanted to have in our first build. We decided on the player, and an enemy, placed in a stage, with some of the game's theming in there. Aiming to have it done by this time next week, work on the missing features began. Ramiro took on the challenge of creating a level, and Akash would look into making GitHub automatically creating builds of the game when we pushed to the main branch, as well as finishing a Dough enemy he had started working on. The Dough enemy pounces the player, knocking them back, and if the player gets the chance, they can jump on the Dough's back and use it as a trampoline.
Some concepts that went unused for the XGC demo. Felicia's Cake enemy and a way to defeat it, and my Puncshroll enemy and its two possible variations.
Week 5 (1-7 May)
Akash implemented the auto-build feature to the repository, and Felicia drew some concept art of his Dough enemy. Ramiro's had been working on a stage, and had finished its graybox this week. I created a few prefabs of what we had so far (player, Cookie enemy, pickups) and placed them around the level and tried it out. So fun running around in an actual level.
Work on the player continued afterwards, this time focusing on character animations. I downloaded a temporary model and an animation set from Mixamo and began the implementation. Another ScriptableObject similar to character audio and stats was created, which later turned out to be unnecessary as Unity's built-in AnimationController sort of works in a similar way and is better. Anyway, the character now animates when playing. Idle, walk, running, and jump/fall animations were added to begin with.
As we had a couple of scenes in the game, we wanted to have the ability to switch between them in the build, which led to me implementing loading screens. These are done by loading a separate scene for loading, and loading asynchronously while a bar gets filled, after which the desired scene is loaded. After that, we compiled our first build. While there were some things missing from the list we had created, it was great having a version of the game accessible by everyone in the team.
This week's meeting focused on what we wanted our game to be at the end of XGC, a.k.a. the minimum viable product (MVP). We decided on a list of things we wanted (things that were already implemented and things we felt were required, such as UI).
Felicia drew concept art of the Alien's spaceship and wrote an outline for the game's story, while Paulina had finished the models for the Rat and the Alien and added them to the repository.
The evolution of Kali, our Alien character. From Felicia's early concepts and final appearance, to Paulina's initial and finalized models.
Week 6 (8-14 May)
We finally settled on a team name, and a name for the game! Previously we had two suggestions for team name, with one being my suggestion of Alien's Dozen, a play on baker's dozen and our game focusing on an alien. The other suggestion, being Felicia's Alien Bakery, was instead used as the name of the game, playing on the idea of the bakery being alien to the as-of-yet-unnamed Alien.
I'd noticed a few problems with the build created last week. Upon loading a scene, it was like it was loaded multiple times, and for each time a scene was changed, more scenes were loaded. This turned out to be a problem with the DontDestroyOnLoad object I added, which is used to switch scenes. As this object was in one of the two available scenes, more of them were created, each likely loading the same scene at the same time. This was solved by creating an initial scene where only this object was available, and then loading into a title screen from which the scene can be changed. The other problem was that the camera was stuttering, but this was fixed by moving the code for camera positioning from LateUpdate to FixedUpdate, to match player movement being called in FixedUpdate.
I started adding UI to the game, and so I also added Unity's Localization package, just in case we wanted to be able to localize the game to various languages. It could be too early to tell at this stage, but it's better to have it from the start as changing it later on would just be cumbersome. There was some UI work done on the title screen, and regarding gameplay some basic UI was added displaying the player's health. Finally, the character model I'd downloaded from Mixamo was replaced by the Alien model Paulina had made. It's alive!
Felicia drew some more concept art of how the bakery/café's prep area would look, while Paulina finished up the models of the Alien's spaceship and the Gingerbread Man.
Image from 8th of May. Our temporary character model can be seen running around in an early version of Ramiro's stage. You can see the particles of a defeated Cookie, as well as the Swiss Roll in the background (long cylinder).
Week 7 (15-21 May)
This week was spent on adding the missing pieces needed for us to build an actual game out of this. While the player has been able to take damage for a while, they haven't actually been defeatable, so a death-state was finally added. The player hasn't been able to finish stages either, and so the main objectives and stage goals have been added. Now the player can pick up a main objective and bring it to the goal (a.k.a. bring the spaceship part to the spaceship), clearing the stage! Finally, menus were added. The player can now pause the game and select from a couple of options, and when defeated they have a few options as well. The title screen also received a menu with its own set of choices, instead of just pressing a button to start.
With that done, it was time to refine the throwing mechanic. While it worked, it wasn't as good as it could be, given it didn't aim towards what the camera was looking at. After updating its code it felt more like the original vision, though it could still do with a bit more refinement.
Felicia drew art of the proposed second stage, focused on the clean-up zone. Akash pushed the initial version of his Dough enemy to the project, stating it wasn't done yet.
Image from 21st of May, showcasing idle Cookie enemies and Cookie Decoys and some preliminary UI. The Alien's model has also been added, and the main objective can be seen in the background.
Week 8 (22-28 May)
The GDD had been mostly ignored by everyone up to this point, so it was time to start working on it for real. We'd received a template on how a GDD should look, so I started by copying over each section to our document, followed by me adding some information from our one-page GDD, before growing tired of it and continuing work on the project itself.
Felicia drew art that we could use for the game's title screen, so I added it as its background. I also adjusted the UI in various ways. A reticle was added to the screen to help players with the aiming when throwing items on enemies. It's only active if the player is holding an item, as it has no use otherwise. Related to throwing, code was added that made sure that items were thrown to the center of the screen, as opposed to towards where the camera was looking. The picked up items are placed a bit above and to the side of the player, so they would always be thrown off-center otherwise.
Speaking of pickups, I made adjustments to how our pickups behave in Unity. We realized that we could use pickups as platforms, but you were unable to stand on them properly. Previously they were on their own layer, which caused some issues with collision and made it impossible to use them as platforms more than at most one time. The code was altered so that pickups could be assigned by using tags instead of layers, solving the issue. Another change was that any picked up item's colliders were turned off upon pickup. As it were, large items collided with the player's collider, pushing them in unwanted directions. Now the item can be of any scale without issue. There are still some visibility issues, but that is a problem for another day.
In terms of polish, up to this point the Cookie enemy used sounds of a human for testing purposes. I finally decided to find proper audio for a Cookie enemy. Since we had a death state, an animation state for when the player is defeated was added so that they'll act appropriately on defeat. Stage goals also saw an improvement, as you previously had to hold the item while in the goal-zone in order to clear the stage. Now, whether that's the case or as long as both you and the main objective remain inside the zone at the same time, you'll clear the stage. Finally, I created a bunch of new prefabs to make it easier for us to place items in stages.
While Akash was busy with the Dough enemy, I started looing into making AI's for the Rat and Gingerbread Men enemies. Time was running out, so the decision was made to come up with a combined AI, one to use for the both of them. I began exploring how a Gingerbread Man could be mounted on a Rat, and that's about how far I got before the week ended.
Felicia's art for the title screen, displaying the front of the bakery. The left hand side was left clear to leave room for UI buttons.
Week 9 (29 May – 4 June)
The final stretch is upon us, but the AI I started needed to be completed. The new Mountable Enemy script was based on the Rolling Enemy script, just to copy over the wake up code and such. To start, the stats of the new enemy were adjusted to make a more agile-feeling enemy, a bit slower than the Cookie but with a smaller turn-radius. In my mind I had the idea of the Rat running towards you quickly before stopping in place, charging up a jump, and then jumping at you and retreating quickly after. What I ended up with was a slower enemy that constantly run towards you. At a close enough distance, it jumps towards you faster than its move speed, and stopping for a while after landing before repeating the process. It's not exactly what I wanted, but it was good enough as there was still much to do in other departments.
It wasn't done yet, however. We still wanted to have Gingerbread Men mounted on Rats. What I ended up doing was adding a variable to the Mountable Enemy script where you would put a prefab. On load, an instance of the prefab is spawned and placed at a set position on the Rat, a position that's manually set via an empty GameObject. The mounted enemy has a collider, and when hit they're unmounted. With this in place, our Rat and Gingerbread enemies (plus the Gingerbread Man Riding A Rat combo enemy) were done!
Now that my enemies were complete, I started looking into adding a bit more oomph to throwing items and hitting enemies. Knockback functionality was added, so whenever someone took damage they would also be knocked back. It greatly emphasised the hit, it worked to inform you that it hit, and it's just fun as the knockback value was set a little too high. Another change made for enemies was how they track the player. As it were, they were homing in on the player's current position with lazer.precision. To add a bit of realism and leniency, a quese was added that stored the players position each frame. When the queue was filled, the earliest added position would be dequeued and used as the position enemies would track, ensuring enemies were not as precise as before.
With that done, it was time to polish up what we had. The reticle was adjusted to turn red when aiming at an enemy, further increasing its readability. While we had functioning menus, they felt a bit lifeless, so sound effects with a bit of a sci-fi theme were added when navigating them and selecting an option. When throwing an item, you unintentionally had the ability to instantly pick it up and throw it again to increase its velocity. As this could lead to losing said item, the velocity is reset before applying the new one, so it never went faster than intended. I also finally discovered a way to improve the camera when using a mouse. Moving the camera with the mouse has been way too sensitive since the beginning, but I realized that the mouse position can be used to track which input method is used, so if the game detects it has changed, the value used to move the mouse was lowered to a degree similar to when using a controller. The general stability of the game was increased as well, with more null checks added.
Ramiro shared the first look of a new stage he'd been working on. A new layout compared to his previous stage, and he'd placed a bunch of kitchen supplies and the like everywhere. It looked really good, exactly like a kitchen should. Work also began on the pitch this week. Participants had been given the opportunity to pitch our games to people at XGS, where they'd hear us out and give us feedback on what could be improved and such. Only Felicia and I had the ability to participate, so we started working on it.
The GDD was further expanded with info based on the game. I went over what we had in the build and detailed basically every aspect of it as it was. The GDD was still not finished, but not much remained. Felicia finished the concept art of the third act, taking place in the dining area of the café. She also finished the backstory of the game, which you can read in the next paragraph.
You are Kali, a master pilot from the planet of Hanakiita. Hanakiita's population is growing at an exponential rate, and combined with the increased industrialization of the planet they are running low on their fuel resources of sugar and oil. A search has been conducted in the galaxy, and the results have been planets containing the resources, but not in large enough quantities. There was one exception: Oleum 73. Kali was sent there on a mission to confirm these results. On his way there, he collided with one of Oleum 73's satellites, sending him and his ship racing towards its surface. He landed safely inside of a strange compound, but his ship was worse for the wear. Kali wasn't looking at that, though. Beyond the crashsite, he saw what could be an infinite amount of sugar and oil. The scan result was correct! Kali must find the missing ship pieces in this sweet land, filled with sentient cookies, cakes, and pastries, in order to repair his ship and return home with the good news!
Image from 1st of June, showcasing a work in progress version of Ramiro's final stage.
Week 10 (5-11 June)
It was time to finalize the build so that we could start recording footage for the trailer. The throwing was improved even further, some music was added, some voices were changed, and a Credits screen was added (static screen accessible from the main menu). The camera sensitivity with a mouse was further improved as well with a more robust check, among other changes.
Ramiro had continued working on the stage and had finished its main layout by now, icluding moving and spinning platforms. I retrieved his stage and started filling it with prefabs, namely the player, the main objective, and a goal, alongside some props and enemies. Playing around in it was awesome, to say the least.
It didn't seem like the look of the Dough enemy would be finished on time, since, well, how does a Dough blob look? We did some thinking and decided to turn it into a Jelly enemy. Jelly is bouncier than dough, and it can be shaped like a cube like the model Akash's Dough enemy used at this time. We took some inspiration from Tom & Jerry, and now the Dough enemy was a Jelly enemy, which may actually have been to the game's benefit, as we realized that Dough could still be used in the future as a hazard behaving similar to quicksand.
Like with the Dough, we didn't have a finished look for the Cookie enemy. After a bit of brainstorming we realized that donuts would be a good replacement. Round, but with a larger height (read: a larger hitbox), making it easier to hit and therefore solving another problem we had with the Cookie. And so, the Cookie was now the Donut. While looking for models, I had trouble finding one for the Swiss Roll hazard, so it was changed into a Rolling Pin due to model availability.
Work on the pitch continued. During the meeting with our mentor we held a preliminary pitch, where he provided us with some good feedback on how it could be improved. Using his feedback, we restructured the whole pitch, making it easier to read and cutting some fat.
The week was almost over and the build still wasn't done. However, Paulina managed to finish the Rat's animations just in time for the final build, and Akash managed to improve the jelly enemies by adding deformity to them, making them appear wobbly. I continued working on the game, fixing various bugs, like how you couldn't move on moving platforms. Since cookies were no longer enemies and since the player's health was a circle, the health UI turned into a cookie on a plate. More sounds were added as well and some more fixes were made. Finally, the XGC version of Alien Bakery was complete!
Inspiration for the Jelly enemy. Notice the similarities?
Week 11 (12-18 June)
With the build done, I started recording footage to use for the trailer. Many clips were recorded, both from a gameplay perspective but also from Unity's Scene view. Evey imagineable aspect of the game was recorded: Platforming, pickup, throw, enemies damaging or defeating each other, throwing off a Gingerbread Man from a Rat, moving and spinning platforms. With the footage in my possession, I started trimming all the clips and placing them in a good order. Many years of experience watching trailers has brought with it a general idea of how one should look. After more editing and adding a bit of visual flair to the whole thing, I found a track that fit almost perfectly with the current edit of the trailer, so after a few final adjustments it was done. One of my best video-editing works, I must say.
Trailer now done, it was time to fix the remaining aspects of the GDD. Akash and I spent most of the night of its deadline finishing the last bits of it. Luckily not much was remaining, so while I worked on the wireframes for enemy cycles and the gameplay loop, Akash made sure everything else looked good, making adjustments as necessary.
With the trailer and GDD done, all that remained was sending in the build. The week prior, we were made aware that we could send in the game and have it displayed at XGC's ending ceremony. While we had made a build for the trailer, I realized that there were no controls present in the game. How would the people there know how to play? A Controls menu option was quickly added, working similarily to how the Credits work. While I was at it, a Story menu option that worked the same was also added, containing the story Felicia came up with.
There was also an annoying bug where the enemies' animations didn't play properly, so that was fixed. Turns out the enemies movement were being ran in Update, meaning they never reached the required speed needed to play the animations as those are speed dependant. This is also the reason why they were so slow (much smaller values being used in calculations), so I fixed this by making them use FixedUpdate, improving them in every way. They, along with the player, had another animation bug where they'd play the running animation while standing still on a moving platform, and that was fixed by only checking if any input is given (or, in the case of enemies, checking if they're idle).
I also forced the default language to English as Swedish is rather niche, and also added a blob shadow, made changes to the player physics, making camera immovable when paused, improving the goal, adding a program icon... way too much for a final polish update, basically. But, it was done, and it was sent in, ready to be displayed at the XGC finale.
A look at the bakery with the new lighting, which was made to look like it takes place at night. From a shot used in the trailer.
Week 12 (19-25 June)
The pitch had seen continuous work done to it for the past week, and with due date being here, the final changes for the pitch were made. On Tuesday night it was time. Felicia and I presented the pitch, and the people from XGS seemed to like it! They provided some good feedback, like how we basically neglected the financial aspect of the pitch (budgetary needs, competition, success/risk) and also some game design aspects we hadn't given much thought thus far (how long the game would be, what one's expected to do while in the game). All good things to think about, should it become a real game with a need for a real pitch. We were satisfied with the result of the pitch, and happy that they could imagine the end result in their heads.
One thing that made me a bit anxious though was realizing two ways the demo that'll be shown - that had already been sent in - could have been even better. In the demo we sent, there is no objective marker of any sort: You're dropped straight into the stage. Just a single line of text on the UI saying "Find the missing ship part" with an image of said part would make a big difference.
Also, I placed the goal on the floor, with the ship part placed high up on a shelf. As it is, the item you need is hard to find, being half-obscured by the shelf, but also: Players don't look up (quote from someone, I can't remember who). Once you get the item, the way back is also just a straight line. The enemies are there if you haven't defeated them, but they don't provide much of a challenge. They're relatively easy to avoid and outrun, and you can also use the main objective as a weapon to defeat them with. Switching the place of the goal and the objective would place you high up, giving you an overview of the entire stage, and would also give you a challenging platforming segment to overcome while carrying the main objective back to the ship. Definitely something to keep in mind for future development.
That was Tuesday. Now it's Wednesday, the day of the XGC finale. I'd made my way up to Stockholm where the event was held to participate in person. The event was held at Space Arena in Sergels Torg. Both Felicica and our mentor was there as well, so it was nice meeting them in person. After everyone had checked in, a final panel was held where a few people from XGS would talk a bit about the experience and the future, after which every XGC participant was brought on stage for a group photo. With that, networking night started. I'm not much of a networking guy, so I mostly sat by our game, watching people play. I got the chance to talk to a ton of people that way and hear a lot of feedback, and hearing all the positive words from everyone was such a great experience. Eventually I went away from the game and into the crowd, chatting with people until basically everyone else had left. At the end there was one group of people left other than our group of our mentor, Felicia, and I. The three of us chatted for a while about the experience and the future until we all felt ready to go home, thus ending the XGC experience.
With XGC over, we at Alien's Dozen are now left to our own devices, unhindered by deadlines and the like.What's in store for Alien Bakery in the future? Well, we all like the concept and believe in the project, only being more motivated by all the feedback. From now on, it'll be worked on as a side project, with at the very least a polished up version of the ending ceremony build ("the EC build") being worked on for release in the future.
XGC was such a great experience. Got to meet and talk to a lot of cool people, whether in person or through a presentation, and working on games is always fun. I want to give another shout out to my teammates and our mentor, Oskar Thysell. If you want to download the EC build, you can do so from the game's itch.io page.
XGC participants who attended the in-person ending ceremony. I'm the guy with the pink shirt in the front row near the middle. Felicia is standing directly to my left. Source
Ending Ceremony Demo Feedback
To end this dev log, I want to share some of the feedback we received when it was on display at the ending ceremony ("the EC build"), some other problems I discovered, and how these things can and will be changed in the future. Think of this as a "what's next for Alien Bakery" kind of tease. Some of these will be addressed in the upcoming enhanced demo, which you'll also be able to find on the game's itch.io page.
- Interact with an object: In the EC build, when you're close to objects you can pick up, they glow red. This makes them look like they are dangerous and should be avoided. There is also no indication that they can be interacted with.
Solution: Add a button prompt display when near an interactable object, and make it glow a different color than red. Also add a button prompt to signify that it can be interacted with. On a related note, if an object is picked up, add prompts on what can be done with it then. - Interactable objects: A game with tons of interactable object almost calls for every item to be interactable.
Solution: Either decrease the amount of random props in stages, or make more items interactable. - Demo stage's main objective: The EC build has the main objective placed on top of a shelf, and the stage starts at ground level. First problem is that there is no indication of what the player should do. Second problem is that finding the main objective is hard to do, as it's placed high up, and is partially obscured by the shelf it's placed on. Third problem is, once you have the main objective, all you need to do is run in a straight line to the goal.
Solution: Switch the goal's position with that of the main objective and vice versa (easier to find the main objective, makes traversing up the shelves while carrying the main objective the challenge of the course), and add something that points you toward your objective (like a Mario Sunshine camera pan). - Differences with pickups: In the EC build, what an item weighs and its scale are the only things that affect an items behaviour, leading some to be clearly better than others.
Solution: Currently, object stats are affected by their Rigidbodies only. Adding a script with changeable variables to pickups to affect other properties (e.g. jump height) could be a solution. Also, add alternate functionality that consumes the item (e.g. eat blueberry to gain extra health), or add different effects when thrown on enemies (e.g. throwing sugar at a rat consumes the sugar while speeding up the rat). This adds a bit of a risk/reward element to pickups. - Controls: Players had a hard time knowing that double jumping exists in the game.
Solution: Improve the Controls menu. Potentially add a tutorial segment or stage. - End goal: For the demo, the goal is to bring the main objective back to the ship. What else will there be to do in the full game?
Solution: Take inspiration from e.g. Mario 64: Multiple separate missions in each area. Or Banjo-Kazooie: plenty of a lot of things to do at once, whether objectives or collectibles. - Enemy interaction: Players enjoyed interacting with the enemies, how can that be capitalized on?
Solution: Add more ways they can interact with each other, e.g. special animations for certain interactions, and the aforementioned "different items do different things depending on the enemy".