Write games, not engines
This here article explains the heading.
It's a lesson I learned the hard way and one I hope you guys don't have to learn too :)
It's a lesson I learned the hard way and one I hope you guys don't have to learn too :)
Comments
I think eventually they either 1) come around or 2) go do something else besides (attempt to) making games.
Cool read :)
Also, the rest of it are also good reads, I'm just now discovering what a singleton is and it does change the way I think about my (super noob) code :)
@Tuism, If a singleton blows your mind you should google "design patterns, gang of four" and see what comes up :P But honestly I don't think you even need to worry about stuff like that. It's great to know about design patterns. But not entirely necessary to create games. :)
I'd say it really comes down to the requirements of your game. But don't start your game-dev journey by embarking on a massive idea involving a custom engine. It'll surely end badly.
I don't think console middleware support is great for indies at the moment, but apart from games needing to eek juice out of last gen consoles, or work on fringe devices, and AAA titles, I can't think of any game recently that needed its own engine.
That's not to say they don't exist, just that, I can't bring one to mind.
In my mind anyway an indie game made today that has to have its own engine, that isn't needing it for the sake of hardware, would be really radically different to most games we play. Though maybe I have too much faith in middleware?
At least, in my experience with UE, it's not possible to create something like Minecraft without fundamental changes to the engine. Maybe there are a dozen MC imitator engines out there now though :P
Minecraft's systems were built to make Minecraft the game happen. Not the other way around.
Well, the engine should serve the game's vision, not the other way around.
I have written a minecraft-like thing before. I won't call it a game or an engine really. I just did it for learning OpenGL and it kinda got outta hand from there. Never intended to do much with it, but it was a good learning experience. I managed to get the same view distance as minecraft with similar performance, BUT with my optimizations the world was set in stone as it was generated. Changing it would cause rather big lag spikes. Also I had very basic lighting (one lighting level throughout the world). I think minecraft's design must be borderline genius.
Yes, being an experienced programmer helps as early in your career you get side tracked by anything and everything. So while I won't make an absolute statement by saying I won't eventually go unity or some other framework the notion of not improving my skills by trying to create better, smarter systems is absurd. Again, this holds true for me, but maybe not for any of you.
My list of corporate examples is classified, but in real terms I would have never discovered my clever little path finding technique if I didn't figure it out myself and without it, I wouldn't be able to draw thousands of independantly moving Zombies on the screen. No, I don't use A* or any variant thereof.
What I can say is that it takes me more and more CV's to find suitable candidates because of this mentality. It appears as if more and more programmers can link 2 existing pieces of code, but can't create either.
Maybe I'm just old school, but I believe this is all part of the art
If your game needs large numbers of independently moving actors, awesome, go ahead and mess with algorithms that will let you do that, research vector fields and all that jazz, make up weird crazy algs that might just work, whatever. The point is that you're solving an established need in your game, the code you're writing is novel and immediately applicable. What you're not doing is writing code to try and potentially optimise some vaguely foreseeable imaginary problem that hasn't even happened yet because you heard that's what game engines are all about because bullet points on the back of game boxes said so.
Writing the code to display triangles on screen is a complete waste of time when there are so many systems out there that already do that for you. Which would give you more time to devote to solving the problems unique to your game... Most people trying to write engines never even get to the point of having a game in the first place.
And there's nothing to say you couldn't implement your pathfinding alg in an existing engine, is there? ;)
But it won't help you to learn how to make games.
It won't help you get games out of the door.
And in particular: it won't help you write well-designed code to be used in games. This is one of the most dangerous misconceptions. People that write engines that don't make lots and lots of games write bad engines, because the things they do not learn (on a technical level, and simplified in a nutshell) is how data needs to flow in a game, especially when it comes to support multiple genres and logic setups (for example, an engine that works well single player or multiplayer, with opponent AI, procedural generation, etc.)
I also know you would have come up with the (perhaps I should say "a") path finding algorithm if you used a higher level tool if it was required. Using an engine does not suddenly diminish your intelligence; it just allows you to put it to different problems (usually, ones that help you make more games) :P
For the reason of understanding things such as dataflow, given two otherwise equal programmers, I'd always go for the one that solves the problems we are facing on the highest possible level. Because if we did go a level lower for certain aspects, I know his/her code will be better for the other aspects.
I *could* probably have discovered the path finding a different way, but everything I did up to that point formed part of the thinking process which ultimately lead to the idea and discovery. That experience would have been vastly different had I not been working on my engine at the time. Of course that does not mean I could not have discovered it otherwise and I completely acknowledge that. For me, as an indie/hobbyist games programmer, the process is more important than to push out hundreds of games. The satisfaction of doing it relieves stress and helps me focus on being a good artist. To me, code = art.
Why re-invent something someone else has already done? Simple. For the same reason you play a game that someone else has already finished. It wasn't you. It's a cliche, but it's true for me.
I never insinuated that using an engine diminishes your intelligence, rather, I am pointing out my stance because the overwhelming view seems to be that an engine is some form of black box that should be avoided and for the most part I agree. BUT, it has a knock on effect, both positive and negative. For most people, it means less hassle which means daster turnaround times which means more games. I get it. By far most of my time was spent on my map editor, making maps and drawing graphics. The engine wasn't nearly the mental overhead it is made out to be. Again, true for me and true for my experiences up to this point. When that reality changes I will obviously adapt. Also, reference point is limited to 2D, platformers and isometric games. I get motion sick so I avoid 3D, lol.
I would really question the statement of people who don't make lots and lots of games writes bad engines and ask exactly the opposite by saying people who never writes engines makes bad games. Both are flawed assumptions that are essentially meaningless. It could be true, or not. Who knows.
So, unless you are building the next unity, it's horses for courses. Bad code is bad code, period. Whether that is in your engine or in your game or wherever.
The final statement is a little vague and confusing for me, maybe I am thinking too corporate and not from a gaming point of view but if you have two otherwise equal programmers performing a task and one solves the problem on a high level and one solves it at a low level, the preferential is determined by code review and cost/benefit. As you said, they are equally skilled so I would expect the same quality result at both levels.
I don't think you're properly aware of the experience of the developers that are saying people who write engines with no game in mind make poor engines. We've all made our share of engines, good and bad. We've watched hordes of people assume that they're this generation's Carmack and end up never producing either a game OR workable engine.
I will never understand why proud programmers always want to argue this point so hard when they start out... I guess I shouldn't worry: 2 years down the line, if you're still making games, you'll be the one telling the new people the same thing we are. Maybe there's no way to dissuade certain kinds of mind from the path that this sort of thing leads to... It's just that every time this argument pops up again it subverts and confuses the kids who might not have chosen the engine path, who might have taken the other road and ended up not giving up. It gets a little frustrating.
P.S. Actively using engines is both the better/faster way to gain the experience necessary to help you guage when to write something low-level or not. Actively using engines also exposes you to more interesting unique algorithmic problems more often, as you're working on gameplay, not the latest shader implementation from GPU Gems ;)
If what you truly want is to make games, and then make better games; you don't want to be re-inventing anything if you can avoid it. If your heart lies elsewhere, this might be the wrong forum for you.
If it's not, well, then it's not, and you'd have learned why it's not.
I don't want to build engines I want to build games, but that's not what everyone thinks. An analogy (and truth) is that I always wanted a 3D printer, and was gonna build one, then saw a bunch of technical difficulties in building one. Then I examined what I wanted - and that's really to have a 3D printer to print 3D stuff, not to build a 3D printer. I don't mind if someone else builds it and I get to use it.
BUT there are people who really want to build the 3D printer, and when I ask what they want to print, they haven't even thought about it yet. Those are the engine builders, and they know that they are, and are comfortable with it.
I also have a [verifiable] combination of [serious] ADHD and [slight] OCD and over the years I've learnt to work with it without medication as it wasn't properly discovered until my son had problems too. So I have very little sympathy for people making excuses for getting side tracked or losing focus. It's a convenient excuse as far as I'm concerned because I have all the reason in the world to say "hey, its not my fault" and I don't. It is a very selfish vantage point but I don't look for excuses, I look for solutions and ways to work with what I have and ironically, that makes me exceptionally good at what I do. It makes me come across differently to what I intend because I get side tracked most when I think about words and names.
I don't mean to insult, imply or otherwise rock the boat in the normal realms. What I say comes from my viewpoint, personal experience and the headache of a career spent fixing the bad code, bad designs and bad decisions made by people who could prove they are right but couldn't make it work. This viewpoint clearly differs substantially to what most of you do and how most of you see things. So if you are unable to accept that I am not attacking, but here for the same reasons you are, then please don't read any further as I'm sure to offend you unintentionally. I do hope that you read though because maybe you can learn something from me and maybe I can learn something from you.
So...
@Squidcor: I you truely believe that you are about making games here, how can you substantiate pretty much telling me this isn't the forum for me if I'm one of the few who is actually doing it all from the ground up and making it work? For my game, the actual engine was a couple of days. The map editor & maps took weeks and drawing graphics took months. The rest is gameplay and, as pointed out to me, lacks a bit. BUT, how much of that would have changed if I used unity or some other tool? I am being judged on what I did for a few days in my game development. Not what I spent the majority if my time on. So am I therefore NOT focussing on making better games? I asked for feedback, @dislekcia and @BlackShipsFilltheSky and @Tuism gave me good feedback to work with. So I changed my thinking and are looking at it. I am actively admitting my approach was wrong and am changing my ways because of it. How is that not about making better games? At the same time, how is that not about personal growth? So how do you separate it all so clearly and with so much comfort? Why should the fact that I wrote my own engine over shadow that. Why CAN'T I ask for advice and feedback on my engine simply because every time this argument comes up I get thrown with a textbook. I replied to this thread because this theme of being incredibly theoretical comes up pretty much everywhere on the forum and I'm not convinced that the kids who are starting out that are being referred to would even have the courage to speak up here. I waited several days before I replied because I was afraid. I was afraid I might explain myself wrong or say the wrong thing and get exactly what I got and get exactly the same argument as I got from people who have long moved on to other things at work and left their horrible code for other people to sort out. So what's the point then? Maybe you are right, maybe this forum is about making games rather than having some experience or fun while doing it. I don't know, but I'm willing to try and willing to share and willing to expand my thinking processes. 100% True. Except there is no such thing as right and wrong when it comes to doing something you love. Also, I'm not a kid and I'm definitely not starting out. The fact that making games is not a career for me doesn't imply that I have no knowledge or experience to share or that the things I've learnt in the corporate world as a programmer or in my part time gaming world's don't apply. As a programmer, dabbling in games/engines was how I honed my skills. The fact that I never wanted to release any game I made or engine I made was the whole reason why I shelved some ideas and moved on to others. After all, it is a lot more fun to take your boring day problem and solve it at night using a guy with a sword. Assuming that I'm a junior developer, who is just starting to learn the ropes is an error and one I am pointing out to avoid further confusion. I am new at sharing my experience and talking about it openly though. Again, I reiterate, I agree that for most people something like GameMaker [et al] is a good idea. If you want to have the best of all worlds, use something like Unity. If you are like me and you know how/why/when to do something different, then do it yourself only if you really want to and if you are willing to keep yourself on the straight and narrow. For me, that last bit was a lesson learnt the hard way. I would probably be coding in C++ and Direct X (As I did before) if I had more time. But the more I browse the forums the more obvious it becomes that I'm alone, lol. You'll notice in my welcome post that I am alone in the corporate world too, a one man team. When complex things go wrong and people want reasons as to why, that's when I get involved. I'm paid to provide facts. To be efficient and clinical. I have to substantiate and I have to prove everything in triplicate. It's annoying, so I don't want that in my gaming life too, hence why I've never been active on forums, why I chose only to publish tools and which is why I'm mentioning it. If that means I need to take a step back and not comment and not point out that there IS indeed a world out there in which some people do things differently, then I'm happy to do that, but I was hoping that it wouldn't be the case.
That said, you can get side tracked no matter what/how/when/with whom and how many you do. If you don't have what it takes to finish something you won't finish it and if you look hard enough at everything except yourself you'll find lots of reasons why. Heck you might even start a blog or write an article of why you failed and ultimately be truly satisfied pinning the blame on some design deficiency or the fact that your dog kept on licking your leg. Who knows. That article will become the internet net sensation for those millions of others who are looking for reasons as to why they failed and before you know it, you have a trend. That is true for most things on the internet. Find me an article saying one thing, I bet you I can find you one that says the opposite. What you are doing in the process is blaming everything and anything to avoid the fact that you didn't do it or to re-enforce your beliefs so that you can push it onto others. Period. It's the same kind of argument as researching everything for weeks before you do anything simply to go back and do what you were going to do on day one in any case.
This of course doesn't mean that I am right, you are wrong or you are right, I am wrong or that bob is right and will is wrong. It merely means you can justify anything if you look deep enough and hard enough. I find it more fun to do than to argue, to go through the process than have the nett result. To learn by doing than by forming an opinion by reading. So sure, you might have better odds if you can focus on something like your gameplay and forget a little about the engine but that doesn't hold true for ME. This is something I pointed out repeatedly, for ME. Because of that, I might actually need some support/guidance/pat on the back on the forums beyond "dont do it" or "rather use Unity" or "Why are you doing this, go read this theoretical paper on y". I am not against theory, but too often we use theory as a stick to beat others. That and I'm more practical than theoretical, but I do read. I read a lot. I have trouble communicating what I read, but that doesn't mean I don't understand it, or I don't apply it.
So going back to my path finding example, the thinking process I was in while building the engine is what gave me the idea. It is what set the stage and what gave me forward momentum to think about certain things in a certain way. If I was doing something else, I might have had a different idea. Or, if I was using Unity I might have come up with the same idea in a different way. The fact is, based on the evidence, I discovered it while working on the engine. Instead of having a long winded argument about it, why can't that be the end of it? Why must it be pulled apart and over analysed and used in ways that it was not meant? Again, I agree. However, the downside is that programmers end up focusing on what something looks like instead of what makes it tick or how it fits together. That in itself isn't a problem, but, follows the trend of the South African job market where there are an over abundance of half baked coders out there that are nothing more than spaghetti coders with 10+ years of experience. It creates an attitude of buy/want for free/I can't do it myself yields results where sometimes entire projects are the nett result of google'd code that was cut and pasted. With that we lose a part of the thinking process that people like K&R used to make C or Microsoft used to make Windows or Sun used to make Java. It's probably an engineering discussion more that a games discussion but the principle is the same. Heck I don't know if that came out right but I have work to do and can't sit and type this all day, I have binary to dig into lol.
The whole reason why I extended my reach by trying to share that it is ok that if you WANT to dabble in more than just the nett result of making a game was because it clearly lacks representation and I enjoy the process and I'm sure there are thousands of people out there who ARE the same. In fact, I know quite a few. Ask yourself why aren't they on these forums and if they are, why aren't they speaking up?
Would these forums be a worse place if it represented a broader or narrower section of the South African game "making" community.
I will build an engine today only if I have no other choice. For example when there is no engine to use in the first place. Point of example would be the PS Vita port of our game. I believe there is place and fair reason to nurture the skills required to build an engine from the ground up even if you assuming no game will follow. If we make people feel unwelcome because we didn't think they would finish there game what would that make us :0
It might be worth considering having a [Technical] category for such discussions since I know it only interests a few people here. And perhaps those of us that like the idea but don't have the time can build an engine vicariously through those with the time and the desire to do so.
+=5c
So eventually I got frustrated and, on a different forum, challenged people to join me in making a game in a month in Game Maker. It exploded, grew a whole bunch of careers and, eventually, turned into this place via an extremely painful merger with SA GameDev (which had stayed around with a tiny core of users who all hated the new community for some reason). The attitudes you're seeing here are a direct result of the culture that grew a functional, productive community in contrast to a stilted and stagnant one.
Sure, more technical posters would be cool, but you're assuming that most of the people here aren't technical, just because we're concerned with efficiency (of both learning and production). I find it interesting that you still haven't spoken about your actual pathfinding alg at all. Why is that? It's also interesting that you're talking about 2D systems when game engines typically handle much, much more complex stuff than that. "Engine" is a stupid, largely useless catch all term that confuses a ton of people. Perhaps that's where all of this is coming from.
And finally, you sound pretty unique given your specific mental makeup. That's cool, but don't assume that your specific solutions to focus problems (which sound like cultivating hyperfocus of a type many people simply never attain) are things that everyone else can do. Experimentation and history have shown that regular cycles of feedback coupled with focusing on producing games instead of generalist engine-style code (seriously, how are you supposed to know how to order your world data if you don't know what operations are going to need to be performed on it? Yet people keep trying to build generalised scene-graphs because they think that's a defined "engine term" that you have to tick off) result in the greatest motivation, not only in keeping new people learning, but also in keeping people producing games.
Don't be so quick to assume that anyone here is anti-technical, game development is a hard discipline that often results in huge projects, it's quite unlike any other form of coding I've done. Some of us do indeed have loads of experience in the corporate world (QCF's last project before DD was building a dynamic data-ferreting system for the local government, we had 2 months to do it in and 2 years of expectations - and budget - to meet. 1 month for detailed design and specs, we asked EVERYTHING. 1 month for implementation, 2 coders. Delivered on time and worked perfectly, beyond spec. Govt people had never seen that happen before... My current project, DD, has taken over 3 years. Why do you think that is?) and loads of us have spent a loooooong time staring at raw memory, trying to find out what the fuck X shader or Y texture or Z audio is doing in the middle of what should be the terrain data-structure. Compound that with console hardware that sometimes randomly doesn't give you the memory you asked for and... yeah.
Bottom line: People know their shit here, despite sounding like they're advocating certain "easy" solutions. They learned it writing games, not engines. All the engine-writing frustrations became aha moments as soon as that switch was made for most of us. There is a very high likelihood that you don't mean generalist engine wankery right now, but that's what the "build your own engine" meme means to many of us... So talk about your pathfinding alg already. Misunderstood. This has happened several times over the years and is mostly the result of people falsely defending a favorite practice or assumption they have. Their vehement feelings mean that anyone saying something different is attacking them, combined with a specific type of insecurity, this can make then feel unwelcome... That doesn't mean it's the intended outcome.
I would welcome technical conversations. Be it in depth stuff using engines or building them from scratch. I still vote for a specific discussion tag for [Technical] so people that do want to engage from that point of view feel welcome, since there is a space for those types of conversations. There is plenty of space in the forums for all manner of games development. There are no easy solutions, but there might be less difficult ones.
Like you I suspect, there are few things I hate more than theories and arguments and long winded unfocussed generalist work. I also can confirm that I don't mean generalist engine wankery but rather focussed effort to achieve a very specific result for a very specific purpose without digressing into the realms of what is not required, but while having lots of fun in the process.
I spend most if my time every day of my life staring at binary dumps and stack traces & dumps of some kind of another so I am certainly prone to simplify that with a tool if and when I can. <insert guy who has a problem with tools here /> lol
So without further bickering or confusing anything, can we call this a synchronization process that is complete and start working towards a goal common to all of us, to be inclusive rather than exclusive and not forget that we're here to have fun as well?
Still curious about your pathfinding...
I think it's awesome LazyLizzard is managing to write the engine AND produce something that people can play. I'm glad he's getting the joy of solving the really hard technical stuff and being able to express himself there AS WELL AS the joy of watching people play his game and figuring out how to craft a pleasing experience for them.
And I'm super glad LazyLizzard is doing it here : )
And I hope we can help him in his goals.
That said, I wanted to sort of differ on one thought that I felt wasn't addressed. It was part of @LazyLizzard 's response to @Dislekcia pointing out that @Dislekcia thought that working on engines and not producing games (as a result of not getting the engines to the point of making a game) is a problem. Which I think @LazyLizzard is expressing that those who find the quickest path to making games, without knowing the underlying layers, will not be good coders and so the SA games programmer market will have an overabundance of poor programmers (as the non-game programming market suffers from).
If I got that right. I'd just like to respond that, while I agree, I think that is not an immediate concern.
I think the real concern in the SA game development industry (programmer-wise) is that there really isn't much game programming experience at all. The problem being that, while I agree that many SA game programmers may not program well, very few can implement the game systems well enough to reliably make something fun.
If I were to be harsh (and honest) the number of game programmers that I feel could reliably lead a commercial game project in this country is less than 10. And one of them is leaving for the UK in November.
I think that's a more immediate problem. And I think that is specifically due to a lack of high-level game logic experience. And though the technical side may bolster the skillset of SA games programmers, it won't produce successful games without the high-level experience.
I'm certainly not saying LazyLizzard should use existing engines and scrap his work and experience. I'm just trying to explain why this engine question could be seen by some as very important.
I hope that doesn't come across as an attack on what @LazyLizzard is doing. It really wasn't intended that way, it really was intended to highlight a concern that I have (and perhaps others share) regarding the SA industry.
I know that this is the core thing that every person who says they enjoy the technical challenge of making engines disagrees with me on, but they're simply doing that because they don't understand how much work goes into a game engine. They don't understand how many systems all have to work together perfectly in order for a game to materialise at the end of it.
When you're working on a game, you're rarely ever just working on one specific problem. You're always dealing with how two or three distinct pieces of code interact - the interaction of multiple systems is how games become interactive themselves, after all! So that means that focusing on just one problem in order to learn what's going on and really understand the root of the issue is far more likely to be possible when you're using an existing game engine and the problem is gameplay-related.
That isolation helps people learn faster. Then when they do need to build their own engines, for whatever reason, they can use the experience they have to help them keep problems relatively isolated and thus solveable.
P.S. I totally think @LazyLizzard's talk of engines focuses on a much simpler concept of "engine" than most people imagine when they use that term. For starters, he's not going 3D. For enders, he's got something you can play - he must have spent time not working on the engine bits in order to make that happen ;)
To be a good programmer requires many different skills. One of them is of course putting instructions together to solve a problem (writing a for loop to print the numbers 1 to 10 on screen). That type of skill can be learned on any level (even "visual programming"-style). In this sense, there is no reason why a "high-level programmer" will be any better or poorer than a low-level programmer. Both have to learn the same thing.
A second skill is more domain specific, and is different for low and high-level programmers. The problems are different; on a high level you need to figure out for instance how to animate smoothly from one discrete state to the next. On a low level, you may be concerned with which shapes overlap. In general, totally different problems.
Now in this second sense, there is actually little benefit from having knowledge from the low level if you work on the high level. Two temporary (I hope) flaws in current technology makes it useful to know something underneath (for optimisation, and for working around engine bugs), but this is actually quite rare. Most (99% ?) of the time treating the engine as black box is fine.
On the other hand, if you work on the low level, knowledge of the high level is extremely useful. Because that tells you what problems to solve. Because they are slightly different from the ones you would imagine.
There are many examples even in commercial engines of this solving slightly the wrong problem. The one that's probably caused me the most sadness is how GUI system are often implement as if you want to make a web page or implement Photoshop. Game GUIs are different (they require much more juice [animation, sound, other effects], they have non-standard layouts, they sometimes animate in and out and so on. This require more hooks, more dynamic styling etc. When not there, implementing the GUI becomes painful, and you have to bend the system quite a bit to make it do what you want.
Another example is in physics. Without having made lots of games, the naive implementer may have collision boundaries coincide with visual boundaries (or physics size with visual size). In game, these are often different. And if the engine provider did not think of this, it may be a little tricky (and dirty) to implement.
It is for this reason that programmers will write bad engines (not bad code, mind you, the code may be very good!) if they have not made lots of games. Simply because they won't know what the engine should actually do.
(I don't think trends in there being more half-baked programmers has anything to do with the level on which these programmers learn their skills. I think it's simply because there are so many programmers required and so few of them, that even a half-baked programmer can get a decent job; the average is dropping simply because the pool is growing. If a company wants better programmers, all it has to do is provide better incentives: salary, location, perks, environment, etc. If it cannot make a business case for this, there is no point in complaining. There is not a skills or talent problem. If anything, there is a business problem, and a solveable one. In fact, the fact that it is not being solved means it is not really a problem at all. "The industry" is quite happy [in the cost benefit sense] with what it got.)
(I also put "The Industry" in quotes because I know I was being vague and evasive. Overall I do believe anyone wanting better programmers should either accept the impossibility or pay up [and most definitely not only money-wise]. If businesses control the education system, it would be a different story, but since they don't, all they can do is try to get more people to pick from . But this is more a side point.)