Page 1 of 1

New approach to coding

Posted: Wed Jul 18, 2018 2:48 pm
by Rytelier
I've looked a bit into Daggerfall Unity code and it looks pretty messy for me.
I'm not and expert, I admit, but I think code structure should be cleaner, more modular. I would say - as modular as possible - especially as this project is made with modding in mind, so modders should be able to change/replace game mechanics easily without making changes to whole code and getting lost.

Scriptable objects
I've noticed that many things are hardcoded in the code. I've got a heart attack after seeing that enemy types are put into a giant enum list. Please don't do that. Unity has handy function called scriptableobjects. Use them for everything, literally, scripts too - I will get to that point in next part.

Example: there's a weather manager, it sets lighting, sound, etc. So weather should be put in a scriptableobject, so modder can modify weather or add new one without changing entire weather manager prefab and its code.

So, what I meant about using scriptables for game code? It's a good idea, because they make code modular, without hard references in the code. You can put functions, like walk, interact, input, etc. into individual script modules. And then reuse them for player and NPCs.
You can do things, where you can reduce repeating code and "if" conditions in it.

Here's a handy tutorial about it: https://www.youtube.com/watch?v=UjcG0B7JFbM
He has adapted this pattern and it makes his code way cleaner. I suggest also to take a look at his Soulslike tutorial, from part 65, where he ditches everything he made in previous parts and replaces it with the new method.

Yes, I'm aware refactoring script, where you've done decent amount of coding isn't a fast task, but it will profit in the future. Please, don't risk of getting lost in the code as there gets more and more of it.


Again, I'm not an expert, but I have some knowledge about scripting in Unity and did also research how to make my own code clean. I'm still learning using scriptableobject based architecture, but it's already way more clean and convenient, than my old way, with hard references and horribly long bloated scripts.

Re: New approach to coding

Posted: Wed Jul 18, 2018 10:18 pm
by Interkarma
Welcome to the forums! :)

Some of the older parts of this game (such as enemy classes and weather manager) started life as part of my Daggerfall Tools For Unity. DFTFU is only a toolset for reading Daggerfall's assets into Unity, not a game by itself. Part of that toolset was a dozen or so "demo" classes for using these imported assets at runtime. For example, you might have noticed the MonoBehaviour class which instantiates enemies in the world is still called "SetupDemoEnemy". This code existed long before Daggerfall Unity and is simply maintained as functional for now.

BTW, the enemies are actually defined in MONSTER.BSA, part of Daggerfall's classic game data that Daggerfall Unity also uses. What you're seeing in those classes is just a bit of "glue" to epoxy the new game engine back to the old DOS game data. Daggerfall also hard-codes this behaviour information, so it's very much a like-for-like implementation. I do plan another pass over enemies and item templates in future to make them a bit more modable, but it's not a priority any time soon. I'm a big believer in the phrase "perfect is the enemy of good".

I'm quite aware of ScriptableObject and very intentionally do not use this pattern. I disagree it would be a fit for this project. I even avoid using MonoBehaviour unless something physically needs to interface with the scene. In some cases, I've gone to the lengths of separating game logic (e.g. DaggerfallEntity) from the part that touches Unity (e.g. DaggerfallEntityBehaviour). I do this to reduce/decouple dependency on Unity where possible.

All of the core systems (UI, items, entities, quests, magic effects, etc.) have minimal reliance on the Unity engine, or any other external dependency for that matter. I've done this intentionally so it remains possible to move the game to another engine later if necessary. This would still be a major undertaking of course, but it remains feasible. I am far more likely to reduce dependency on Unity even further than to increase it. Despite all the criticism I've received from FOSS purists for using the Unity engine at all, I try to keep open source freedoms available while tapping into the network effect of an engine with a multi-million strong user base. I believe there's a practical middle ground to be achieved here.

And some things are just messy because they're created by several different people over the course of many years who each have different styles and experience levels. I try not to sweat that too much - as long as the sausage gets made in the end. Again, perfect is the enemy of good.

I do appreciate your feedback and constructive criticism, and will always take this stuff on board and try to do better in future. My code has improved greatly over the years thanks to feedback from others.

But it's also important to recognise that I might be doing something a certain way for reasons that are not obvious. And some of the constraints I've had to endure are difficult to understand without having gone through the process first hand. Daggerfall itself is a messy creation and some of that inevitably carries across.

At the end of the day, there's a good reason Daggerfall Unity is rolling downhill towards the finish line, almost against all odds for a fan recreation of this scale. A major part of this outcome began with understanding that "perfect is the enemy of good", and making sure the game actually gets made ahead of everything else.

Re: New approach to coding

Posted: Fri Jul 20, 2018 11:52 am
by Rytelier
Ok, I see.

Is it possible to use the code in engines that don't use C#?

Maybe it's possible to make an Unity independent system for modular scripts? Something, that would allow modders to easily change certain mechanics?