We’re continuing to work on our game after participating in Epic Mega Jam 2025. In this devlog, we share updates on gameplay improvements, visual enhancements, new ideas, and our plans for the project’s future development
We took a part in Epic Mega Jam 2025. Since our 3d artist was busy with her full time job, we knew we wouldn’t have enough time to buils proper asset pilepline, so we decided make a focus to a rendering tricks to hide the rough edges of some models. We also tried to experiment with the platformer genre. The idea itself feels very promising to us, even if the jam version didn’t fully realize it. The amount of interest and feedback we received was really motivating. Now we have clearer vision of what we want thr project to become. We decide to continue development and turn it into a more polished complete game. We’ll be using this thread as our devlog to share progress, show improvements, and talk about the direction we’re taking
Since the Jam concluded a little over a month ago, some of our early progress will be shared in retrospect, and we won’t always have older screenshots available for direct comparison.
Right after the Jam ended, we took a cold, hard look at the results ourselves. We immediately noticed significant issues with the graphics, which became our main focus point at the time.
Some of these graphical problems were quite obvious and were made consciously as a compromise due to the time constraints. However, there were also things that simply didn’t turn out well, primarily our inability to effectively handle lighting informativeness. That is, we struggled to use light effectively to convey necessary information to the player.
Here is an example to illustrate this point. In this screenshot, the transitions between the walls and the floor, as well as the fans, are clearly visible. However, we realized we didn’t need this level of detail (informativeness) in the background elements. If we could have diffused this information using less specific lighting, it would have allowed us to conceal the crudeness and lack of texturing on those models.
But during the Jam, no matter how we adjusted the lighting and post-processing, we couldn’t achieve the desired results.
Furthermore, we encountered strange colored patches and unexplained excessive specular reflections in certain areas. We also struggled to correctly configure the stylizing post-process effects. Specifically, the outline thickness was dependent on the screen resolution, and the color grading gradient inappropriately shifted the original texture tonality.
Initially, we suspected the stylizing Post-Process material, which was essentially assembled in half a day and barely tested. Therefore, we completely rewrote it. While the core logic remained the same, the semantic structure was significantly altered. This fixed the outline issues and resulted in much more user-friendly customization methods. Crucially, however, this rewrite did not resolve the mystery spots and excessive specular reflections.
The issue with the spots and reflections was found much later and entirely by accident, and frankly, it was incredibly stupid (the classic dev log revelation). We simply had the outputs for the AO (Ambient Occlusion) and Metallic channels swapped in our base material setup. Essentially, this meant our models had metallic properties in strange places. The environment reflections hitting these metallic areas created the bright spots, resulting in the odd colored patches and unwanted gloss.
The lighting, however, proved to be significantly more complex. It’s difficult to explain all the intricacies concisely (and I’m not sure everyone would be interested in a deep dive). Essentially, all our issues stemmed from a lack of theoretical knowledge.
It turns out there’s PBL (Physically Based Lighting) in addition to PBR (Physically Based Rendering), and we lacked a fundamental understanding of HDR (High Dynamic Range). We found that clear and easy-to-digest information on this subject is surprisingly scarce.
In short, we had to overhaul every single setting related to lighting. We worked on aligning tonalities and colors to ensure they didn’t shift after being imported from graphic editors, and made numerous other adjustments.
The result is a much-improved visual look (see the updated screenshot!). Since the core level geometry hasn’t been significantly processed yet, the final game environment will look even better than this.
While it might not be immediately obvious in the recent screenshot, the majority of the problems have actually been resolved.
Don’t mind the background fans being excessively dark-they are currently using a black chrome material purely for testing purposes.
If you look closely, the informativeness of the image has greatly improved; you can now discern far more detail. Crucially, the excessive saturation is gone. The textures now appear in the engine as they were originally designed (like in the current image). The previous lighting incorrectly boosted the saturation, making them look overly vivid. This was problematic because while it’s easy to increase saturation on a texture in a graphics editor, it’s inconvenient when the appearance differs drastically between the editor and the engine.
Furthermore, you can also see that the on-screen elements (the control prompts) are now much clearer and more legible.
Next we received some interesting feedback:
Pixie feedback Marko Sovljanski.pdf (104.0 KB)
There were a lot of messages and reviews, but they were all along the lines of “Very good visual style!” That lets us know someone liked it. But using feedback as input is only possible at the emotional level. There are also specific questions and suggestions, which are something we can work with.
Some of the problems described, especially the visual ones, are simply a lack of time, and we just need to work on them. And there are things we haven’t noticed yet, and we need to think about them.
”Camera rotation is laggy and sometimes it’s too close to the character.”
I can’t remember exactly what kind of interpolation is used for camera rotation, whether it’s double differentiation or crit dump. The lag is essentially intentional, but as far as I understand the message, it’s either unnecessary there or needed in a different form. Since I don’t have much expertise on platformer cameras, I’ll look at how it’s done there, compare it to what’s currently available, and try to implement it without it (and I need to think about how to gather better feedback). But I’d like to discuss this in more detail with Marco; I’ll try to invite him here.
Yes, regarding the fact that the camera is too close to the character, the problem is clear and it interferes with the game in some places, but no one has solved it yet.
“Character walking animations have no animation blending when changing direction. The flip is performed rather slowly so all animations feel like they are happening almost at the same speed. It would help that when we jump there is a more exaggerated jump pose with more bent legs and ears (antennae) and then when we roll it happens more suddenly and swiftly. In general just the act of moving and jumping should feel amazing even if we aren’t crossing any obstacles. Sound is very important here and it needs to accompany all animations. If the character slides there should be a sliding animation with a clear start and stop pose.”
We always have problems with animations because we’re weak at them, and here we were under a very tight deadline, so we did the bare minimum of animations just to make them work.
Well, I did hear some advice on animations, but I’d come back to that later when we’re working on them, simply because right now, animations are essentially placeholders.
“And very importantly a clear death animation with the sound. This character can simply explode in pieces suddenly when dead. It could all benefit from being snappy, clear instant. At least when we press the button or move the mouse. If you want you can still keep the gravity low since it is not tied to player input. There is a lot of opportunity for a very cool animation set here, this character can have a ragdoll, roll around spin on the back and shake legs like a bug or anything else. Just be more unstable and active or rather reactive.”
Regarding sound, we had a story where several people wanted to work on it, but no one ended up doing it, and it was being worked on in the final hours, somehow. Regarding our weak player feedback, I also understand that it needs to be addressed.
This is actually an important comment, because many things get forgotten during development, and it’s important to remind ourselves of them.
“What is most important here is clarity of obstacles. Platforms that are to be jumped off of and on to could have tapered sides in different directions then now, making it clear that its a sharp ledge rather than an edge to slide.
Also when jumping onto platforms sometimes I hit the edge or get stuck a bit between the edge and a wall. These collisions need to be flawless. Because of the laggy and floaty way the character moves and uncertain collision detection makes the platformers flow fragmented.”
We initially took a different approach to this issue, but we simply couldn’t implement it properly in such a short timeframe. The idea was to make a platformer with slightly more interactivity with the environment. Starting with the idea that jumps and dashes would vary depending on the surface, angle, and number of standing feet.
I tried implementing this in Character Movement Component, but experience has shown it’s impossible. It’s actually easier to rewrite it for this task. And I’ll likely explain the problems later.
And along the same lines, there are all these stories about physics, reaction precision, and so on. This is a purely technical issue that I’m currently solving.
“I need to stop, compose myself, then go again, stop again etc. There is a missed opportunity
here I feel that would enhance the experience, to make all traps have a timer of a kind that is
creating anticipation. A visible timer, for example before spikes go out they are slowly heating
up, when fully hot they suddenly pop. Things that create tension. On top of that maybe the rest
of the level that you went through is falling apart. Maybe that is pushing this concept too far
outside of the setting of the industrial area. Maybe it just transforms making it impossible to go
back. Another thing that would help us create rhythm would be if we had anticipation with traps
we can have clear save points that make us realize that in fact it’s a checkpoint and we are safe.
Gives us some rest and a short term goal. The level design is all about this building tension,
releasing it. But then subverting expectations. It’s like a dramatic structure in plays and movies.
At the end I would try to make more clear how mechanics work and are introduced. One way to
do this is to have a supplementary gameplay mechanic where you are solving a puzzle and only
when you apply a correct set of movement the puzzle is solved and you can pass onto the next
area.”
Regarding level design and readability feedback, this is being handled by someone with relatively little experience, and we’ve come up with a plan where we first build the level keeping in mind some more basic things, like a gradual increase in difficulty and the idea that each room allows us to explore a single concept. Then we make several more passes at the level, checking other things like readability, game rhythm, and so on. But during the jam, it was initially a bit of a hustle and bustle, and nothing was working at all, and by the end, the person had gotten a grip and was able to complete just one pass, not everything.
At the moment, we want to work on the basic mechanics and build levels around them.
The section on level design goes into more detail about how to solve these problems, and I agree with all of it. But it’s very difficult to discuss and think about it at this stage. Simply because level design is built around gameplay mechanics and player objectives. And at this stage, those essentially don’t exist yet.
But when we get to that stage, I’ll sit down and reread it all again.
Regarding the last part about the visual component.
To be honest, except for the robot, everything was done extremely quickly and carelessly. Simply because the modeler didn’t have any time at all. There was an attempt to disguise this with properly adjusted lighting. But within the confines of the jam, that didn’t work, and a slightly more complex render, which essentially salvages the image, was necessary. And there was no thought (consciously) put into it at all. So, we’ll work on this soon and discuss it again, I hope.
Hi @OrcParty welcome back! This looks like a really fun 3D platformer! The character feels really unique, and the puzzles seem really fun. I was wondering if you might add a bit more variety to the background objects later on even some light texture changes on the walls could help things pop a bit more and make the whole thing feel even more polished.