23 ms·
Create your own Game Engine but don't use it
- ganoushoreilly 9y agoI think a lot can be said for someone trying to go their way, and learning the value of a prebuilt solution. A lot of people would stubbornly keep trying to build their own "because they could build better" rather than focusing on the end outcome of a playable product.
- CJefferson 9y agoOn the other hand, I find my game engines, particularly (unfortunately) open source ones, are in a terrible state. They often try to support many platforms, then it turns out they usually support one platform well, and the others are various degrees of broken. Then, when you want to get your game working on Android, the engine is too massive and complex for me to have any chance of figuring out how to fix it.
- oneZergArmy 9y agoThis is why i prefer frameworks like LÖVE 2d. it's so simple that I can keep everything I need in my head. I like just staying in the text editor.
- crucini 9y agoDo many game engines force you to use a GUI?
- pjmlp 9y agoDepends if you want collaboration with designers or not.
- CJefferson 9y agoI really wanted to like love 2d, but I found the community very unfriendly, and there were some fairly simple old bugs that have been around a long time. Also, I was looking for something to teach children, and they seem to like "hilarious" library names like anal. (This is not one of the problems I asked about, I knew better than to ask someone to rename something).
- striking 9y agoThey recently (about a year ago at least) changed nearly all of the library names. They also had the friendliest community I had ever been in on IRC, besides maybe #haskell. Sorry to hear you had a poor experience, I'm shocked to hear things had changed on that front.
- CJefferson 9y agoI'll have a look, because I am still on the lookout for something after scratch -- I currently use pygame but I love the idea of love2d. Maybe I just caught the IRC channel on a really bad day, or asked some particularly offensive question, without knowing what I was doing.
- TillE 9y agoToo massive and complex, plus if you want to do anything a little unusual (eg, procedural generation) you'll often find most engines are working against you. I can't imagine writing a 3D game from scratch in this day and age, but for 2D games I think it's absolutely justifiable to just grab something like SDL2 and go.
- crucini 9y agoSeems to be a subset of libraries and frameworks in general. They are not up front with the limitations of their software, so you have to invest a lot of hours finding them.
- avaer 9y agoInteresting contrast to the Carmack school of thought: _do_ build your own game engine and don't even reuse anything you made before, because you'll know better this time.
- thomascgalvin 9y agoMost of us aren't John Carmack, though. When you're the guy that basically invented the genre of code you're talking about, there's a very good chance that your next project will advance the state of the art. When you're basically a hobby coder looking to get an game in the app store, it's a slightly different story.
- emodendroket 9y agoBeyond that, it's not the 90s anymore; what novel feature are you going to implement that is going to wow anyone in the way that Carmack's engines did?
- aaron-lebo 9y agoI wish modern games could get the basics as right as Carmack's engines did. What good is the tech in No Man's Sky if visiting untold numbers of planets feels like a slog through mud?
- juliangoldsmith 9y agoGame mechanics were a lot of what always set id apart from everyone else. You could always count on them for smooth, fast-paced action, without much in the way of frills. While their new games are still quite good, they seem to have begun to slip a bit after Carmack's departure.
- musha68k 9y agoHuge Carmack fan here but I feel the need to defend the latest hi-octane Doom incarnation from 2016 - IMHO great controls, fast old-school gameplay, superbe graphics.
- golergka 9y agoI've worked with Unity from the beginning of my career as a developer. (Used to be a game designer and producer before that). I haven't quite understood what's so special about it before I tried other solutions, including open-source (Cocos) and in-house ones; turns out, a LOT of things that Unity devs take for granted (like asset pipeline and management) are lacking elsewhere. Sure, a senior developer should be able to write his own game engine from the lowest level - but he almost never should actually do it on a real project.
- aphextron 9y agoI think a lot of developers who come into game dev have a mistaken view of Unity as the "budget" choice based on the poor quality of many of the indie titles shovleled out with it. But Unity is probably the most advanced game engine in existence today. Far beyond Unreal 4 in terms of both performance and tooling. The reason the average quality is so low with Unity titles is because of just how easy the technical aspect of making a video game has become with modern engines. The barrier to entry for creating a game with AAA graphics is now a $20 shader pack and the ability to hack together some C# scripts.
- emodendroket 9y agoI have pretty much no experience with game development, but why is UE4 such a popular choice for commercial games if that's the case?
- aphextron 9y agoMost big studios are still on UE as a matter of momentum and the aforementioned biases. Unity really only became viable in the past 3 years, which is shorter than the average AAA game development cycle. Also certain games such as FPS are still better off with UE, as that's what it was designed for.
- emodendroket 9y agoWell, the examples I had in mind are, like, Guilty Gear Xrd or Tekken 7, where there isn't any obvious history or genre reason (to me) to pick it. But maybe it's just old prejudices, as you said.
- lfowles 9y agoPossibly leveraging existing C++ experience.
- emodendroket 9y ago
- aaron-lebo 9y agoA year is nothing in the grand scheme of things. If you can't invest a year into building tools that could be your foundation for the next 3 decades, then what you are building is just a quick-rich scheme that doesn't matter. Use whatever you want because it doesn't matter...and your game probably isn't going to sell anyway. Those are the odds. But as they've pointed out, you kind of need to know that stuff anyway, so it's time well spent. I don't have a ton of gamedev experience, but at least graphically that game isn't doing anything you can't do in a few hundred lines of C++. Maybe that's part of their problem. Why use Java if you want to make a mobile game and it isn't well supported on one of your primary platforms? That sounds like a bad fit. Unity and Unreal are super cool but they are also bloated with features that you don't need and lacking in others you do. For the longest Unity required you to use 3rd party modules for a camera. A camera....something that takes a few lines of code for a basic implementation. Why didn't that come standard? If you really want to hurry to market yet another game by all means use one of the existing engines. It might even work really well. But if you want to do anything interesting, you're gonna be doing custom stuff anyway.
- kevindqc 9y ago>For the longest Unity required you to use 3rd party modules for a camera. What do you mean? How can there not be cameras? How then can you view a scene without that 3rd party module?
- aaron-lebo 9y agoGoogle "unity camera scripts" for an idea of the kind of functionality that people were grafting onto Unity a few years back.
- thomascgalvin 9y agoThis can be said about plenty of things. Encryption is probably the most obvious; there's a lot of benefit from reading about and implementing various encryption methods, and absolutely foolish to use any of that work in a setting where it might actually be attacked. The article is pointing out something that should be obvious; if you're making a widget as part of a larger task, your implementation will probably be lacking compared to one developed by a team solely focused on making the best widget they can. I could write an HTTP server or a threadpool or a database connection layer if I really wanted to, but thousands of talented people have invested millions of hours in those tasks already, and I'm not likely to do better than them on my own. Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. In my day job, I'm working on a (relatively) trivial problem that's never been done before, because there are about ten people in the world that need it. As a hobby I work on a text editor that is completely customized to my personal workflow, and which will probably never be used by anyone else.
- aaron-lebo 9y agoIndeed, but there are a lot of situations where a focused specialized widget made by a small team will be better than a general "best widget" made by a large team. The further you stray from the use cases of the "best widget" the worse it gets. Writing another HTTP server does seem like an inefficient expenditure of time, but we wouldn't have Nginx or smaller tools like Mongrel if the existing "best tools" were good enough. Game engines benefit you even more to be custom because the further your game strays from another Unity game, the further it stands out from the crowd of 100,000 smartphone games.
- aphextron 9y ago>Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line of code". You learn that it's all about layers of abstraction, and understanding that the human brain is far more useful and efficient at problem sets higher and higher on that scale of abstraction than it is at twiddling bits.
- kbenson 9y agoThis is good knowledge for whatever your field is. I've created a few ORMs. I don't use any of the ones I wrote, but I learned a lot in doing so. I've created a few web routing systems. Again, you can learn a lot, but unless you actually want to spend a lot of time writing and extending one, just use what you learned to help you pick a good one.
- steeleduncan 9y agoThis blogpost gives the other point of view: http://www.spacesofplay.com/blog/why-we-built-our-own-tech-for-future-unfolding/ http://www.spacesofplay.com/blog/why-we-built-our-own-tech-f... Essentially that the engine you use can constrain what you create, so write your own.
- thehardsphere 9y agoI've considered a stack like that myself for less exotic looking games. It's nice to know someone who actually has gotten farther than I have is making similar choices and that those choices are working for them. I think the choice boils down to project scope and the relative size and skill of the team. If a game of your scope is already well served by an existing engine, it makes sense to use it. If you have a large team with a particular skill set, it makes sense to cater to their skill set by picking the engine they know. For any other case, rolling your own makes sense, provided you know what the scope of the project is in advance. The common mistake (that maybe the guys in the parent article also made) is that they assume "game engine" is some necessary prerequisite to making games, so they spend time working on all of these technical problems that are not actually their game they want to make.
- Kenji 9y agoThank you for presenting an encouraging counterpoint. I think own game engines can work, but you'll probably have to stick to 2D or 2.5D because 3D introduces such great amounts of additional complexity - and even though 3D is not extremely hard, it's a huge time sink.
- zellyn 9y agoOther games with interesting/different visual “looks” and custom 3D engines are Reset and The Witness.
- alol 9y agoHaving a broader understanding of your domain at a different level of abstraction is always extremely valuable. For anyone interested in the detail of _how_ to create a game engine from scratch, I'd recommend checking out Handmade Hero https://handmadehero.org/ https://handmadehero.org/
- fellellor 9y agoHandmade Hero is over 380, hour or two long videos last i saw. How far are you into it? Regardless, it's an amazing effort.
- moomin 9y agoYeah, it grossly understates the effort required to create a decent game.
- nbm 9y agoI've watched pretty much every episode, mostly live. It is pretty amazing. It also pretty much single-handedly reinvigorated my love of programming. But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build. https://hero.handmade.network/episodes https://hero.handmade.network/episodes is a must if you want to cut some corners on what you watch. Off the top of my head, here's my suggestions: * Weeks 1-15 are all useful - it's really a great introduction and kool-aid provisioning system * Week 20 and 21 has some introductory lighting stuff. * Week 23 and 24 has some good performance profiling stuff. * Week 25 and 26 has some multithreading job queue stuff. * Week 28 and 29 has SIMD/SSE sound mixing implementation * Weeks 36-38 has debug/performance infrastructure * Day 235 and weeks 48 and 49 are the start of OpenGL initialization. * Week 74 discusses particle systems * Weekend 3 discusses compression * Weekends 6-14 are the core software-renderer-to-OpenGL days * Weekend 23 is a re-implementation of lighting The other stuff is exploration of concepts that are either specific to Handmade Hero, or are much deeper implementation detail type stuff - not entirely necessary if you're skimming.
- krapp 9y ago
- sbov 9y agoIt seems like you can learn a lot of that by building a game without using a game engine at all.
- crucini 9y agoThere's no absolute answer to the "build vs buy" conundrum. A lot of us are biased towards "build" and its useful to recognize that bias in our decision making. But the "buy" side often has hidden costs. In the author's case, which involves targeting multiple platforms, the "buy" side gets more attractive. In general you are deciding whether to code on platform X or on platform Y built on top of X. Fashions come and go, and if you invest heavily on top of Y it may become "obsolete". Will you be willing to stay on Y when the developer/community has abandoned it? You may have to reinvest to port onto Y', while X remained somewhat stable. The higher level the platform, the more likely you are to hit surprising limitations late in the process. Your role gradually transitions from technology producer to technology consumer. Programming an AVR chip in C gives you a great feeling of space and power because the platform is so clean, while using Arduino you rapidly hit limitations and spend your time getting around them. Higher level platforms tend to make the easy things easier and the hard things very hard. I wouldn't rule out the subjective factors. For many of us building is more fun than sorting through what others have built. The brain works a lot better when having fun, which is why MBA-style decisions about programming don't always work.
- mherrmann 9y agoDeveloping indie games is hard enough. Starting off by building your own engine is crazy (unless there are _very_ good reasons). They unnecessarily and gravely harmed their chances of success in a very competitive niche.
- karmadog 9y agoThere's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound each other. All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead. Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes for C# (a task which Unity does for you). Languages that require JIT for performance don't work on mobile (unless supplied by the OS, e.g. JavaScriptCore). Debugging becomes extra-difficult. C/C++ are not convenient to use, but not hard to use either. It causes discomfort at first, but you get used to it. Being forced to do memory management manually also helps with learning how to structure programs, with a bonus of not having to wrestle GC pauses. Having said all that, using a commercial engine is totally fine, of course.
- dakics 9y agoUnity's multi-platform track record is quite solid at this point in time. I wouldn't bet on exotic Java attempts of "write once run everywhere" though.
- kuschku 9y agoJava is actually not that bad – Java with LWJGL gets you within a factor of 1.6 to C++ performance, while actually being "write once run everywhere" (for PC, at least). That’s good enough.
- deleted 9y ago[deleted]
- thehardsphere 9y agoThe mistake that most people make is thinking about whether or not they should make a "game engine" when what they really want to do is make a game. If you want to make a game, make it. If it makes sense to use somebody else's engine to make it, then by all means do so. If you aren't going use someone else's game engine (which is a perfectly valid choice), skip straight to making your game. After you've made a game or two, you'll know whether making a "game engine" out of what you've written previously is a worthwhile effort for your next game.
- psyc 9y agoWorking on low level engine things for 15+ years lets me wield Unity like a sword now. It's a mid-level sword, but my technique makes up for that.
- advice_giver 9y agoThis blog post and the comments here are amazing. In no other software field but indie game dev does spending a year trying to build your own toolset instead of $ACTUAL_PRODUCT_THAT_MAKES_MONEY draw praise.
- thehardsphere 9y agoIt's cargo-cult word-thinking. "Game engine" is associated with "game" because of the success of id Software, Epic Games, Valve, CryTek, et al. So people who don't think the way programmers do, have the impression that a game engine is a required step in the software development process to have a successful game.
- thefoxbard 9y agoI really don't think the issue was with "creating x from scratch", but from the purpose it was built for. Game engines like Unity are general-purpose engines, they are not made for a specific type of game, and can be used for basically anything. The trade-off is flexibility and performance. What they tried to do was to basically create a "clone" of Unity, that is, they tried to create a general purpose engine, and that does not make any sense at all for an indie developer. If you're going to create a game engine + editor, then do it for a specific genre of games (e.g. FPS), and do it only if you're planning to create a series of games that belong to that genre only. Unless you want to create a business out of selling game engines, then have a specific game in mind before creating a game engine, and tweak it for that purpose only.
- krapp 9y agoThis is apparently what I've been doing for about two years. Except I still haven't gotten to the "engine" part, it's more "a bunch of wrappers around Lua and SDL2 and some random stuff that seems useful, and probably the worst ECS ever." I actually did almost get to an actual game, though. But I was so disgusted with it that I gave up and started everything over from scratch. Mind you, everything worked fine, I just hated every thing about the code. And this is why I am an amateur programmer and a professional box-pusher.