I've tried to write my own game countless times. And I finished a very few of them, all because of bad design decisions, which made my code hard to read and even sometimes painful to look at. Even through 5 years of working as developer I'm still struggling to write a nice designed code. I read about design patterns a lot of times, it helped but not as much as I thought it would. Most of tutorials online using bad design practices.
So, I want to ask you to suggest an open source plaformer-like/zelda-like game with which design is good in your opinion. I lookd a lot of them by myself but didn't found what would seem good for me.
I've found personally that looking at other's code can both be helpful and damaging at the same time. But unreal engine has a fairly good amount of sample games ranging from moba's to first person shooters, you can look at their code base for free. But just be weary about it. Looking at other's code can turn into emulating it without fully understanding the intricacies.
But just be weary about it. Looking at other's code can turn into emulating it without fully understanding the intricacies.
As much as I like Unreal, it's a great example of this. Since it's a commercial game engine, Epic has a strong motivation to make most common things easy to use even at the cost of efficiency and simplicity. They've added a fully functional garbage collector and reflection system to C++, for example.
As long as you keep context in mind, I think browsing other's code is usually helpful, if a bit slow. Do it if you want to find things to avoid as much as things to try out.
One option could be to post some bad part here in some way (brevity is likely important, so it needs some thought, I think), and ask for ways to improve it.
Alternatively you can post code at some other site, like a pastebin or github or so.
Fabien Sanglard's code reviews are great also - http://fabiensanglard.net - a good way to get up to speed on those code bases without having to decypher the architecture yourself.
I learned so much of my own game programming knowledge from reading (and modding) the Half Life 1 code base. The engine is closed source, but the game code is available. The gameplay architecture is bad by modern standards (incorrect use of OOP everywhere) but the separation of engine, network, client and server responsibilities follows the Quake model closely, so is quite clean.
Please do not equate open source games with good architecture design. While looking at source code might help, there will come a time whereby your needs take priority over following other engine's code structure. Don't dwell too much on fancy design patterns (most of them suck quite a bit), keep to writing simple code. If you really need a base to start from, learn entity component systems and continue from there.
I've tried to write my own game countless times. And I finished a very few of them, all because of bad design decisions, which made my code hard to read and even sometimes painful to look at.
Stop worrying about your code design, you've seen first hand what it does to your projects.
Code is about functionality, not design. You're not painting here. Too often I've seen people rewrite entire subsystems because they were "ugly" only to make things worse in the end, or to throw it away and rewrite it from scratch because it "doesn't look nice" (losing features in the process).
You're not working on some kind of enterprise software or in a large team, so just let it go. You can refactor later if you really need to.
On 7/14/2017 at 6:28 PM, ????????? ???????? said:
I read about design patterns a lot of times, it helped but not as much as I thought it would. Most of tutorials online using bad design practices.
I'll let you in on a little secret: the reason your code is so painful is because you're trying so hard to conform to design patterns or some kind of overarching set of "rules" that you think you're supposed to be following because the faceless coders of the internet say that's what good coding is.
The link ddengster posted is a good one and proposes a nice solution to approaching code. Definitely give that a read because I think it'll help a lot.
" rel="external nofollow" style="background-color:rgb(255,255,255);">This video should also give you an idea of why you're struggling. (Ignoring the somewhat clickbait-y title).
Spoiler
Now let's say you were in a big team working on a large software. I'd still say there's common fallacy among all of the principles and design patterns you come across: the idea of making code easier for others to read and use. People talking of the mythical "user" when they talk about their interface.
To me, this is a huge red flag. This "user" doesn't exist. At best "user" represents an unknown coworker or peer. But let me tell you, 5 minutes of your coworkers time is not worth hours of yours. I'm all for keeping code easy for your peers, but if you're spending more time than it would take to learn your code trying to architect it, you're probably over-engineering.
I'd suggest to simply toss the idea out the window, because it's unproductive. Just code. Do it simple. Be straightforward. Just get your idea into the PC and make it work. Don't write complete garbage, but don't stress too much if it ends up being dirty at first.
Then when it's working, take some time to clean it up as a last pass where you think it's needed. You might think it's inefficient to do because you may potentially need to rewrite parts of the code to fit your new structures, rather than planning up front to prevent that extra work, but I guarantee you you'll save more time than you think you're losing. You can't possibly plan for everything in advance so you will inevitably end up reworking it half way through, costing you more time. And even after this, you'll likely have spent a long time planning it. In the past I've spent entire afternoons planning large subsystems only for them to fail 1 or 2 days into development, being replaced not long after by something practical and simple on the spot when the flaws of the plan became glaringly obvious (when they were invisible during planning).
On 7/14/2017 at 6:28 PM, ????????? ???????? said:
So, I want to ask you to suggest an open source plaformer-like/zelda-like game with which design is good in your opinion. I lookd a lot of them by myself but didn't found what would seem good for me.
I don't know of any platformer engines online off the top of my head (you could look into Löve games but those are in Lua).
It might be more complex (and FPS-centric), but idTech 4 (Doom 3) is a good one to look at. According to things like SOLID principle, etc, it's actually pretty awful. But in practice it's very easy to follow.
Similarly Steam's SpaceWar example is also simple in the same fashion and frankly it's better than what I've seen most people write considering its simplicity and clear violation of many coding principles. Might be a better option as it's far smaller and 2D. You can the code for SpaceWar with SteamWorks.
