momoirosoftware
patreon
Technical Overview: How Our Apartment Has Changed Internally
🕑 Added 2022-08-02 18:33:29 +0000 UTCSome people have expressed the last update was, “disappointing” for them. There’re various reasons why. I try to keep expectations in check, but sometimes people can get the wrong impression. Maybe they read one post and not another, there’s only so much that can really be done. The progress being made is a big deal to me, but for an end-user unless it’s real content they won’t really see that.
And that’s perfectly understandable.
So, I figure a more detailed dev update is in order. I’m going to explain in detail what has changed internally from older versions of Our Apartment. How previously intended goals has been improved upon, and discoveries made. And how the way things were done before are completely unacceptable for the long term, and how they needed to change. The explanations should generally be in layman’s terms, and a good deal will be from memory but should be fairly accurate.
Maybe some people won’t read all this, but I can say it’s there and if someone wants to know why the game isn’t what it was before they can at least skim this.
Also understand this is largely covering the programming/design side, much less art and writing, design and such. I’ll write posts about that later.
This is going to be a long one...
Handling Data: Our Apartment Preview
Let’s start here, easily the biggest challenge in both Our Apartment and likely many games in general. This aspect is probably what’s changed the most and dictates the most change across the project. This is the nexus of most of the change Our Apartment has gone through.
This is not about save data, this is about object data. Characters, animations, dialogue triggers, giving the game the information it needs to do what it needs to do.
In Our Apartment Preview, one thing you might have noticed is that the game loads the Apartment scene, and simply stays in that scene for throughout the play. This allowed me to do direct “Scene References” literally everywhere. That means with one level, one “Scene” I could just tell the game “Here is this object, do stuff with it”. The game doesn’t need to “look” for the information.
This makes everything pretty performant; you just point to the thing in the editor, and it does it. But this has several consequences even in just the short term.
- If something changes you often must remember every scene reference and change it.
- You cannot save reference between objects within prefabs, this makes management more difficult.
- You cannot save object references between scenes, so even the Preview was limited to one scene even if I could make more.
As a result, adding new content would become more and more difficult. More interchanging data between scene objects, having to make a lot of scene changes and look through lots of hierarchies. Worse if I intended to collaborate and hire people, they would have to avoid working on things at the same time and the single “scene” is the only thing they can work in. That would make collaboration impossible.
Sure, the game worked, but If I wanted to make a ton of content and expand the game things had to change. There were also some issues for the player:
- The game loading in scene view meant if the device ran out of memory on first load it would simply crash. Not even allowing the user to adjust quality settings
- Adjusting quality settings could cause a crash
A lot of people consider Our Apartment Preview (b22) the best version of the game so far, but that version of the game would have been extremely difficult to add new content to. So, I decided to polish it up as much as I could and leave b22 as the final version of Our Apartment Preview. This was December 2020 just before new year’s.
Handling Data: Our Apartment 2021
So, Our Apartment Preview achieved what I wanted, it was proof I could make something of a sim game, and it was decently quality. But now it needed to be a proper “Game” and it had to work long term. Our Apartment Preview was just a “scene viewer”, an easy enough concept.
Our Apartment was always intended to be a sim game, but I’ve always been skeptical of my ability to deliver simulation gameplay even after the sex sim worked on a basic level. Things like how to handle progression, how to make leveling up functional and impactful felt like they would add a significant burden. That’s why at this point I hadn’t fully committed to making a sim game. I kept things cautious. I was worried about how dependencies would be impacted.
As a result, I didn’t factor the concept of things like stats, persistent numbers, and adding deeper sim elements to sex sim. The projection was, Sex Sim was good, but the game needs a game loop that allows engaging with it (along with invoking the feelings I wanted), and it needed a way to activate story dialogue.
At this point there was a few goals data wise…
- A lot of the game data needed to be decoupled from each other, no longer relying on direct scene references. Basically, needed data would be “found” thus mitigating scene dependent issues. This would allow saving “prefabs” without needing to sync a whole scene.
- Eventually I accepted it’s an issue to have the whole apartment loaded from the title screen. So, there would need to be an initialization scene. This was added with the new UI, with the prior desire to decouple making it easier but caused a big rewrite. Now the whole UI was entirely separate from the actual game objects.
- Outfits due to their sheer volume needed to be loaded into memory rather than stored persistently.
- The game needed a proper Game Manager which Kaitou started on at some point. No game manager existed before; many individual things just did shit.
- This one is most impactful way beyond technical reasons. I don’t want Our Apartment to be one game made for one character, I want it to be a foundation for the long term. I want its design to be as ambiguous as possible so that more games with new characters, and new genres can be made more easily. Not just to make games like Our Apartment, but other potential genres with lewd content. Maybe Naomi isn’t for everyone, maybe Our Apartment is too vanilla, well this games code base isn’t intended to be limited by that.
To explain a little further look at it like this hierarchy...
Scene 1
- GameObject1
-- Scripts
- GameObject2
-- Scripts
Scene 2
- GameObject1
-- Scripts
- GameObject2
-- Scripts
Scenes contain game objects, which game objects within a scene can reference each other directly (think drag and drop) but referencing data between scenes/levels means that when the scene loads it needs to "Find" necessary data or game objects which contain the functions needed.
But also, it's not ideal to have references between particularly separate root objects (GameObject1 and GameObject2) even within the same scene for a lot of reasons. Instancing, accidental reference loss, etc...
So now we have:
- Init Scene: Contains UI, Game Manager, Stuff for Sound and music management
- Apartment Scene: Contains Naomi and Player and all their scripts and managers, their cinematics (dialogue scenes, sex sim, etc), relevant SFX, objects they may interact with.
- Repeat for any additional scenes like the Cafe.
It’s hard to remember exactly what was done at the time cause even from this the game is largely so different now. But one thing I know is the performance concerns doing all this caused.
See, “Find” functions while necessary are very slow. You have to think about how a computer finds things among a group of data. So now the GameManager is in an initialization scene separate from Naomi, Naomi cannot be in that “Init” scene because there’s many aspects that are still scene dependent. We decouple as much as possible, but much is unavoidable at least not without a significant amount of work.
So, when the apartment scene loads the game needs to find Naomi and other objects and characters. And additionally other game objects need to find the game manager.
The game manager needs to find sex sim to start it, then sex sim needs to find Naomi and the player to place them in the scene and start their animation, then they need to find their properties so that the arousal data and stuff like “likes” can be processed.
The worst was that this all need to be reliable, cause if for some reason the game failed to find the object the whole game would break. And this was possible, I don’t know why but sometimes a find function would just fail. Maybe it was timing, or other factors.
At this time and for releases I started a “tagging” system, basically I would make empty components and tag objects with them. I saw this in an asset I used to use. Unity is apparently fast at finding components. So, I had a setup where there were parent objects that would find these “tags” in their children and gather them in a list.
While this was still kind of risky (Objects may still not be found) it worked really well. But added a serious management layer. I had to make sure all needed items were tagged and configured properly. And forgetting what the parent or child object needed caused some issues in testing.
But ultimately builds that year had this solution. And some remnants are still here. And while it worked It still wasn’t an ideal solution.
Then came delaying the steam release when I realized (Partly after my talk with my publisher) that I need to make a more proper sim game. And after some messing about with making some new content, we went back to the drawing board on what the game needed.
Handling Data: Our Apartment 2022
We worked out some of the basics of what was needed, but for a while the main challenge was writing. In a similar issue to the “One scene” issue mentioned a while ago, collaborating on implementing dialogue wasn’t possible. And it was a big undertaking to fix that. Before that work was done, Invertex (Thanks dude!) dropped a bombshell that was so significant it prompted a partial rewrite.
So let me explain what was learned.
Unity has scriptable objects, when this project was a “Preview” we didn’t use these at all almost, beyond certain assets. Largely because I wasn’t aware of their benefits at the time. But in 2021 we started using them a good deal. But what we didn’t know is you could use them to pass scene data between objects.
In short if two objects have the same scriptable objects, and one object assigns a variable the second object can read that. This blew my mind; it sounds simple and kind of obvious, but you’d be surprised how often I encounter people who don’t know this.
To put it a bit more in perspective, this basically takes our former solution and reverses it. Instead of the game needing to “Find” objects, instead when an object is activated it “Registers” itself. This can be to the game manager or other objects which also have scriptable objects to pass data to. This is significantly more reliable and caused us to reconsider how the game was programmed and then also reconfigure how character properties and data worked.
We ended up consolidating much of the character data into a single object. And moved most of the game manager stuff to a scriptable object as well. Now not all of the game is based on this method, mostly stuff related to activating scenes and certain animation stuff lacks it. But that will change soon. But even the current impact is far reaching.
As such I feel like this concludes our data handling approach. I don’t feel it’s necessary to make further changes, where former methods left a lot to be desired. What’s better is this method even further makes it viable to create games with new character or multiple characters in whatever form that needs to take. Be it another sim game, an RPG, or whatever comes next.
This change also has the benefit of now just allowing prefabs but making adjustments without even needing to enter a scene. Whole elements of the game can be changed and expanded without needing to configure anything in one of the games levels. And the data is easily merged on the repo. This also opened the door to handling character data across scene loads. Because of how cinematics will be handled, largely relying on scene data multiple instances of a character are needed. And one huge concern for me has been handling that between scene loads. Cause personally I consider persistent character instances risky, reason being if a glitch occurs it carries over rather than resetting eventually.
IMO this is probably the most important progress by far and gives me a lot of confidence in the future of the game.
Versatility
So maybe you ask, why go through all this effort? Besides the general development benefits if one thing works why not stick to it, finish the game faster? And the reason why is I focus on the long term. Obviously, there’s a limit to how much improvement is necessary. But my goals are creating systems that can be ultimately used in a wide range of adult games.
Learning and implementing better methods early allow for easier expansion over time (less tech debt). Obviously, this expansion doesn’t exactly apply to Our Apartment alone. It applies largely to longer term future projects. Our Apartment is now programmed in a way where be it an RPG, a Racing Game a Sports game or whatever it’s systems can be utilized. It can be expanded to support multiple girls, made to support multiple personality types and fetishes where even the same sex sim gameplay can be made fresh.
Which would free up development to focus on other mechanics. Cause at the very least I know whatever future projects I do will be sim style games at least in interaction with female characters, and character personality is always core. But sex sim gameplay isn’t enough in the long term. So maybe it’s way down the line, but the goal is taking Our Apartments dress up, sex sim, daily, and cinematic tools and apply them in say a Persona style RPG, or a racing game with dating sim elements, or any other genre.
Think about games like Persona, Yakuza, Batman Arkham Series, the Souls series, etc. All games that took great foundations and evolved them over time to become the legendary series they are today. Yakuza in particular being the ultimate form taking its normal formula to make a turn-based RPG, and a detective game. Reinventing the wheel over and over is not what good series are made of. I don’t want to deliver just good sex sim, and good character interaction, I want to make good games period. Our Apartment is about solving a core puzzle, so the puzzle doesn’t need to be solved again for the future.
Conclusion
TL; DR, Our Apartment is made for the long term both for this project and future ones. And the way data handling has evolved has supported that.
Things feel solid now, way more than before. And as things get added like scene transitions it should prove that. Once that hurdle is past, the majority of the games core functions will be complete.
I know it’s been a long road, but the game is more stable now than ever before. And hopefully this means the next difficult task of adding content, cinematics, and story is faster an easier as a result.
Thanks for your support and patience,
~sacb0y
Comments
InuScaled
as someone who doesnt make games, i can only guess how long things take , but i think people should just be happy that some progress has been made, ive seen game being put on hiatus permemently soooooo any progress is possitive progress :) <3 take care of yourselfs <3
BigDaddyG0blin
I do appreciate this type of update. I always think about like, how cool it would be making games at 1k feet. But workin in the industry I do, I realize it must be kinda a nightmare logistically when building a game from the ground up. I do agree I get sad at games being difficult to expand upon once I'm super into it. The forward thinking setup is better, even if it consumes allot of time. Hope you are well.
