Preface
I say “post-mortem”, but no-one knows what Sophomore Mysteries is as it was never finished. (So I guess its a ... pre-mortem?) Its the original project of the “Zero” version. “Zero?” Well its a sort of a short prequel, introduction to Sophomore Mysteries. (Here’s a link to itch.io for a free copy of it, and more about this at the end.)
I’ve wanted to do my very own point and click adventure game since forever. I’ve been playing these games since kid; Full Throttle, Space Quest, The Dig, Gabriel Knight series… list goes on and on. “I do have an idea, why not make it into a game. I’ve dabbled a bit with game making, I’ve released a thing already, I’ve been doing beta testing for point and click games for some time now so why not.”
There were a couple of things that have been bothering me since forever, how you have to do some things in a specific order that should make sense to be able to do in a different way as well. Like the staple of point and click games where you have to combine two things to form another thing. And thing number one is in your inventory and thing number two is on the floor right there in front of you. Why do I have to pick it up first and then combine everything in my inventory? Why can’t I pick the piece I have already in my inventory and put it on the piece that is right there on the floor and then pick up the completed piece? Or do the piece picking up in the reverse order, pick up the thing on the floor first, and go to the place of the other thing.
Or when I talk to NPCs, I should be able to piece together a sentence to ask, right? And if that sentence makes sense in context, there should be a suitable reply from the NPC. As a player I’ve gathered different questions than the ones presented as options sometimes. If I’m allowed to try any object on anything and get at least a generic “Dunno” answer, why not the same for dialog?
Yeeeh, I can do something about it!
What’s in a name
“Sophomore
Mysteries”, where did that
come from?
Well, in the beginnings of what eventually became
this small game basically, the player was a professor of criminology
(that used to be a detective) in a university with multiple
disciplines, and the idea of it was to use that for potentially
different kind of puzzles, ranging from chemistry to tech to acting.
In fact, the first cut-scene that introduced the victim-to-be
of the title was shown there, along with some other
characters to act as potential future suspects. A pompous prickly
sort of professor that berates people, students that don’t want to
deal with it anymore, a criminology professor (the player character)
that perhaps thinks too highly of themselves, too smart, (for their
own good perhaps), a detective friend that might be too trusting sometimes for
his own good, and a bath of
corrosive chemicals to get rid of things.
But, it wasn’t coming along. I knew the beginning, knew how to finish it and even had the scene all planned out how to play out with two possible endings. I just didn’t know how to glue them together, and in a happy-go-lucky way I was thinking to my self that it’ll pan out as I go.
Wheel re-invented (Systems created from the ground up)
When i say "systems created", what i actually mean is that i sat down to code them, instead of looking online to see if anything like that was already made, or at the very least something that i could modify to warp it into what i wanted.
Interactables
The first thing is a script that I guess all games start with. It is a script added to each object that I wanted to be interactable. It basically adds the capability of that object to detect clicks, it has the objects name, what kind of interaction is possible with said game objects; sorry, I meant ~gameObjects~. It also force-attached some other scripts that enabled the character to give out a basic description of the thing that was clicked. Basically if you click and an object is detected under the pointer, if it has an interactable script attached, you get a small description or comment if you right clicked, or the interaction menu if you left clicked. If it didn’t have one attached, you walked there. Thing of the interactables script as the receptionist you meet at a building that directs you to where you want to be. (NPCs also get that interactable script, they just get some other scripts on top of that.)
 |
| Click to expand |
Status (State machine)
This one is simple and something that all games have. A big list of tick boxes (flags) that is used for tracking down what things happened or not. My system used a class array that holds the name, ID number, and state of an inventory objects, and another class array that holds general states of things I need to keep track of, with the same class structure as the inventory items. The “state” field is not a bool, but an int. Because I thought to myself, “what if I need to track the state of something that is neither on or off?!” Which to be honest, I did in some stuff. 0 is off, 1 is enabled, 2 is “used”, 3 might be “go check the object for a custom/specific thing to do in that object.
NPCs or interactions the player performed can set or check states from the arrays to keep track of game progress, dialog and items.
Yes, the code is a mess, but it works!
Inventory System
So in a lot of point and click games, (or at least the ones I played since the late 80s all the way to current times of writing this) the modus operanti is that you pick up what you find, (basically everything and anything that isn’t nailed down to the floor) and if you need to combine things together, you do it in your inventory screen. You had to put them together in there and nowhere else. I’m sure there must be some titles that let you combine things that go together anywhere and any time, but I don’t remember having played one.
So I decided that my game would have a system that you could combine the inventory items that went together, wherever you liked, meaning, you could pick all the parts of a thing and combine them in your inventory, or pick one thing and keep it in your inventory, and then when you found the other piece, use the one you already have on the piece that’s right there waiting for you to pick up. The pieces will instead be combined right there and the piece object that’s on the environment will be replaced with the combined part for you to pick up.
The way I thought about doing this (for better or worse) is with having each object hold info about which other piece can be combined with it and which object is the finished one. Then both inventory items have their state set that they are disabled and used, so that they disappear from the scene, and the finished part’s state is set that it is enabled in the game world…
Save/Load System
...so
when you load your game, the save/load manager reads the status
arrays and while the screen is still black, it enables or disables
the objects according to their state...state if they are inventory
items, or sets their progress flags/dialog flags if they are events
or NPCs.
Once the save/load
manager went through the save file and populated all of the state
tracking arrays, the objects at the scene (everything is enabled when
first loading the scene) would read the state that game is in, and
appropriately disable themselves if they are not supposed to exist
yet/any more, and the NPCs know if you’ve talked to them yet or
not. This is where you deal
with Unity’s script execution order panel to make sure that each
script is executed in the right order. You don’t want the object to
check if it has to be on or off and the array says to it “you do
not even exist”.
Oh yes, the save file is just me serializing the two arrays and just writing them in a file with a custom extension. Nothing more.
Then on load I just de-serialize the file back.
Dialog System
Oh boy. This is where I really got all “I might need this thing, I might need to account for needing that thing in the future. I might decide later on to do this idea as well. I’ll try to implement as universal a thing I can!”
No, stop that. Get some help. Do each type of dialog in its own script instead of one monolithic wall of text, and just add them to the NPCs as needed. “Types of dialog”? Yep. There’s a) normal banter that you go back and forth with the NPCs, b) dialog that uses dialog trees, and c) interrogation mode where you compose questions by combining keywords. Some keywords are common words like “what”, “who”, “when” etc, then you combine that with something like “is”, “talked”, “heard”, “saw” and then tie it all up nicely with something like “victim”, “you”, “they” etc.
Then the compositor would take those - basically tags - and check against the equivalent dialog file for that particular NPC. If it found something that matched, then the player character would make a question or a statement, and the NPC would reply accordingly. OH! And I made an editor tool to help me compose the dialogs and save them to individual files! Because dialogs could also trigger events, change game states or unlock new keywords for the phrase compositor. (It was actually fun to code the dialog system and rewarding when it worked. Even if the interrogation mode is only used once in the finished thing).
Camera System
Its nothing special at all. Its based on triggers, pass from a certain path and the camera will travel to a predetermined position with a predetermined focal length. The camera can either jump to a new position and aim, or it can ease into it. It is also used in certain situations where there is a close up of an object with the camera in a weird place, that would force something from the environment to obscure the thing that needs to be in view. For example when in the early scenes, the player needs to find the dead body’s redacted that slid off all the way redacted redacted. The camera’s position is saved in the general state array and then in the save file, since a single scene might have multiple camera positions and angles.
Plot holes
Yes.
Ok fine. Basically, I couldn’t see a complete path from start to finish, and instead of trying to see one, I started doing the fun parts of modeling and coding and thought that I could connect the bits down the line, that somehow things will fall into place. In the end I caught myself doing changes to scenes that were either mid development, or close to end. I knew how the whole thing would end, and had the beginning made, but forgot I needed a middle part.
Cut stuff
Basically everything from the original idea. Gameplay and style is exactly the same, and so is the whole code. But on top of the scenes and puzzles cut, (that only the police station would have been the same scene and the first alley scene), we have an intro cutscene, puzzle cutscenes, murder(!) cutscene, character introduction cutscene...
Lessons Learned (?)
Even though this didn’t go where or how I planned, it doesn’t mean that it fails in everything. At least now I am more aware into actually designing the scenes as complete as possible and then go into making assets and the like. And anyway, things will still change, but at least with a better understanding on where they should head to. Oh and perhaps check if there are packages that I can modify before heading out to create everything from scratch. Looking at you save system. Though… nah. I actually had to learn things while making it, so yeah; still not a lost time.
So what about “Zero”?
Well, as said in the beginning, Zero is a short prequel, intended to introduce the sort of universe lets say and the characters. For me, it was an excuse to do something other than the main one, to understand how to do stuff in something that has a smaller scope, and in the mean time find how to properly connect the beginning, to the middle, and then to the end. Instead, I’ve actually wrote the scenes of something completely different, from beginning to middle to end, along with characters, and the puzzles in it, and decided on the art direction. Yep, learned nothing. And jotted down a couple more ideas for short mobile games that are good for 10 minute play sessions. In this ... prequel of sorts, you have to investigate a body that was found in an alley. Was a murder? was it an accident? Gather evidence and talk to people, and cause some mess along the way, to tell the whole story.
