Write games, not engines

edited in General
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 :)

Comments

  • edited
    The fact that you must have an engine to build a non-trivial game is a fallacy, something perpetuated largely by people who don’t know any better.
    Sums up the whole article and what everyone here has preached for a long time, sometime with success, sometimes not :) I guess in the end it just sounds preachy to those who are technically inclined (and some topics like religion, republicans, macs, lol).

    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 :)
  • Haven't read the article(yet) but I think something that happens in the mind of technical people when they start making games is that they actually think they are building a game while building the engine. Which is bad because you get a sense of accomplishment but no closer to making a game and this becomes demoralizing. This is what happened to me anyways.

    @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. :)
    Thanked by 1edg3
  • Speaking of patterns, the sequencer pattern is pretty useful!
  • Sometimes the game and engine are inseparable however, such as with Minecraft. Perhaps you have a really interesting idea for a game, but no available tools can do the job. It gets a bit funky then :)

    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.
    Thanked by 1tbulford
  • edited
    Is Minecraft inseparable from its engine? (Maybe you mean when it was created a few years ago?)

    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?
  • @BlackShipsFillTheSky: I mean, that there wasn't anything out there (to my knowledge) that Minecraft could be built from. The 'voxel' world and all that goes with it means it needed it's own tech.

    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
  • I think the point of the article is that the goal of building an engine for building an engine's sake is a stupid one. He says that trying to build a game is the much better approach, that doesn't mean you can't build new tech for whatever game you're trying to make. In fact, it's actually best to build new tech that way: Otherwise how are you going to know what it is you need that tech to actually do?

    Minecraft's systems were built to make Minecraft the game happen. Not the other way around.
  • I agree there. An engine for engines sake is not the right approach, unless you're trying to compete with UDK/Unity. But then, that's not making games :|

    Well, the engine should serve the game's vision, not the other way around.
  • Looked a bit more into how Minecraft works. True, it couldn't run that well in something like Unity without massive effort or access to some low level stuff.
  • edited
    @BlackShipsFilltheSky: I dunno, there are a lot of Minecraft-esque things out there in Unity, the Unity forums are full of people asking questions about how to do things. Fucking with meshes and stuff isn't really too hard in Unity, you just need to figure out how you're going to store your world information in a non-mesh-based format. Then, when you've changed the world data, rebuild meshes as needed.
  • I saw a couple people tried it and the results looked a fair bit slower (with the mesh building) than Notch achieved in his engine. I would have thought it could be possible, with GL functions and whatnot. But I imagine it's a very easy thing to cause to run slowly if you aren't as technically skilled as Notch. Like for instance if I tried it (smiley face).
  • edited
    @BlackShipsFilltheSky Here is a game that's similar to Minecraft: http://mythruna.com. Haven't tried it personally, but minecraft-like things with similar performance can be done (determined by the engine's limits of course). Though lower is always faster though, but takes more time and adds more risk to you wasting your time.

    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.

  • I know I am late on this but for me, building the engine is half the fun. I code for me, it is the world into which I escape and in which I can set the laws/rules/guides and then create a character to break them.

    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
  • edited
    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.
    This feels like a pretty common misconception: People keep thinking that saying "Don't make engines" means "Don't write any code or algorithms yourself". It's exactly the opposite, saying "Don't waste time writing stuff other people have already built", with an added "don't get stuck optimising stuff before you have something playable".

    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? ;)
  • edited
    If getting sucked into low-level mathy algorithmic tech wasn't fun, for at least some people (including myself) we would never talk about this. And it can have benefits in terms of learning things about programming, algorithm design, math, optimisation, and a whole bunch of other stuff.

    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.
  • You guys are absolutely correct except that you are missing my point, which is reality for me, but as I said, maybe not for you.

    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.
  • edited
    @LazyLizzard: What may be reality for you is an untested, unfounded assumption for hundreds of kids trying to make games and starting out the wrong way. Those kids get to a point where they have a black triangle onscreen, make it spin, add a shader and give up. That's the wastage that I'm trying to curtail here.

    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 ;)
  • 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.
    Making games is what we're all about here (this is MakeGamesSA, after all). We care about producing actual playable games. Every time this discussion comes up, people here will tell you that building engines is not an effective way to produce actual games, and not an effective way to get better at making games. We have all learned this from experience.

    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.
  • Well, not essentially entirely wrong. You just have to recognise that you're not making a game, you're making an engine. And if your engine is useful, people here will use it.

    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.
  • @Squidcor: Why would we want to chase anyone away by telling them this could be the wrong forum for them? @LazyLizzard has already made pretty good use of the forums to get feedback on a game he's working on, chillax maybe?
    Thanked by 1tbulford
  • DISCLAIMER: Before you read my reply, please take what I am saying with a pinch of salt if it seems personal, it's not meant to be. I am just extremely technical and a a raw programmer at heart and not the strongest in terms of communicating what I mean without some long winded boring explanation that probably won't make sense to you. I hardly ever speak up about what I do because even senior programmers have a hard time keeping up. That is partially why I seem new to most of you, but I have been around the block and it's why I perform such a specialist role in my career.

    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.
    What may be reality for you is an untested, unfounded assumption for hundreds of kids trying to make games and starting out the wrong way
    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?
    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.
    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.
    Thanked by 1EvanGreenwood
  • Woah woah woah. I'm not trying to chase anyone away. Nor were my comments aimed at LazyLizzard specifically. I'm sorry that it came out that way. I'm just trying to explain why people on this forum always respond with "make games not engines" in these discussions.
  • I enjoy the technical challenges that come from building an engine from scratch. Its rewarding and certainly fun (given you have the time).

    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
  • edited
    Ask yourself why aren't they on these forums and if they are, why aren't they speaking up?
    Because, historically, it's not a successful development pattern... Quick history lesson: There used to be a local game development community called SA GameDev. I was a member. It never made anything - no games - because it was a place that people were totally happy talking to each other about how awesome the new engine they were about to start building was going to be. None of these engines ever really materialised, the most productive engine back and forth resulted in some minor changes to a bunch of id engines that teams like TomazQuake had already done and documented. Nothing playable emerged at all (I think there were 1 or 2 projects that hit a playable stage, but they fell over shortly afterward).

    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.
    @tbulford said:
    If we make people feel unwelcome because we didn't think they would finish there game what would that make us :0
    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.
  • @dislekcia Not sure I understand what you mean misunderstood, it was after all a rhetorical question. Either way if someone feels unwelcome due to intentional action or unintentional they feel just as unwelcome. If its happened several times then there is cause for thought. I feel writing it off as they were all just insecure doesn't grow the community.

    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.

    Bottom line: People know their shit here, despite sounding like they're advocating certain "easy" solutions.
    There are no easy solutions, but there might be less difficult ones.
  • @dislekcia: I happily accept the history lesson and acknowledge that I can clearly see and appreciate that people know their shit here, it's pretty obvious straight off the bat and the main reason why I saw this board as being different to SA gamedev and sadeveloper both of which I avoided like the plague.
    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?
  • edited
    @LazyLizzard: Sounds like a plan :)

    Still curious about your pathfinding...
  • Will share it when I have a chance. Been doing all if this on my phone. Again remember it is what I discovered, whether it is common sense to someone else is irrelevant to me :)
  • edited
    Hey, just to chime in. Though I think this topic has been resolved nicely now.

    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.
    LazyLizzard said:
    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,...
    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.
    Thanked by 2tbulford LazyLizzard
  • edited
    To just add to what @BlackShipsFilltheSky is saying, I think it's super-important to point out that working with existing game systems is how programmers learn game programming skills.

    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 ;)
  • edited
    Also adding to the above (and also to be clear, definitely not an attack on @LazyLizzard and his work! As @dislekcia said, there is a playable game [!] and the engine is not a general purpose pie-in-the-sky affair but solves the problems needed for his game [!] and I look forward to play it on Tuesday!)

    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.)
  • edited
    hermantulleken said:
    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.
    Do you mean games industry or enterprise industry or in general? (I think previously stated that I think there is a shortage of games industry programmers in SA who can reliably produce pleasing game systems, but I think you weren't referring to that?)
  • I was actually talking about what @Lazyizzard said:
    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.
    I think what I said holds to some extent for the games industry in our country as well; although it may need some qualification. My main point is still: lower level does not make you a better programmer.

    (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.)
Sign In or Register to comment.