For indie game developers, due to the limitation of manpower and resources, many ideas and content cannot be achieved in the game. However, sherveen Uduwana, an independent developer, said that as long as the tools accumulated by each project are collected and continuously optimized and iterated, even if it is a single shot, it can improve the efficiency of research and development.
In his 2021 GDC sharing, he explored in detail how to clean up old scripts and make them available for use in multiple projects, helping peers complete larger games without a large team.
Here's what GameLook Interpreters is all about:
Sherveen Uduwana：
I'm a freelancer doing game development and I'm currently working on a game called Midautumn. The reason why I am a freelancer is because I do not belong to any specific studio, and in my career, I have spent most of my time working with studios of different sizes, mainly outsourcing, sometimes for a week, sometimes for a month, and sometimes part-time for half a year.
There are many ways to do R&D in the game industry, but my experience is that every project I have participated in and what I have done can help me grow so that I can do game development faster later on, which is what I mainly want to say today as "Code Library".
What needs to be stated in advance here is that I am only a single developer, so the opinion may not be suitable for everyone, and if you feel that some of the suggestions in this article are not suitable for you, just ignore it. I'm mainly talking about tools that help me solve the complexity of game development, especially when you're working remotely and no one can discuss it, so if you're in a situation like this and don't know how to fix it, there might be some ways to help you.
Making a game is already difficult in itself, and let's not make it harder.
I remember when Pokémon Sword and Shield was released, a lot of people said they reused models of some of the characters, and I supported that because you didn't have to make 100 different versions of each character for a limited time.
So some things are reusable, and completing a project is intimidating enough, and in the first game, you learn a lot of things you don't know, and once you're done, you may want to make the next game.
The development of the second game will be more difficult because you already know what it takes to make a game and what the previous project did.
If you're in this state, then all I can say is that you're more prepared than most developers now, like Batman at sea, who already knows how to deal with sharks.
We can also be like Batman, the game is actually a shark synthesized by some components, you have problems that need to be solved, the functions implanted in the game, etc., you first have to prepare the shark repellent, which is the code list, and then make a capability belt (code base), when the shark appears, you can solve it.
By codebase, I mean a series of helpful resources that are reusable and reusable many times. It has to have a backup somewhere, not just the code, but all the tools that can help you, such as favorite software, settings checklist, documentation, frequently watched videos or articles, etc., which should be added to your code base.
Essentially, going back to the shark problem, in your codebase, you want everything to solve a specific problem and be reusable. Shark repellents only solve sharks, so things in the code base should be light, don't require a lot of setup, and need to be able to easily combine with other things.
How do I maintain a code base?
In the codebase, you obviously don't need all the files for the entire project, and some things that won't appear in other projects. However, you still need to be able to access this information if needed.
Also be careful not to put things that don't belong to you, there are times when certain resources give you authorization, but after a while the authorization expires, and these things are not suitable for the code base, because it may cause you trouble in the future.
The basic process of doing a codebase is like doing housework, so the best time is after you finish one project and before you start another. You'll have to look for code and resources in your old project that you want to reuse, get rid of everything that's only right for the project, and then take a name that's easy to remember, put it in a place that's easy to see, and make sure you have a file management system, which we'll talk about later.
The main reminder is not to think about making it perfect, it's just a good habit and you may only need to invest a few hours a day. And you may overlook something or put something unnecessary in it, and it doesn't matter, you can adjust and modify it later.
How do I identify what the codebase is going to put? Here is a deconstruction of a non-shark model game:
It includes components, core content, Meta mechanisms, and derivation systems.
For example, the chess table and pieces in this picture are what I call components, and in the game, they are characters, living systems, physical effects, buildings, and so on.
The core content includes the game manager, the resource system, and the features related to resource drops, which turn the game components into games; the meta mechanism is like a chess tournament, which has rules to itself, but the tournament also has its own rules, so that participants can constantly challenge upwards, equivalent to the progress system, task system and so on in the game.
And then there's the spin-off system, which I liken to tournament venues, which may not have been built specifically for chess matches, like the menus in the game, localization, the save system, etc., which are almost needed no matter what the game is. Understanding the game this way, you might be more likely to categorize what you can reuse.
Once you've found these things, you can store them in version control platforms, or you can store them in various cloud-based software. I manage it according to the system, such as the conversation system, the menu system, the archive/load and the setting system.
Of course, you can also manage according to tasks, such as scripts that describe creative prototypes, animations, resource creation, etc. You may repeat a lot of things, but it is also a different way of managing.
You can also manage it based on the game structure mentioned above, which is very helpful for me, and if you find it useful, you can also manage the code base this way.
Case
I'm going to use Mid-Autumn Festival as an example, because this project was built using my "code base.". This is a Roguelite game with a theme of Asian discrete culture that I've put on the Kickstarter platform.
Case 1: Make a sound controller that can be reused in different projects
It's an RPG game I made before, called BlackCurrent, and I made a sound controller, which is really just a list of audio clips, and it has some basic playback methods, I can set the volume, the scene, and I can also randomly play footsteps, dialogue sounds, attack sounds, and so on, they only need to be used once, and there is no complicated setting.
However, in your codebase, it's best not to have everything used only once.
So I tweaked it, and while it still looked like it, I added something I might want to use in other projects, giving up all the more figurative resources like footsteps and so on.
Case 2: Extending the same dialogue system to different categories
The case here is still the above two games, in "BlackCurrent", I made some pop-up bubbles, when doing "Mid-Autumn Festival", I added a dialogue box, and also put a character image on the screen.
Although the representations are different, their dialogue systems are actually the same.
This is the overall script of the conversation system, including the conversation content, characters, and story nodes.
In BlackCurrent, the dialogue happens in parallel with the gameplay, and I write all the dialogue. There are 3D characters in the game, they can move and there will be character animations, and dialogue bubbles will appear above the speaker.
As you can see, in "Mid-Autumn Festival", I made more obvious changes, such as dialogue lines are connected with character data, animation and display time, and the character piece has also been changed to character data, including relevant colors, non-dialogue-related data, etc.; the story node also designed automatic propulsion and mailboxes that can introduce CG scenes.
In Mid-Autumn Festival, dialogue drives the progress of gameplay, meaning that whether something happens or not depends on whether you've ever listened to a particular conversation or not, and we made a programmatic dialogue pool, so each conversation can be random. Dialogue boxes always appear in a fixed position on the game screen, and each character has a high-resolution image.
Every time a new character appears, I check the story nodes associated with it, and you can notice that I've also added unlock cadence, vanishing cadence, coexistence cadence, etc., because the progress of the game is driven by dialogue, so you need to know what dialogue the player has heard and what to hear next, even if it's random content.
Case 3: Expand the universal enemy controller to quickly increase the variety of enemies
When I was working on BlackCurrent, I designed a generic enemy controller, a lot of which was defined in a more virtual way, such as if I wanted to be a sub-class enemy, I only needed to change the way I moved, and if I didn't need to, I used the default behavior.
This controller involves many aspects, such as how enemies respawn, how to choose the next state, as well as behavior updates, attack methods, and deaths.
If you look closely, you can see that enemies have special effects when attacking, including melee attacks, and all types of enemies have this ability. I also added a tagging system for enemies, such as the turtle in the picture, when you attack, their shell will take damage, while the main body will not take damage, meaning you can't attack it.
The first enemy I made with this system is a simple melee enemy that will slowly approach the player and attack after a certain distance. When I make new enemies, I add two tabs: Melee and Ranged.
In fact, the two enemies may have different health, appearance, and attack methods, but they actually use the same Spirit.
I then added enemies with shields, the main change is that I can take damage with shields, but the most interesting thing is that I can build on this to make more difficult and complex enemy types.
After making three enemies, I started making game bosses, because with these methods, you can actually make unique bosses very quickly. On top of the shielded enemy, I added the ability to shoot at the next action, and I did different attack methods and reactions to take damage, such as going into rage after reducing health by half, and when the boss died, I just added a dialogue script and added a new boss tag.
Next I made a second boss, because it is easy to do, and if we look closely, we will find that the core logic of the two is the same, of course, there are a lot of differentiations, which are not described in detail here. The biggest difference is that the new boss adds more plots, such as its goals and motivations, and also does different defeat dialogue.
It's a completely different type of enemy because after doing two bosses, I'm thinking about how to make a new enemy type. This time I added the label "upgrade", for example, it may be just a small mushroom-like monster at first, but after upgrading, it becomes more powerful.
The design of this monster didn't take long either, I just changed the enemy behavior, the way they attacked, and added a new label. It will actively upgrade, if it has not been upgraded, it will look for resources that can upgrade it to eat, and the attack method after upgrading will also change.
The big difference here is that two ways of upgrading and downgrading have been added, the latter of which has not yet been used, but can also be added if necessary, such as the upgraded enemy after taking enough damage to downgrade, the ability becomes lower.
This is the last enemy spoken of today, an enemy that can be poisoned, and if the player gets closer to them, the enemy will passively release poisonous particles. I just updated its attack method, added a toxic tag, and actually only takes about an hour or so to make a new enemy every time, because with this controller, it's actually very simple to do, I just need to think about how to diversify the types of enemies.
What are the benefits of a code base?
1. Rapid creative prototypes
With these code bases, it has helped me a lot in my research and development. For example, in the creative prototype stage, when I work on my own game projects, I can still spend 40 hours a week to outsource, and each creative prototype takes less time and effort.
In this way, sunk costs can also be reduced, for example, you can try more creative prototypes, if you feel that it does not work, you can immediately stop, without causing particularly large losses. In addition, these code bases also make me more comfortable when using the Unity engine for R&D, especially if you don't have team support, and you especially need tools to improve R&D efficiency.
2. Quickly share the version
Another help is sharing, for example, the creative prototype is basically playable after a week, although it may not be fun or very good, but I can test it through many features in the code base, have more time to do debug, and can share it with others in the first place.
Usually, you don't have that much time to do this in the creative prototype stage, but with more mature modules such as menus and archives, I can directly send the playable version to others for testing, especially last year, when most people work remotely, which can be a lot of help.
3. Easier to do accessibility
Another point to mention is accessibility, when you do this kind of functionality at the beginning of the project, then it will be easy to make when you actually start research and development. For example, color blindness tests, high contrast modes, etc., in subsequent projects, if you have time, you can do more specific, if you do not have enough time, you can reuse previous resources, functions and systems.
4. Expand the game content
Doing so also enriches your game, has more time for game design, art, and story, and can experiment with and iterate on higher priority features. With these tools, you can accelerate content production with the R&D tools you already have.
5. It's easier to help others
With such a code base, you can easily help a friend or colleague. The gaming industry is a very small circle and it's great to share it with each other. If I don't have that, when someone asks me how to do a feature, I might have to look up a lot of code and put a lot of work into it. In addition, when I work on other projects, such as outsourcing, with these resources, I can refer to my own tools to help them solve bugs and complete the parts you are responsible for on time.
Of course, if you have enough time and resources, you can also redo a project 100% from scratch. But the best part of my career was when someone said that in a new project, he didn't see something that was featured in the previous game, so that's what the codebase does.
In fact, the game is made up of different wheels, or sharks, and I hope that this pre-prepared tool will make your future projects smoother and more efficient.
····· End ·····
GameLook Daily Game Industry Report
Global vision / depth is material