Dear Scholars,
I usually try to focus on one thing per entry but this time I have several different things to write about. I'll try to keep them condensed in return. [note from future self: alas, I failed]
Behind the scenes
The process of creating games was always something I was very passionate and enthusiastic about - not any less than about the end goal to release the game and see people enjoy it. Because of that the idea of live streaming the development process has been lingering in my head for a long time. The reason that I've waited so long to do it is probably that I haven't really had time to do much 3D art in the recent years since programming has always been the most time consuming and high priority thing to work on for Selenwald. I also mostly stopped doing 3D modelling for hire years ago because I needed a more time efficient way to earn for a living. Tech art (shaders, tools, etc.) and programming are paid better and they excite me no less than 3D modelling so I transitioned naturally. Ironically though, it's art that's the most interesting thing for people to watch as indicated by a little poll I conducted over on our Discord server. The most requested topics were 3D modelling and shaders/VFX so I chose to create a model of a fireplace and then make a fire effect to burn inside it.
Half-improvised
Creating a full blown 3D model from scratch using a traditional workflow is something too complex to be done from scratch within a time span of a single stream session, let alone along with the VFX. In order to make the show more digestible I decided to split it into two separate sessions.
My friend Jakub was kind enough to lend me some professional lighting equipment and a camera and after a failed foul start caused by some hardware and connection problems I've managed to get my first stream going.
The goal of this first session which took place on 4th January was just to create the 3D model, without the fire effect. As I said, the traditional workflow would still prove too long for such a prop to be done over ~3 hours (especially that my 3D modelling skills are very rusty these days). This is why I've chosen to model a fireplace in the first place as it wouldn't require me to go through all the usual steps - it's an unusual prop. Typically when you create a 3D model for a game, you need to go through the following stages (as I've described thoroughly in Dev Diary #3):
- Draft / block-out (making sure the dimensions and the general form are good)
- High-poly (modelling a high fidelity version of the model with tons of geometry)
- Low-poly (modelling an optimised, simplified version of the model that will be used in the game)
- Baking (transferring all the detail from the high-poly to the low-poly through special textures containing all sorts of information on the form, enabling the low-poly version to imitate the high-poly one)
- Textures (creating textures by utilising the baked maps in a texturing software)
- Implementation (exporting the final version in a way compatible with the game engine's pipeline and setting everything up in the engine)
However, in the case of this model only 3 stages were required:
- Draft / block-out
- Low-poly
- Implementation
Why was that? That was because this fireplace was about to become part of a modular wall set that uses a workflow called trim sheets. In short, this technique is great for creating models that share common features and mostly utilise tiling patterns such as bricks or repeating reliefs. It enables you to go through the full high-poly modelling and texture map baking workflow only once in the beginning, creating a special texture set known as a trim sheet. Once you have the trim sheet, you can very effortlessly add more and more props that use it. Moreover, once you have many props using a trim sheet you can also create additional trim sheets using the same conventions you used when distributing patterns across the original trim sheet. This way you can easily create additional sets of props that share geometry but still look quite different - a more advanced version of so called "re-colours" if you will.
Both the trim sheet and the wall pieces that use it were originally created by my former colleague Aleksander and then finished/remastered by me.
Although I'm happy about how the model turned out, it still needs some tweaks as much of it isn't finished from a technical standpoint and it may need some additional details here and there. I intend to either finalise it before streaming the fire VFX creation or do it live alongside it - time will tell.
The continuation
The next session is planned to take place on the upcoming Friday (20th January) at 7:00 PM CET over at the Twitch channel. Although it is unlikely for the date to change, I will send a notice via our Discord server in case it does. Join it if you don't want to miss the broadcast.
They can talk now!
One of the most important things I've worked on recently was the dialogue system (which I made with the help of a framework called Dialogue System for Unity) and the disposition system. I have the basic setup ready and will soon bring it to a usable state so that I can implement a first friendly NPC and give existing hostile characters more character. That's right - hostile characters can be talked to on some occasions as well. Everything depends on their disposition towards you. Technically there's no distinction between enemies and friendly NPCs aside from the difference in disposition which you can influence.
Everything on the screenshot is work in progress!
I made the statue my debugging friend because it doesn't move much and doesn't attempt to kill me. However.. that doesn't necessarily cross out the possibility that you will be able to "converse" with it in the final version of the game.
For now, I placed the dialogue interface on the side because the traditional cRPG placement in the bottom has some serious downsides - not only it heavily limits the space on the screen but also partly conflicts with the existing UI in Selenwald. Besides, I've finally found some time to play Disco Elysium (which, by the way, also used that framework I bought) two months ago and have seen how well that kind of layout works there so I'm going to leave it like this for the time being. However, that doesn't mean it won't change since there some other viable options I consider. As a matter of fact, a lot of the elements in the current UI (mostly in the character/inventory screen) are very likely to change in the future.
That being said, I'll likely talk more in-depth about the dialogue system and the disposition system in another Dev Diary entry once they are developed further. Also, I plan to have the disposition system tied to other systems in quite a unique and interesting way so I'll gladly tell you more in the future.
Restoring order
Take a deep breath since you're about to read about the most thrilling story so far. Have you ever walked around with a full bladder for several hours that felt like ages to finally be able give in to the blissful feeling of letting it loose? Such a mundane thing, yet what a feeling it is! And that's exactly what what I felt when I finally brought order to all of the Selenwald's source files (primarily of 3D art) a couple of days ago after not finding time to do this for a year and a half. It took me around 3 days but it was well worth it.
As boring as it may sound, I find it very exciting for a good reason and want to tell you what mistakes I made along the way and what are some good practices related to storing source files (and working with people who send them to you in the first place).
So the trouble started as soon as I started to regularly hire freelancers in 2021. Most people are terrible at keeping their files neat so if you don't explicitly tell them how to name files, how to organise data between files and which files to send you for feedback, you're going to end up with a terrible mess of files that don't make sense and there's clearly too many of them but even their authors no longer remembered which files are good and which aren't so they sent you all of them for you to figure out yourself.
Accepting and keeping files like this kind of works at first when it's fresh and are in the loop. That's the trap because you're likely to leave it like this because you currently know what is what. And it will cause pain a couple months later when you need to find something among these files. It gets even worse if you leave the received files scattered across many locations - some in the Downloads folder, because hey, files have their "Created Date" and "Modified Date" so you don't really need to categorise anything. Files will be easy to scrub through if needed, right? Wrong! With tons of .zips and folders named like drive-download-20230118T194202Z-001 you won't even know what's inside, let alone decide what's actually the recent version. Especially that the "Modified Date" can get easily changed on many occasions without your intention and will also be changed by the source control system once the files are stored. You just can't rely on those. On top of that, people are likely to send you stuff in different pieces. For example, maybe they sent a folder of the final files but it turned out they forgot something so then they sent only what was missing. And you end up with 2 packages which both contain final files (and possibly some duplicates which makes things more confusing).
Things get even more messy when you're out of space and need to keep things on external storage devices. For me not only this happened but my primary monitor has died in January 2022 (and I was so broke at that time I couldn't afford a new one nor having the old one fixed) so I had to abruptly move my workstation to my laptop so I can have 2 screens again (it's impossible to work in gamedev with less than 2 monitors, trust me). So now some of the source files were on my stationary PC, some on my laptop, some on my portable SSD, some on my Google Drive and some on the cloud repository where the game project resides. If this doesn't sound like a nightmare I don't know what does!
And the thing that was making me anxious all the time was that many source files were not stored online. I was constantly worried that in a case of a tragedy such as my apartment going down in flames with both my computers inside, I'd permanently lose some some important source files. The project itself is - of course - hosted in a version control system since the very beginning. I used GitHub in the early stages of the development and later moved to Plastic SCM. But I was reluctant to put the source files there as well. And was was that?
Even neatly organised source files for a single 3D prop can weight like 2-3 GB which is more than the actual project files of the game are going to weight for a solid chunk of the development time. Now if your files are a mess, then they can easily weight several times more. For example, the source files I had for the game's UI weighted over 50 GB because they contained several packages I received from the artist and I didn't organise them while it was still an easy thing to do. Just dumping so many files into the source control sounded like madness to me as it would cost a lot of money to keep so much stuff up in the cloud so I only stored them locally. However, later on I realised that keeping source files in the source control system - just like the project itself - is the correct solution but I still needed to manually go through all the files and open them up one by one to make sure which are good and which aren't. That was the price of not enforcing order since the very beginning. Anyway, I knew doing the work now would enable me to compose a package of a manageable size and avoid worrying about bills eating me up.
Now that I've done it, my repositories containing both the project files and the newly uploaded and ordered source files weights over 75 GB which isn't bad. Everything is now relatively easy to find. And the stress is gone. What a relief!
Lessons learned
So what are my takeaways from the source files adventure?
- Rigorously enforce naming conventions that have the date included. You can't trust the dates assigned automatically. I was actually taught to do this when worked for CView Studios / 4A Games several years ago but somehow forgot to introduce this in my own project. The convention I am likely going to use from now on is: [AssetName]_[FileType]_[YYYY]-[MM]-[DD]_[OptionalID] So for example: CutStoneFireplace_LowPoly_2023-01-18_2.fbx This would mean that this is the 2nd version of the low poly model of the fireplace received today. Also, the proposed date format is important here because this order will make it work with alphabetical ordering making things sorted chronologically.
- Instruct people on how to best organise the data so that you don't end up with different elements of the same thing scattered across many files.
- Immediately place all received files in one place. The best place would be the the target folder in the repository workspace, ready to be pushed to the server once you receive all the final ones and delete clearly useless old versions.
- Absolutely use a version control system for source files, just like you use it for the game project files. Just remember to have a separate repository for it so that the game's repository stays lightweight. Alternatively you can use a service like OneDrive, Dropbox or Google Drive but I think proper version control like Plastic SCM is just better for this and you don't have to pay for 2 similar services at the same time.
I hope you learn from my mistakes and save yourself some trouble by having everything both well organised and safe in the repository from the very beginning!
Thanks for reading,
Wiktor