vigeogames

[vigeogames]

Long time no #screenshotsaturday – new title screen for Wright Files: Egerton's Pickle! 🥳

[vigeogames]

Woot! All the cast for demo of “Wright Files: Egerton’s Pickle” is ready! As you can see, most of the visuals have been redone – all the characters have new sprites and finally the locations are mostly complete. Time to wrap this thing up!

[vigeogames]

Cheat codes are mostly gone from video games – and it’s a bad thing

In today’s game development/design musings let’s discuss: cheat codes! Do you remember them? Do you miss them? I do and do. And for quite some time, it’s baffled me how few players recognize the disservice done by removing cheats from video games.

But before we go further, I’d like to clarify that by cheat codes (or cheats) I mean any mechanism – be it some key sequence, button combination, or action that can be performed at some specific moment or at any time – consciously embedded in the game itself by the developers to let the player alter game state in a way outside of standard rules of gameplay (for example, accessing a specific level, removing time limitm getting more lives, ammo, better weapons, etc., becoming invincible, or having enemies ignore you).

Initially, cheats were added as a way to provide the developers themselves with an easier way of testing the game during development. Game creation usually requires multiple, repeated playthroughs of a specific section of the game, and being forced to start from the beginning every time is impractical for such scenarios. It actually makes this process impossible for longer/harder games (I’m referring to times when game creation tools were not as sophisticated as now and it was not that easy to, let’s say, launch the game in a specific state or level). But with a cheat code that lets a developer (or tester) skip right to a specific level, it’s easier and quicker to focus on what’s important in a given development phase. Cheats were usually left active in release versions of the game, and it was a matter of time before they were discovered (or leaked, or – as in the case of level access codes – provided by the game itself as a form of reward for completing a certain level). Once public, players could choose whether to use them or not.

And here’s the kicker: one of the unintended side effects of cheats was that virtually every player – no matter their skill – was able to experience every part of the game. I’m not saying they got to beat it fair and square. They got to play every section of it even if not exactly as intended by the developer. Thanks to cheats, they actually got to tinker with the game in any way but intended by the developer. They could skip some part of the game they deemed dull. They could feel godlike obliterating baddies with a bazooka they were not supposed to have yet. They could blast through boss fights they were not skilled enough to challenge. They could fast-forward through a 30-hour-long game when their adult life granted them only one hour of playing games a week. Yes, it was cheating. Yes, it broke the game in some way. But you know what? It was OK. The only person for whom the game was broken was the player. And they knew exactly what they were doing when using cheat codes.

Another thing I’m puzzling over is how players seem completely unfazed by the fact that they pay real money for games and then do not get to experience them in a somewhat complete form if they lack skill or time. Some games are hard by design, I get it. But does it really hurt anyone if the player makes it easier just for themselves because they really enjoy the game and would love to enjoy also the parts they cannot access with their skillset? After all, they’ve already paid, right? You don’t pay for seeing a movie and have the director regularly pause and confirm that you’ve paid attention close enough to be allowed to watch it further. You don’t buy a book and have the author regularly check if you’ve understood the plot so far and can access the next chapter. Interactivity of games does not change the fact that it’s still entertainment and the player paid to be entertained. And it’s not about having “git gud” mindset either; not every player plays a game thinking that they need to “earn” access to further content. Or to get all (sometimes overly contrived) achievements. Or to prove anything to anyone. Or they simply may not have those 30 hours at their disposal.

So yeah, cheats. Players have learned to play without them. And to just drop a game they’re not good enough (or cannot spend enough time) to experience fully. As a player, do you miss being able to see all the game has to offer? As a game developer, are you OK with not providing such option? Adding it as a microtransaction does not count.

P.S.: It can be argued that mods may be used as tools to modify the game in such a way that it’s easier for the player. But they’re not embedded into the game and their purpose is usually different. Besides, they’re mostly available for PC games only.

[vigeogames]

CSI: Character Scale Investigation – The “Wright Files” Chronicles

It’s hard to deny that things have been somewhat quiet regarding “Wright Files: Egerton’s Pickle” for some time now. Development work stalled towards the end of 2023 (I wrote about this – and the reasons – in an earlier post from July 2024). However, this doesn’t mean that nothing has been happening on the development front. Actually, most of what I’ve been working on in the meantime is essentially an evolution of the technology that I use in “Egerton’s Pickle” (yes, I’m that classic hopeless case of a game developer who, instead of simply finishing the project and publishing the game, constantly improves and polishes things that no player will ever see, i.e. technical guts of the game). Today, however – in another technical post with another cliche title – I’d like to show something I’m really proud of (and which most players will probably either not appreciate or ignore completely).

I’ll start by saying that from the very beginning, one of my fundamental assumptions was that “Egerton’s Pickle” is going to be a retro-style game (both visually and gameplay-wise). This is largely tied to my fascination with games from the transition period between 8-bit and 16-bit computers (the era when typical screen resolution was 320x200 pixels, when pixel artists just started to notice that pixel-art can actually be art, and 3D games were still in their infancy with no one yet thinking about texturing, shading, or anti-aliasing). The aesthetics of games from that period were largely dictated by hardware technical limitations. Today, such aesthetics are a conscious artistic choice driven by nostalgia, economic considerations, or the creator’s technical abilities (in my case, all three reasons are equally important).

In the case of “Egerton’s Pickle” the retro visualization is tied to three aspects: low-polygon 3D environments, 2D sprites, and low resolution (around 320x200 pixels). The first two aspects are largely dictated by economics and skills: my graphic abilities are limited, so simple (not to say primitive) 3D environments and low-resolution 2D sprites seem to be within my capabilities. The low resolution is a nostalgic-economic choice – it’s easier to hide graphical imperfections when you’re displaying pixels the size of Minecraft blocks.

After starting work on the game (around July/August 2021) and creating several visual style prototypes, it quickly became apparent that combining the aforementioned aspects in the way I envisioned would be challenging. This is mostly to the fact that while combining 3D scenery with 2D characters is trivial and has been used since Wolfenstein (if not earlier), achieving precise control over the appearance of displayed objects in low resolution requires some work. It’s manageable when the game uses an orthographic camera view (like isometric or top-down). The real problem begins with a perspective camera view, where objects shrink as they move away from the camera. Remember 3D games with 2D characters and freely moving cameras on PlayStation 1 (PSX)? They looked horrible. Really awful. It’s a miracle players could even decipher what was happening on screen. For this reason, I’ve decided that yes, “Egerton’s Pickle” would have low-polygon 3D scenery and 2D characters, but everything rendered in high resolution. However, I kept returning to the original idea of achieving the graphic style I had envisioned in various side projects.

And this brings us to the gist of this post – presenting the results of my latest game graphics styling test. I feel I’ve finally achieved an effect that well combines all the previously mentioned aspects, and the breakthrough moment came when I adopted the assumption that 2D sprites should maintain a constant size regardless of their distance from the camera. At this point, it’s worth mentioning that such an assumption only makes sense with very specific game world presentation parameters. For example, it won’t work at all in a situation where a perspective camera view shows a game area far away. In such a situation, a 2D sprite of the same size both near and far from the camera will look very strange and will probably confuse the player. However, “Egerton’s Pickle” uses a fairly limited view of the game world (divided into rooms seen from above, so the convergence of perspective lines and resulting scene depth is minimal), making such an assumption sensible.

It’s best to show this graphically, so below is an example scene using the trick described above in low resolution – each character maintains the same screen size at all times:

Constant sprite size is most noticeable if you look at Manfred (the butler, in the blue suit) at the beginning when the camera moves toward the center of the entrance hall and he’s quite far from the camera.

For comparison, the video below shows the same scene in high resolution, but character size changes with their distance from the camera (as perspective dictates):

This was the display method I adopted after the first failed prototypes. Pay attention to Eugene’s height (the main character in glasses and fedora) when he goes through the portal to the next room, or when he stands by the grandfather clock in parlour. The height difference is easy to notice when compared to the first video.

And the final comparison: the same scene in low resolution with character size changing based on their distance from the camera:

This best shows the problem that discouraged me from using this method – as characters move away from the camera, their sprites decrease and pixel-art deforms, resulting in a very unpleasant visual effect. This method is visually correct and useful for scenes with great depth, but only if we accept ugly downscaling of sprites (similar to Wolfenstein or Doom). Side note: texture interpolation could have been used to downscale the sprite more evenly but this would be only usable for high resolution. In low resolution interpolation would result in highly blurred sprites with most of the details lost (which would probably look even worse that what can be seen above).

In summary, the visualization shown in the first video is currently closest to what I envisioned for “Egerton’s Pickle”. At this point, I can’t say whether it won’t cause new visual problems that weren’t there before (which would again force me to return to the version shown in the second recording). I know it’s not a universal solution and only works within a very narrow range of game world presentation parameters, but for my purposes it seems quite well-suited and I believe it adds charm to the game.

I’m curious about your opinions – is the difference noticeable to you? Would you be interested in a more precise technical description of the entire solution? Let me know in the comments!

[vigeogames]

The Case of a Thinky Game Bug

For the last couple of months, I’ve been struggling with a really obscure and elusive bug that has cost me quite a lot of hair-pulling. Today, I finally solved it. It turned out to be such a bizarre combination of technical issues, Unity engine specifics, and plain sloppiness on my part that I need to write it down just to vent.

The story starts in late November 2023 when I was two and a half years into the development of “Wright Files: Egerton’s Pickle”. At that point, I was kind of fed up with the project and decided that I needed a break. I wanted some quick and easy, low-effort diversion to let my brain cool off. By pure chance, I came across the Thinky Game Jam (TGJ) that was planned to start at the beginning of December 2023 and last for two weeks. It looked like a perfect opportunity to start a short and simple side project that would give me new energy to finish “Egerton’s Pickle” (obviously, this side project turned out to be neither short nor simple, but that’s a different story).

I started work by doing what solo indie game developers typically do in such cases: copying the whole project folder into a new location and reusing as much of the code and assets as possible. Now I need to get a little bit technical. As this is a Unity project, I’m using ScriptableObjects extensively. ScriptableObject is a type of asset that lives inside the project whether the game is running or not (including in the editor). This is really convenient as it makes it very easy to persist and pass various types of data between different scenes, levels, and in the editor itself. At that point in time, I had also been using the Unity Atoms library, which makes ScriptableObjects even more awesome. Thanks to this setup, I was able to build the logic of the game (story, gameplay events, gameplay event reactions, etc.) out of reusable blocks that could be added, deleted, and recomposed without needing to touch the code. For example, I could configure a reaction for interacting with a specific NPC, and this reaction could consist of several specific actions, like adding an item to the player’s inventory, opening some door, or simply setting the value of a gameplay state flag. All these reactions were stored in a dedicated ScriptableObject type that I’ll call story controller. For the TGJ side project I’ve created a separate story controller with separate gameplay event reactions and actions.

Now, Unity Atoms is a really advanced library, packed with tons of features. This is both good and bad. It’s good because it can do many things out of the box and supports a lot of use cases. It’s bad for the same reasons: it can do many things out of the box and supports a lot of use cases, which makes it cumbersome to extend or omit features that are not needed. Because of this, I had been mulling over the idea of creating my own library that would be simpler and less advanced than Unity Atoms, but at the same time would be leaner and more focused on the feature set I actively used. However, I didn’t want to start working on this so late in the development cycle of “Egerton’s Pickle”. Yet, after a week of the TGJ, it suddenly became more tempting to reconsider, as I now had a small and more focused playground project and adding new features based on Unity Atoms seemed to slow me down.

This is also when the TGJ project started to slip and eventually missed the deadline, because implementation of this new library (I called it Mites because, you know… atoms) took almost three weeks. With the deadline missed but the library coming along nicely, I decided to dig deeper into refactoring and started exchanging parts of the story controller based on Unity Atoms with similar elements (gameplay events, gameplay event reactions, etc.) based on Mites. I was really proud of myself because this new architecture made it possible to create much more advanced gameplay event reactions and actions with more elaborate conditions and whatnot. As a last step of refactoring, I changed the type of objects stored in the list of reactions in the story controller’s ScriptableObject while retaining the name of the variable.

If you’re a programmer (especially a Unity game developer), you’re probably starting to see where this is going. Now I’ll get a little bit more technical again to explain: in Unity, all assets backed by code (MonoBehaviours, and ScriptableObjects) exist in a kind of dual mode that enables persistence. The editor instantiates them in an editable/runtime form based on their definition from code but also stores them in files in a serializable format (also based on their definition from code). This usually works fine, but data corruption may occur when the underlying code definition is modified. In such cases, Unity’s deserialization mechanism will do its best to fix the corruption, but typically all it can do is clean up corrupted data and instantiate the object without the broken elements.

Data loss due to corruption might not become evident until much later, and this is exactly what happened in my case. Some time passed, some more refactorings were performed, and suddenly the story controller started throwing errors during gameplay. The errors seemed random and rare at first but became more frequent recently. Usually, once an error occurred, I was only able to make it go away by restarting the Unity editor. But since yesterday, it became permanent and repeatable every time, at the same moment in the game. The strangest part was that even though the TGJ story controller had ~30 gameplay event reactions attached, it reported exactly 74 null reactions attached every time the error occurred.

Actually, the only reason I was able to trace this error down was due to another technical aspect of ScriptableObjects related to their lifecycle. ScriptableObjects live outside of the currently active scene, so they can react to various events even if the game is not running. In the case of the story controller, this means that it starts to listen for gameplay events when it is enabled (i.e., when the game is launched in standalone mode or when the game project is loaded in the editor). After several long debugging sessions, it finally became evident that the error came not from the TGJ story controller but from the “Egerton’s Pickle” story controller copied over from the original project and lurking in some long-forgotten folder. And the actual reason why it was throwing errors was because I had changed the type of gameplay event reactions from Unity Atoms to Mites, and Unity was not able to correctly deserialize 74 reactions persisted in the story controller’s file, so it just instantiated a list full of 74 null references. And when I run the game in the editor and gameplay events started flying around, both story controllers started reacting to them but the one for “Egerton’s Pickle” tried to react with null reactions. How convenient. FML!

Good thing is that once the error was traced down, I was able to fix two issues – corrupted list of reactions in “Egerton’s Pickle” story controller and making sure that only one story controller reacts to gameplay events during runtime.

And the moral of the story would be: if you’re a game developer, be careful about what you copy over from previous projects and what testing and refactoring leftovers remain unattended in your current project. Copy-paste errors exist and can hurt you. Or even cost you $36 Million.

[vigeogames]

Third year of “Wright Files: Egerton’s Pickle” development

Last Monday marked exactly the third anniversary of starting work on my tiny, super-short mystery adventure game, which was supposed to take a maximum of 6 months to develop. In a few days, it will be exactly one year since I publicly revealed the game (optimistically assuming that I would manage to finish the game by January 2024). And yet here I am on a day when, despite three years of development, not only is the game still not released, but it can be openly admitted that it has not been actively developed for almost a year.

However, it wouldn't be entirely true to say that work on the game has stopped completely. I simply did what I do best – I started a new, smaller side-project (which was supposed to take a maximum of 2 weeks). But let's start from the beginning.

I keep a fairly detailed work journal, so I can easily trace what happened over the last 12 months that led to the disruption of game’s development. And quite a few things have piled up! The first distraction came in July 2023, when Twitter began transforming into X (by the way, for me it will always remain Twitter). However, this was nothing compared to what Unity served us in September 2023. The commotion caused by the announcement of plans to introduce a runtime fee flustered me so much that for a long period I wasn't able to muster even a bit of motivation to work on the game (especially that I was already struggling with 3D asset creation for all the props I wanted to have in the mansion).

Of course this does not mean that I was doing nothing development-wise. I’ve just started procrastinating heavily, looking for every possible excuse not to actually work on the game. And the excuses were plenty: toying with Godot as an alternative for Unity, resurrecting my old prototypes, creating new prototypes (i.e. delving more into low-poly 3D + pixel-art visual style, testing new code architecture ideas, prototyping an Android application to play YouTube music in the background, etc.). Wherever you look, always something more interesting to do than to grind on parts I’m not comfortable with.

And then, at the end of November 2023, Thinky Game Jam has been announced. If you’re not familiar with TGJ, it’s a game jam focusing strictly on “thinky” games: puzzles, mysteries, investigations, detective games, etc. Have you noticed “detective games”? Yup, that sounded like a good justification to get me back on track – to participate in a “detective games” jam by creating some really small detective micro-game using code base of “Egerton’s Pickle”. This also aligned nicely with my overarching idea of making a series of episodic adventure / mystery / detective games with the same main protagonist within the same universe (thus the “Wright Files” prefix). This micro-game would serve as a complement to the story presented in “Egerton’s Pickle” depicting the history of the friendship forming between the main protagonist and Charles Cavendish.

In retrospect, this was exactly the moment when the “Egerton’s Pickle” has landed on the shelf for an indefinite period (that is, essentially defined – at least until the end of work on the micro-game for TGJ). Two weeks to complete seemed like a quite reasonable deadline, and initially, work was progressing really smoothly. The initial scope was small, and most elements were already implemented in the main project. I further simplified some parts (e.g. dialogues) to reduce the amount of work required. But then I hit the same issue as with “Egerton’s Pickle” – 3D assets. The TGJ has ended and I’ve had about 80% of mechanics and 20% of props and level design. Again, I’ve bitten off more than I could chew.

Yup, this is the bane of me. I’m a programmer first and everything else second so all other areas of game development are a challenge for me. That’s why I struggle so much with visual side of my games and why I try to simplify it as much as possible while striving for something more than simple 2D top-down graphics.

Right after TGJ concluded I’ve decided to push on with what I’ve done until then telling myself that there was so little left to do. That the story and mechanics were ready, that I just needed to get through finishing the visual side of the project. How long would that take? A month or two, right? And then came the usual case of scope creep because not being able to get the style I have envisioned, I’ve started to look for the ways to make the game more interesting mechanics- and story-wise. I’ve also decided to refactor substantial part of game’s architecture to streamline elements I was not comfortable with (or I found limiting) during development of “Egerton’s Pickle”.

And yet here I am on a day when, despite 8 months of development, the TGJ side-project is not done. It’s also bigger in scope and more advanced architecturally than what I’ve had when TGJ has started. The only consolation is that I'll be able to use all the improvements implemented in this not-so-micro-anymore game to finish “Egerton’s Pickle”. Oh, wait! I think I told myself something similar a couple of months ago.

P.S.: Here's a small GIF to lighten the mood a little (let this door situation be a metaphor of me trying to actually finish this project).

[vigeogames]

Still doing what I'm best at: chipping away on a little side-project (started during last year's Thinky Game Jam) while taking a break from finishing “Wright Files: Egerton's Pickle”. 😅

[vigeogames]

Wright Files: Egerton's Pickle on Itch.io and GameJolt

My tiny #detective #mystery #adventure #game “Wright Files: Egerton's Pickle” now has a page on Itch.io, GameJolt and IndieDB! 😄 Follow the development at:

Itch.io: https://goshki.itch.io/wright-files-egertons-pickle

GameJolt: https://gamejolt.com/games/wright-files-egertons-pickle/712868

IndieDB: https://www.indiedb.com/games/wright-files-egertons-pickle

#gamedev #indiedev #indiegame

[vigeogames]

Last saturday marked second anniversary of working on my tiny #detective #mystery #adventure #game. Seems like a good time to reveal game's title in a hastily created trailer.

So without further ado I present to you: “Wright Files: Egerton's Pickle” 🕵️‍♂️

[vigeogames]

And another update regarding my tiny #mystery #detective #adventure game! The car is ready and so is the intro cutscene.

P.S.: Here you can see just the intro of the intro cutscene because you know… it will be best to watch it in-game and not in-a-post. 😅

[vigeogames]

Back to work on my tiny #mystery #detective #adventure game. Currently modelling a #lowpoly 3D car for introduction cutscene (3D modelling is hard even when keeping it low-poly 😅).

[vigeogames]

My low-poly terrain generator toy now has terrain patch recycling, wavy ocean and a three-wheeler to drive around (powered by TopDown Engine by More Mountains).

The generator pre-computes vertices, triangles, normals and colors for all quads in each terrain patch at load-time and then uses a pool of terrain meshes to only display patches that are actually visible in camera frustum – nothing is stored in the scene, the generator is able to fully reconstruct the terrain in runtime. The ocean surface always follows player's vehicle (a trick I've seen used in “A Short Hike”) to minimize amount of calculation for waves.

Btw. is it obvious that I'm trying to recreate the vibe of Zeewolf from good old Amiga times? 😅

[vigeogames]

New fancy feature in my low-poly terrain generator toy – height areas (with slopes supported). Nice for enforcing some flat land for buildings, roads or landing pads. 😎

[vigeogames]

I'm having way too much fun with this, so I'll just share. 😁 I'm making a low-poly terrain generator that let's you compose different generators and operators. You can remap generator values, clamp it, add falloff (with several peaks), etc.

Currently I'm working on an island shape editor that will let you apply a falloff in a shape based on a provided list of points. Oh, and the generator accepts instances as well as references to generators/operators from ScriptableObjects to compose them into reusable blocks. 😎

P.S.: For now I'm using LibNoise.Unity as a base for generators/operators but also extending it with several of my own (i.e. remap, fallof and island fallof operators). 🙃

[vigeogames]

Using ChatGPT for simple procedural content generation

TLDR; ChatGPT can be used to generate procedural content with a set of rules but time spent writing those rules may quickly become much greater than time required to implement them in a programming language (which gives you much better control anyway).

A couple of years ago I've created a JavaScript snippet that generates names for animal teams. Recently I started wondering if such content generators could be created using ChatGPT and what are the limitations of such usage.

It turns out that ChatGPT is capable of emulating such generator when provided with a set of simple rules:

With the above rules it's possible to get different results with additional requirements provided:

The probability requirements can get quite explicit:

After several (many) attempts with different approaches some caveats became quickly visible:

the more specific the rules get the greater risk of breaking the “algorithm” – for example I spent a lot of time trying to force the rule of using default probability of 100% for each component and make it customizable only by user input but couldn't get it to work (and it turned out that probability customization is available even if not mentioned)

it's easy to go down the rabbit hole of finding specific wording to make it work better and fail

the results seem rather finicky, using the same exact prompt of rules in fresh conversation yields different results (for example I couldn't get ChatGPT to add n_adjective and n_adverb on some fresh conversations with the same set of rules)

[vigeogames]

You've probably seen that cool “Game Development Difficulty Tiers” infographic by @richtaur and unsurprisingly implementing doors are the top-tier.

Luckily I've got'em already covered in my tiny #detective #mystery #adventure! Even the NPCs get a hang of the doors – up to the point of being jerks and closing them right in front of your face. 😅

[vigeogames]

Another update regarding my tiny #mystery #detective #adventure game: here's the most recent room I've got done.

As you can see, it's a “trophy room”. 😉