Games made in godot6/9/2023 The way the scene system works allows to apply a “divide and conquer” approach to developing games (instead of caring about meaningless things like MVC, subdividing in components, etc.). It encourages productivity above all else in the design. When I work on a game, I want to get things done as quick as possible.Īt this point, many readers might have noticed that Godot was created to develop games this way. When I work on Godot, I make sure the design and architecture are as flawless as possible. What you lose in organization, you win by orders of magnitude in development speed. Let them work the way they like, quick and dirty, but just make sure they write clean APIs to communicate with other programmers. Just make it clear that every programmer in the team has a clear role and area of responsibility. In reality, it takes way longer to develop this way and it’s hardly cheaper in the long term. The rationale is “We should be able to replace programmers at any time, so code must be readable and maintainable”. Lead programmers require clean and organized code, which results in very slow development. If it doesn’t, don’t touch it.Ī common excuse for this is teamwork and many programmers working on a game. If you are planning to make the code cleaner at some point, it has to be because it gets difficult to work with it. Make it quick and dirty and just get it to work. Don’t apply design patterns or encapsulation for the sake of it. If you are writing a game, just write things as fast as you can and as simple as you can. This often results in code with excess encapsulation, which in turn results in codebases that become a severe pain to modify when your spec changes. This overlaps with another situation I’ve seen countless times, which is programmers caring too much about “doing things correctly” and “good practices”. I’ve seen this so many times I can’t count it with my fingers. Another case is engineers claiming they find success in not using OOP design (while they use it anyway, without realizing it or admitting it). One situation I’ve seen repeated over and over as a consultant is having to deal with engineers that lie to themselves about successfully applying MVC to their game architecture (and making a complete dish of spaghetti and meatballs as a result). ![]() Design patterns, or lack thereofĮven applying standard design patterns isn’t warranted to work. This does not work in game programming, because you are more concerned about how the player feels than what he or she will do. From the use cases, all interactions are conceptualized. Software engineering is based on listing requirements and developing use cases from them. In many situations, it’s just impossible to get it to work and realizing it has to be abandoned in favor of something else is a very difficult decision to make.įrom the technical side, the processes taught in university don’t generally apply. In game development, your initial implementation of gameplay is always broken, and needs iteration to improve. It covers many disciplines but can’t borrow much from their processes.įrom the artistic and creative side, artists (painters, musicians, writers) will usually conceptualize something and later add depth to it. Making games is very fun, but very difficultĭeveloping games is difficult. I tried to contact many of the devs to ask them what the reasons were and, in most cases, they were not technical but related to the scope of the project being difficult to manage. ![]() Many games were released, but a large amount were abandoned. The biggest strength of Godot is that, due to its design, it makes it really easy to throw in code that works (and scales to large projects) without worrying about the game architecture. Since Godot was released, I saw many developers work on awesome projects with it. I’m sure others have written about the same topic, but this article is written from my own experience, in hopes of it being useful. I didn’t become rich (yet :D) making games, but I learned a lot in the process… and nowadays I enjoy developing Godot more than anything else. I also owned several companies and helped others on the business side so I believe I have a clear enough picture of the whole process (which does not meant it’s failure proof, it never is). Generally, my responsibility ranged from programmer to project owner, but most of the time as technical director or technical consultant. Despite being the lead developer of Godot, I have almost 20 years of experience developing and shipping games, and a decade of experience as technical consultant. The motivation for this article is that many devs asked me to write it for a long time. ![]() Compiling Godot takes increasingly more time, so I guess a new setup is one more way to accelerate Godot development. Today I’m reinstalling my development computer, so I can’t do much programming.
0 Comments
Leave a Reply. |