Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1412425 Posts in 69791 Topics- by 58713 Members - Latest Member: MCHIGM

February 19, 2025, 03:21:33 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogs“Wright Files: Egerton's Pickle” (a love letter to C64 game “The Detective”)
Pages: [1]
Print
Author Topic: “Wright Files: Egerton's Pickle” (a love letter to C64 game “The Detective”)  (Read 15018 times)
goshki
Level 4
****



View Profile WWW
« on: November 10, 2022, 06:54:26 AM »

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” Noir




It's going to be a tiny, super-short mystery adventure drawing inspiration from a Commodore 64 game “The Detective”. The player takes the role of a Scotland Yard inspector invited to a British countryside mansion to solve the case of a mysterious fatal accident.

Or maybe it was not an accident at all? And did the butler have anything to do with it...?

Anyway, the game is being created in Unity and the visual style is a consequence of two factors: my deep affection for mixing low-poly 3D with pixel-art and the fact that I'm mostly a programmer, not a graphic artist. Gameplay-wise the game will be rather similar to “The Detective” – the player walks around the mansion and gathers clues by talking to characters, interacting with objects and collecting items. The time will flow in real-time (Durr...?) and there will also be a hard time limit (just like in C64 original). Control scheme is rather simple (movement, action, cancel) and will support both keyboard and gamepad (along with touch-screen controls, hint, hint  Well, hello there!).

Most of the story, characters, dialogues, objects, items and mansion layout is established and decided upon and currently I'm focusing on actual production using Aseprite for graphics and Blockbench for 3D modelling (do you know Blockbench? OMG it's so cool!). The work is going rather slowly (but steady!), so I expect this thread to be updated somewhat regularly, even if not too often.

From now on the development process will also be posted on:
« Last Edit: July 24, 2023, 11:32:40 AM by goshki » Logged

mobilelast
Level 2
**


View Profile WWW
« Reply #1 on: November 13, 2022, 11:48:06 AM »

An interesting project. Images look very moody already.

Wasn’t “The Detective” at least somewhat procedural? Agatha Christie -style mysteries tend to be very logical, and it would be an interesting task to make a generator to create something like them.
Logged

Avaruustaistelupeli (ATP) - a space combat game
- Free download from itch.io or IndieDB
- Dev diary here
goshki
Level 4
****



View Profile WWW
« Reply #2 on: November 14, 2022, 01:39:44 AM »

Well it is/was procedural in the sense that in-game time flows in real time, the NPCs mind their own business and the events will happen when the time comes and their conditions are fulfilled (for example, player is not in the same room that the event is about to happen). Other than that everything was rather linear and predefined (i.e. who's the culprit, what are the clues, events, etc.).

But I remember various reviews of the game specifically mentioning that there is an apparent inspiration with “Clue”. So the whodunnit-generator idea is quite in place. Smiley

Yet, at this stage of the project, I still haven't decided as to how much similar will my game be to “The Detective” in this aspect – I mean, I'd love to have some kind of a closure where the player needs to provide an explanation of what has happened using gathered clues and evidence but currently I'm leaning towards a more adventure-like finale that happens on its own when the player gathers all required information.

This part is quite fluid at this moment. Smiley
« Last Edit: November 14, 2022, 01:57:23 AM by goshki » Logged

Alec S.
Level 10
*****


Formerly Malec2b


View Profile WWW
« Reply #3 on: November 17, 2022, 10:37:17 PM »

Ooh, this looks neat!  I love the visual style, and I'm always interested in detective/mystery solving games.
Logged

goshki
Level 4
****



View Profile WWW
« Reply #4 on: November 18, 2022, 04:08:59 AM »

Thanks, glad you like it! Grin

Yes, detective/mystery solving games have this special kind of charm when compared to classic adventure games. Putting all the pieces of the story together can be much more enthralling, when done properly. But it's also much harder from development and storytelling perspective, which I've learned fairly quickly after starting this project. “The Detective”, being a fairly old 8-bit and seemingly simple game, seemed like a good candidate to serve as a base for a more modern mystery adventure. Only now I appreciate how much work actually went into this – the free roaming NPCs, the story flowing seemingly in real-time (not to mention typical adventure game features, like UI, inventory, object interaction and NPC dialogues). Quite a feat by Sam Manthorpe!
Logged

goshki
Level 4
****



View Profile WWW
« Reply #5 on: March 01, 2023, 07:24:12 AM »

Just a quick update – work on the game trots along. All the story beats, dialogues, items, events are there. Just like almost all cutscenes.

Current focus is on creating all required props to fully furnish each and every room in the game. Here's the most recent room i've got done and, as you can see, it's a “trophy room”. Wink



Also, I've got the door fully working. 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. Lips Sealed



Still quite a lot to do to call it finished but the end is definitely in sight!
« Last Edit: March 01, 2023, 11:50:19 PM by goshki » Logged

goshki
Level 4
****



View Profile WWW
« Reply #6 on: June 05, 2023, 06:27:15 AM »

Currently modelling a low-poly 3D car for introduction cutscene (turns out 3D modelling is hard even when keeping it low-poly Giggle).

Logged

nathy after dark
Level 8
***


Open Sourceress


View Profile WWW
« Reply #7 on: June 08, 2023, 10:16:45 AM »

Looks cool!
Logged

goshki
Level 4
****



View Profile WWW
« Reply #8 on: July 03, 2023, 08:19:09 AM »

Looks cool!

Thanks! Glad you like it.  Smiley

And here's something fresh – an intro of the intro cutscene. Giggle The cutscene is actually done but it wouldn't make sense to show it all here.

Logged

mobilelast
Level 2
**


View Profile WWW
« Reply #9 on: July 10, 2023, 04:54:47 AM »

Wasn’t “The Detective” at least somewhat procedural?
I remembered wrong: the game I was thinking about was “Murder!” (https://www.gamesthatwerent.com/gtw64/murder/). Might be worth checking out for ideas.
Logged

Avaruustaistelupeli (ATP) - a space combat game
- Free download from itch.io or IndieDB
- Dev diary here
Alain
Level 10
*****



View Profile WWW
« Reply #10 on: July 12, 2023, 01:18:31 AM »

I love the mood and look of the intro cutscene, great job!
Logged

goshki
Level 4
****



View Profile WWW
« Reply #11 on: July 21, 2023, 12:33:33 PM »

Last saturday marked second anniversary of working on the 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” Noir



Logged

goshki
Level 4
****



View Profile WWW
« Reply #12 on: July 24, 2023, 11:33:33 AM »

From now on the development process will also be posted on:
« Last Edit: July 25, 2023, 03:10:44 AM by goshki » Logged

goshki
Level 4
****



View Profile WWW
« Reply #13 on: July 17, 2024, 05:04:04 AM »

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).

« Last Edit: July 17, 2024, 05:09:49 AM by goshki » Logged

goshki
Level 4
****



View Profile WWW
« Reply #14 on: August 30, 2024, 09:49:38 AM »

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.
Logged

goshki
Level 4
****



View Profile WWW
« Reply #15 on: January 30, 2025, 11:38:56 PM »

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 GIF 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 GIF.

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 GIF 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!
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic