Greetings
Hey everyone, this is x8c8r (or Xeight, if you prefer) speaking! I wanted to talk about the development for a bit of time now, so I thought I could make a post here.
What i will be going over
- What happened over the last year
- What is happening right now
- Plans for the future
Development over early 2023
Long story short - Scrapped entirely
This section is about what happened to the previous version of Cube, and will not be talking about the current state of the game, so feel free to skip it. This is also my personal recounting of the story, so it may not be fully accurate. (As a matter of fact it probably isn't)
Start of year
Entering 2023 there were 4 members in the team:
Me (x8) [Programmer, Game Designer]
Jayjay [Game Artist, Game Designer and Level Designer]
name [Programmer]
Kenan [Programmer]
Everything was going moderately well, we even tried to get a demo out for the Summer Next Fest (which we didn't). A lot of essential systems were coded, the game looked pretty good, we had a story written out. Point is - We tried to develop the thing, and it seemed like we were succeeding.
Things started to go south when Jayjay stopped making progress on the map. It was a big issue for us, since no one apart from him had a graphics card good enough to bake lights. (Looking back in retrospect, we very much could have just built the map and then bake the lights at the end)
As far as I understand there were 2 things that contributed to this:
Jayjay losing interest in game development as a whole was one of them, and I will not blame him for that, you never know whether you like something or not until you try it, and he seemed to enjoy making Blender renders and filmmaking more.
Abnormal bake times (>20 min/bake, very long) were another one. The entire game at that point was just one huge scene with tens of lights each and every one of which had to be baked. Despite having a good GPU it still took a while. We tried to come up with some ideas on how to seperate the map into different pieces, but never really acted on it, due to, once again, no one touching level design.
The end
Team motivation started to fall quite a bit before that, but this was really the tipping point sort of. No progress was being done.
After the Steam page being dormant for quite some time, in September we decided to delete it. Well... not really.
$100 is quite a bit, and it would be really bad to waste that money that was spent to put the game on Steam, so I suggested we just ask the support to hide it, which we did.
It was final, Cube was pretty much dead. Jayjay wanted to turn it into a short film series, but the game? It was dead.
The Revival
So, what is the first thing one can do once a project is dead? Correct. Start it over. Which is what I did.
Starting over
One thing I didn't mention is that I wanted to potentially revive the project, so in October, I decided to act on that thought.
The old project file was a mess, so we decided to make a new one and rewrite/port things we needed.
Redesigning a game out of horror
Cube was supposed to be a horror game from very start. But we always just struggled to find something that would make the game actualy scary. This also pushed the game into a "backrooms game" territory, which is not exactly the best.
As you may have guessed, the horror aspect was abandonned. But what will replace it?
At first i thought - Exploration! Just explore around, find the lore, secrets. But the moment I wrote that out to the team I understood that it even sounded boring. I decided to go with it anyways, we got nothing to lose.
Except, one day i remembered about a fun thing we wanted to add - Wire Puzzles. It just kind of clicked for me there, I realised we can add puzzles to make it more interesting. While still, it may not be that engaging, it's still better.
How to art without an artist
Well, I am still unsure.
For the sake of convenience, as well as personal preference, I decided to change up the visuals of the game a bit - Adding a PSX style renderer (Which is just fancy slang for "render texture with low resolution"), as well as preferring to use low-poly models, due to the fact that they can be made more easily.
Lighting conundrum
A decision we made back in previous iteration was that we will use baked lighting.
For all the non-nerds out there - "Baked" means that instead of your computer processing the lighting, the developer "bakes" a lightmap, which contains lighting data, basically meaning that the lighting is built-in to a map, improving performance (and looks) by quite a bit.
The issue with baked lights was that baking used something called "Global Illumination", which is basically a less fancy version of Raytracing. What it does, is that it bounces light beams off the objects. An obvious thing, that is a major downside, is that in order for an object to be able to bounce light, the engine needs to know that it will always be in that position, therefore it has to be marked as "Static", meaning it cannot be moved once the game is running.
So, you might be asking - "What is all this nerd-talk about and why do I need to know it?", and the answer is - Doors.
You see? Doors are very funny, they actually can't be static, because guess what - They are supposed to open and close!
What this also means - Is that they don't contribute to Global illumination, making any area with a door bake improperly, due to engine basically ignoring the door, and shooting beams right through it.
i genuinely bashed my head about it for days. Several solutions came up during research:
Just switch to realtime, lol
While we could do that, it would result in both performance and visual downgrade. Also another thing with realtime lights is that - I didn't understand at the time how to properly configure them, so they always ended up too dim.
Ask someone who made good lighting
This is the option I ended up going with, obviously. Now, who was I going to ask? A friend? Maybe a support server?
How about Superliminal developers?
I played Superliminal a bit before this issue came up, and because I am completely obsessed with this thing, I decided "Fuck it, lol, I will give it a shot". So, I send an email, and get a response a couple of days later.
I feel like it's a good time to thank Christopher Floyd for replying at all. If anyone reading this haven't played Superliminal yet - You should. Also check out other stuff he does, here is his Twitter - @cfloydtweets
Anyways, the response is: Mostly baked with some realtime
"But isn't that exactly what you said you can't do?" Yes, but, there is one thing that came up during research, that I kind of ignored due to being confused - Light probes.
Basically, to save you the headache of the already 2 entire nerd explanations - Light probes store light, and they project it onto objects nearby. With this in mind, I can make a room with fully baked lights, add light probes to it, and now any objects will have proper lighting.
Designing the level design
From early days of starting this iteration I decided to not use Probuilder. Despite being a default Unity package, that a lot of people use for their games - It seemed to have more issues than I would like to deal with. From being extremely tedious for making complex structures, to lacking functionality, I wanted to find an alternative, and I did - A CSG editor. I will not bore you with details yet again, but I am using RealtimeCSG. It's free, and pretty convenient.
Anyways yea, I decided to make initial sections of the map smaller, more tight and claustrophobic, eventually expanding in grander areas with more interesting structuring. The lighting is mostly pretty dim as well, bright lights do not fit the aesthetic we are going for.
There will be lore segments too, but they will come later.
Zones
To avoid issues with stupid long bake times and to improve performance by slight bit more, I wrote a simple "zone system".
Basically, the map is divided into zones, with triggers to load/unload adjacent zones. While this does mean more planning in order to properly be able to bake only certain zones' lights instead of the whole level - I feel like overall it's a pretty good solution.
So, what now?
To be completely honest - I am not working on Cube as much as I wish I would. It's mostly a couple hours some days of the week, so the progress is really slow. The current plan is to release a demo by Summer Next Fest (again), and then see if the public even likes it or not. Chances are, Cube will be a pretty niche puzzle game, and quite a bit of learning experience for me and others. Who knows, maybe it will get like 10 sales, and we will be able to put up another game on Steam.
I cannot accurately predict the fate of the game as of now. It may be finished, it may be not. It may be good, it may be not. It maybe a lesson on how to make a game, or how not to make one. One thing I know for sure is that it's probably not releasing in the next 3 years due to some legal questions that cannot be solved as of now, so we might as well take our time making the best game we can.
I also don't know how frequent these devlogs will be. Maybe every month, maybe whenever I feel like substantial progress was made. If you want even more updates, then join the Discord server, since sometimes I post things there.
Anyways, thanks for reading. Feel free to ask any questions or correct me if I got something wrong. Merry Christmas!