studio apart(ment) devlog 1

hello there! i have been working on this game for a while and am going to share some progress whether you like it or not

the premise

so basically this game was a jam entry originally for the indie tales jam but i had this grand idea to make it bigger. originally the game was just overcooked but solo. get a task --> walk to it --> accomplish it. pretty basic, but it was kinda chaotic and fun. i really liked the art style in it. it was something i had never done before so i wanted to at least give it the light of day. the original plan was just to add more to make a post-jam version. i added things like level loading, walking around the apartment building, doors, dialogue, a city, there were a lot of problems though

• reaalllly awful code structure. there were a bunch of dependencies, i didn't even really know events when i wrote a lot of the code, and most importantly i didn't know how to use a multi-scene workflow in unity. an example of this was transitioning between scenes, where the player object was not persistent between scenes. therefore, when you load through scenes and i would save the data in a persistent object through scenes and then set the player position. it was really awfully messy
• the game was made in 2d. the main problem with this was that it was useless to make art in all 4 directions. i am also way more comfortable modelling in 3d than i am making vector art. in addition, a lot of perspective issues were funky with a 2d camera. there's no perspective (the game is orthographic but some would be nice at least), the camera cannot rotate around the player, and rendering objects in front of each other was a nightmare to set up (i was trying to use sprite pivot points but it was still not very fun)
• and the most important reason of all: the spark. the idea for a post jam version was initially relatively small and it just felt a bit boring to me. you have this whole city to explore and your goal is to...do chores? it didn't feel very fun. i thought a lot about where this idea could go and i had no idea honestly. it's still a little unclear but i have an interesting (i hope so) idea and i want to make a really great life sim.

converting the game into 3d

so i had to convert the whole game to 3d. was this a problem? a little. was i mad? no. the nice thing about the fresh start was that i had to refactor all the old code or write new stuff to fit in 3d or just for code cleanliness. therefore, doing it again in 3d was not a problem at all. i also learned a ton of new stuff about using multiple scenes and events. also, having the hindsight to restructure code in a way that would not cause the same headaches they already did was nice. also, since i had made most of the assets in 3d already, they were a drag and drop replacement. since the shaders are all flat color the look of the game was achieved relatively quickly.

does it look perfect? i don't really think so. but it's still a wip and i think it keeps the integrity of that jam version and i think i can perfect it.

now some code related things

movement

the movement was a tricky thing. i wanted to use kinematic rigidbodies but i am not very good at it. Rigidbody.MovePosition() was not amazing for what i did (either that or i don't know how to use it properly which is more likely), and i wasn't getting collisions, which was a huge problem. i ended up getting it to to work by setting the velocity of the dynamic rigidbody of the player every frame.  the rotation was done by lerping the angle of the player to the angle between the forward vector of the player and the target vector (see image)

dialogue

i have a node-based dialogue system that i wrote about a month ago. it uses a really handy package called x-node to make dialogue sequences. the change i made was putting the dialogue objects in their own scene, as they used to be their own canvas objects, which meant every time you wanted dialogue the objects had to be in the scene. now i have a static coroutine (i wanted a void but i need a coroutine) that will check if the scene is loaded (if not it waits for it to load) and then calls the dialogue. this way is so much better than having a dialogue object in scene. in addition, i made the dialogue manager a singleton, so it can be called from anywhere which is extremely modular and allows for it to be called dynamically.

input

i decided to use the new input system in unity. i love it. it's not amazing with events when you need input for something like movement. and it's definitely not the easiest to set up. but boy is it useful. the most pragmatic use of it was dialogue inputs. i want the player to stop being able to move when dialogue is active. the old system would have had a bool canMove which would be set true or false when there's dialogue. the main issue with this is the dependency and reference to the player object, which is wholly unnecessary. instead, it is much cleaner to just disable the player controls and enable the dialogue controls. another benefit of this is easily being able to add in controller input and change input, as well as adding new action maps. so i really love the new input system for this functionality. it is rather glitchy, every time i move it sometimes will keep the joystick kept pressed even when i am not touching the controller.

tilemap

this is a 3d game. tilemaps are not meant for 3d usually. but here's my workaround. the original plan was the make tilemaps with the gameobject brush provided by the unity-2d-tilemap-extras package. but this method is not great for procedural generation, and makes copies of gameobjects rather than storing them in the tilemap data. what i found was that rule tiles can place down gameobjects as tiles! therefore i can use meshes i make in blender in the game with rules, which is awesome and makes procedural generation a whole lot easier.

game design decisions

- keeping the camera fixed: should the camera be turned on a joystick (like most 3d platformers) or be like a button and turn a fixed 90 degrees every button press? at first the answer felt obvious: do the first one. but doing that made the game feel weird. the game is isometric, and making a rotating camera like that made it feel like a whole new game. overall, i think it was better to lock the camera to 90 degree rotations

- the day cycle: how long should a day be and how often should the clock increment? drawing heavy inspiration from stardew valley, i wanted to decide the length of each day, since i want it to be short enough to play a few days per session but not too long to feel boring. the gameplay should therefore match that and not be grindy, but rather have something new every in game day. the tentative day length is 15 minutes. i'm not sure if this will stay constant and playtesting will help that. every 15 minutes the clock ill increment, so the clock will go 12:00, 12:15, 12:30, 12:45, 1:00, and so on. 

thanks for reading this! i'm not sure how far i'll take this life sim, maybe i'll go all the way to a steam release but for now i just wanna have fun and make a cool game about living in a city. peace out