The best response to this is Derek Yu's article on finishing a game.
The guy in the video made all the investment fallacy mistakes, all the scope mistakes and all the resource mistakes, but managed to avoid the engine mistake and finished the game eventually anyway. That just emphasises how bad an idea it is to make your own engine - most people who try that never finish anything, even if given 13 years.
There are benefits to having your own engine. The key is not letting "make the engine" be a goal in itself. Make the game, and as you go along, identify the bits of your code that will eventually become part of "the engine". Also, not every part of your "engine" needs to be written from scratch. Most of what you likely need to achieve already exists out there with some liberal licenses attached.
Why does this always come up? What is it that you thought I was saying that needed countering?
I mean, I'm curious as to what these benefits are supposed to be and if they actually exist enough to be worth bolstering the incredibly harmful misconception that game engines as imagined by the idea of "building an engine" are even a thing that exist, but mostly I'm just wondering what it is people THINK I'm saying when I write that...
@dislekcia I believe the benefit is that you can be so lazy that you can avoid having to learn how to use an existing engine (that professionals spent years on making and optimizing). In the end though, this initial laziness will cause you to do more work creating something that will necessarily be inferior to the existing engine
Let me rephrase that to "There can be benefits to having your own engine", by which I am also saying that no one rule/piece of advice is going to be applicable to everyone.
If you need to do something simple, why have all the added bloat of a fully-featured engine, for example. If total ownership of your code base is important to you, then that too is a good reason to use your own. Also "engine" is not always going to be something all-encompassing. And I am putting engine in quotes because what the hell is that even? Hence me saying that making an engine should not be your goal, even if you end up with one.
The warning/advice that it's bad idea to build your own engine comes from this thing that very often happens where devs spend ages making a game engine but never actually get around to making a game. Or they do silly things like code a physics engine from the ground up, when they could have just plonked in Bullet Physics. Yeah, don't do that.
Not sure if snarking there Tuism. :P But oddly enough, Unity3D is probably overkill for what I am doing with it at the moment. Definitely have neither the skills, the time, nor the will to do a more "pure" implementation though.
No no no I wasn't snarking, I was just observing the fact, and that it may have had to do with your attitude towards the topic. ME's probably one of the rare projects that did its own engine and didn't die a horrible engine death, from what I've seen :)
Only the (very simplistic) Twine->Unity thing is our own. I'm hesitant to use the word "engine" to describe it.
For a great example of "own engine" combined with super-productivity, I suggest following the Limit Theory developer videos. It's the dev's first commercial game but he seems to be a master craftsman. His "IDE" is just vim and clang. Not sure if he uses SDL2 though or if he codes directly against OpenGL.
EDIT: Nope, no SDL - he's just churning out code by the bucketload over there.
@dislekcia I believe the benefit is that you can be so lazy that you can avoid having to learn how to use an existing engine (that professionals spent years on making and optimizing). In the end though, this initial laziness will cause you to do more work creating something that will necessarily be inferior to the existing engine
Hah! That's the first time I've heard someone suggest that laziness is the reason people want to "build their own engines". Usually it's the other way around, with the people who use already existing tools being reviled for their laziness and/or "cheating" :)
Let me rephrase that to "There can be benefits to having your own engine", by which I am also saying that no one rule/piece of advice is going to be applicable to everyone.
Argh. I hate that bolded chestnut so much! All it does is give people already deep in the throes of the Dunning-Kruger effect an easy way to insist that they're definitely special somehow and thus they're the exception that whatever advice has been hamstrung with that caveat definitely doesn't apply to them. I much prefer statistical approaches that at least carry more context. At least that way there's at least a chance at comparison and evaluation instead of outright dismissal. I know that phrase isn't trying to say the proffered advice is bad, but that's how people receiving it often take it after that phrase comes out.
If you need to do something simple, why have all the added bloat of a fully-featured engine, for example. If total ownership of your code base is important to you, then that too is a good reason to use your own. Also "engine" is not always going to be something all-encompassing. And I am putting engine in quotes because what the hell is that even? Hence me saying that making an engine should not be your goal, even if you end up with one.
The warning/advice that it's bad idea to build your own engine comes from this thing that very often happens where devs spend ages making a game engine but never actually get around to making a game. Or they do silly things like code a physics engine from the ground up, when they could have just plonked in Bullet Physics. Yeah, don't do that.
I'm starting to feel like a main focus should be disabusing people that are just starting out of this idea of an all-encompassing "engine" that magically makes games possible. There's no such thing, it's literally a construction of marketing messages around games with few other comparison points besides technical mumbo jumbo in the 90s and we're all stuck with it now... I'd much rather tell new people that game engines as they think of them don't exist, thus their attempts to write one are probably futile, than keep being told that my advice doesn't hold because a genius once did something amazing.
I personally agree with @dislekcia's view on people believing that they're special. To quote "She's just not that into you":
“We're taught that in life, we should try to look on the bright side. Not in this case. In this case, assume rejection first. Assume you're the rule, not the exception. It's liberating. But we also know it's not an easy concept. -He's not just into you” ― Greg Behrendt
I'm starting to feel like a main focus should be disabusing people that are just starting out of this idea of an all-encompassing "engine" that magically makes games possible. There's no such thing, it's literally a construction of marketing messages around games with few other comparison points besides technical mumbo jumbo in the 90s and we're all stuck with it now... I'd much rather tell new people that game engines as they think of them don't exist, thus their attempts to write one are probably futile, than keep being told that my advice doesn't hold because a genius once did something amazing.
This I agree with. If you look at Josh Parnell's work on Limit Theory, he never mentions the word "engine". He's just making a game. The side effect is that by the time he's done he'll have a nice big ol' chunk of code and libs that he can likely use in future projects, which you can view as his engine.
All it does is give people already deep in the throes of the Dunning-Kruger effect an easy way to insist that they're definitely special somehow and thus they're the exception that whatever advice has been hamstrung with that caveat definitely doesn't apply to them. I much prefer statistical approaches that at least carry more context. At least that way there's at least a chance at comparison and evaluation instead of outright dismissal. I know that phrase isn't trying to say the proffered advice is bad, but that's how people receiving it often take it after that phrase comes out.
I don't disagree here. And you said the magic word too, "context". I am more worried about people who are so desperate to be handed the magic recipe and therefore willing to accept any advice without context. And in general I believe it's bad to give advice without context. This coupled with the fact that there are so many chronic advice givers out there who drop little platitudes on Twitter where there's no room for context, that people get misguided fast. And the advice is usually not bad, just that advisees often suck at evaluating what applies to them and what not because the advice is rammed down their throats as absolutes.
I think @dislekcia is contradicting himself. He uses other peoples engines and yet he thinks its useless to create engines. maybe to him game engines were made by Aliens, or beings not belonging to earth. Unity 3D or Game maker came from space man. We human beings are so stupid that we are incapable of creating sophisticated computer science applications, maybe the universities should cancel subjects like CS or Applied Math because they are useless, They wont make You productive in the 21'st century, you just need to learn politics, both unity and GM in a month and you are good to go, everything else will be made aliens and robots. People like me who are fascinated by how engines are working internally should just become hair barbers and forget about our Dreams because we will never beat aliens at doing them.
@dislekcia thanks for discouraging me that the knowledge of reading hundreds of books on game engines since 2007 is hogwash. And maybe now I'll give up all the demos Ive been doing all this years and go for a macdonalds job. thanks for yr courage.
@SkinnyBoy: It seems like your comment might be designed to incite some sort of argument, but I'll assume you feel like you are unable to get your point across without snark, and try and respond according to the way I see things, to hopefully put things in a different light for you. Also in the future, maybe try and post comments that aren't so antagonistic.
Firstly, I don't believe anyone implied that game engines just appear out of the aether, and therefore making engines is bad. Compilers certainly don't magically appear, and yet it is a bad idea for people to make their own compiler. You might try argue this last point, but I would like to see any evidence to back up such a claim. Also note that I am not saying that because making a compiler is a bad idea this implies making a game engine is therefore also a bad idea, merely that the necessity of game engines doesn't imply that everyone that needs one should make their own, as seen with compilers.
Secondly, your remark about CS or Applied Math seems to imply that somehow, just because you are able to do something (to some degree), it means you should be practically doing it at some point, which is not true. A similar situation occurs in digital security: cryptography is a difficult subject, both from an implementation and integration perspective (hence the need for relevant education), but it is well accepted that writing your own cryptography system for production is a really terrible idea, even if you are well versed on the subject.
So while the above certainly doesn't try argue that making engines is bad (although it is alluded to), it argues against the points for making engines that it seems like you are trying to make.
And just to make my view clear: I think that writing your own game engine is actually pretty similar to writing your own compiler or cryptography system: it takes a long time, and chances are that you won't do a good job in comparison to the alternatives. That doesn't mean you aren't free to study them and try things out on your own, just don't say you're making games - you're "just" researching one aspect of game development, and it's arguably not a very good avenue of research if your plan is to make a game. Also note that this comment completely ignores the very grey area around what a game engine actually is (in terms of where to draw the line), but I'm pretty tired of this subject at this point, so yeah...
EDIT: I realise my last remark about making an engine being research is not always true, but the rest of the paragraph is still valid so I just crossed out the wrong part.
EDIT 2: Just for background, also note that I have written a: small compiler, core portions of a cryptography system, and a few small game engines, but those cases were strictly for research or fun (I'm weird), and not with a realistic end goal of programming, security or games respectively.
Well some reasons might not have a reason. If I like making game engines I continue buying Game Engine Programming books. Or maybe I just like the sense of ownership or maybe not begging for money. One Example is I like making construction games so I invested time on learning about Isometrics tiles and bought 4 books covering the subject, one bonus is that two of of this books included chapters on websockets, accidentally extending knowledge on my java networking skills, enabling me to create an entire multiplayer engine and saving thousands of dollars if I had to buy Electrosever or SmartfoxSever. Having an entitlement or entire ownership to my code might not be a good counterexample to my reason above.
But maybe I just like making engines for the sake of making engine not games. Its a sort of entertainment for me, and that I own it, I can do anything with it.
Why would Mark Overmass(Game Maker Creator) or Mario Zechner(LibGdx Creator) write entire books on teaching Engine Programming if they believed you can only use theirs and not be able to compete with them. Maybe its just a Science fiction movie.
And On the premises about compilers, maybe learning about them might make you invent something new that human beings have never seen before or if you survive world war 3 or global warming, your knowledge will greatly be appreciated in reinventing computers. So possibilities are endless, think about mixing cryptography with Stem cells and Natural Language Processing.
Maybe I'm weird too, but for me, just like Trevor Noah said: "Crazy is Normal"
"I wanted to make my own drum music. I realised while programming drums that it was cheating so I programmed samples. Then I realised using samples was cheating so I recorded real drums to make my own samples. Then I realised using samples was cheating so I bought drums and played them. Then I realised using bought drums was cheating so I made my own. Then I realised using premade skins was cheating so I bought a goat and skinned it. Then I thought that was cheating too so I grew my own baby goat. I just realized that is also cheating but I'm not sure where to go from here. That being said I haven't made much music lately, what with all the goat farming and everything."
(I'd love to attribute this, but I don't know where it's from, and Googling it takes me to someone who quoted it but didn't attribute either. :()
@SkinnyBoy there's nothing wrong with doing research and making things that make games. But then you're making things that make games. Around here, we prefer to advise people who want to make drum music to not farm for goats and people who want to build houses to not have to build a cement factory, or people who want to have a cup of coffee to not have to start a coffee bean plantation.
Though I really appreciate people who farm goats, build cement factories and start coffee plantations :) but I know those aren't what I wanna do :)
@SkinnyBoy: You seem pretty negative at the moment. Are you okay?
As for "engines"... Well, I don't advise trying to compete with the massive teams and budgets behind tools like UDK, Unity and Game Maker. That's especially bad business sense when trying to compete without, y'know, knowing what you're competing against. I really don't understand what it is that makes people defend the concept of an "engine" so vehemently.
I also don't understand why books are so important... I've built compilers at university, written my own renderers, collision managers, scene graphs, resource managers, network layers and stream loaders. Most of that was just implementing algorithms I'd read. You know what I'd never read about anywhere? How to build the systems at the core of Desktop Dungeons, how to keep game actions deterministic across a network, how to procedurally generate space ships or how to make a maths game that taught and inspired learners. That stuff isn't in any book ever, just like all the game-specific logic that people who love writing toy-problem "engines" continuously ignore. So yeah, maybe your book learning isn't that wonderful, it was great when you started, but now you should probably move on to actually testing your skills against the juicy problems that nobody else has ever seen: The ones lurking in your own game ideas.
And if anyone feels disheartened by my advice on this topic, make more games, that'll fix that disappointment right away :)
@SkinnyBoy In short, making games != making game engines. It is possible for you to do either, but it will be hard for you to do both. If you make your own, I know you know it won't be better, than say, Unity Engine. So in the end, you will spend most of your time on the engine, and not on the game (in the event that you do try to do both). And if you make a game engine, it is likely that you will be the only one using it. Note, I used the word likely. Maybe you have some revolutionary game engine idea, and some fantastic marketing skills, but the market for game engines is quite saturated at the moment.
So we are not trying to dishearten you, we are trying to prevent failure from disheartening you. And failure is less likely if you leave the engine work to the big boys with the big budgets :)
It might seem that Grave Days is written in Unity, but don't be deceived. I used the bare minimum of the actual engine, and wrote my own engine on top of a very thin layer of Unity. I'll even go as far as to say I was ignorant of the fact that I was doing it. In the end I spend a lot of time trying to optimize, and improve performance for a large number of game entities. Sure, this will still be needed if I used Unity to its full potential, but I definitely less so. I have spent probably not even 1% of the time remaking this game the way Unity intended, and I am already nearly 50% as far in the development as I was last time.
Sure, you could say that the second time around goes quicker because I have learnt a lot (and yes I have, I have learnt how to use Unity), but at least this time around I didn't have to write a script (4 nested loops and recursion!) to try and mesh together all those goddamn tiny (NOT TINY ENOUGH) semi-transparent squares that I called my lighting system! Anyway, I'm sure you get the point :)
U guys don't really get my point. I never in way said its a bad thing to use unity, look at all my comments above and tell me where I said that.
I was saying maybe I like making engines for the sake of making engines "NOT FOR MAKING GAMES". I think im repeating this... Secondly, my type of games might not suit unity as you all think they might. Or maybe I might not like even like unity, or it might not suit my style of programming. Or maybe I just don't like the idea of not paying for stuff that I can make myself or maybe I just like the learning experience.
Count all the "maybes" I used and make your own conclusion.
U guys don't really get my point. I never in way said its a bad thing to use unity, look at all my comments above and tell me where I said that.
I was saying maybe I like making engines for the sake of making engines "NOT FOR MAKING GAMES". I think im repeating this... Secondly, my type of games might not suit unity as you all think they might. Or maybe I might not like even like unity, or it might not suit my style of programming. Or maybe I just don't like the idea of not paying for stuff that I can make myself or maybe I just like the learning experience.
Count all the "maybes" I used and make your own conclusion.
Nothing is impossible!!!
Making engines is a great way to improve on your programming and to understand how things like OpenGL and OpenAL work. Its is very time consuming but if that's your thing you wont really mind. I spent a good chunk of time developing a 2.5D engine from scratch and its helped me in a lot of ways (using different data structures, applying design principles, language tricks etc). Most people would opt to use existing tools like Unity and JME however I made a conscious decision not to very early on.
@SkinnyBoy, I'm going to point out something obvious you might have missed. This forum is www.makesgamessa.com. It's not really that hard to understand why everyone's responses here are formulated in such a way that they are trying to help you make games.
I don't think anyone said you shouldn't make engines either. The point they were trying to make was that you shouldn't make engines INSTEAD of games. It's something that most people are prone to do when they start making games, I know I was. So if you like making engines for the sake of making engines, that's awesome. I know there are things I do for the sake of doing them rather than the end result. But that won't bring you closer to making games, which this forum is all about.
I'm sure there are many other forums dedicated to game engine and related topics, but this is not one of them. That's not to say you shouldn't be here though. What I'm suggesting is that finding another forum to discuss these things will most likely result in a much more rewarding experience for you.
Just to reiterate, I'm not saying you should leave the forums or not participate. I'm simply saying we are here to make games, and will evaluate everything here based on that criteria. If you aren't doing that, then I'm afraid it will be a very frustrating experience.
@SubiyaCryolite: And what was that decision based on? I'm guessing it wasn't actual experience on your part?
There's nothing that says you can't write "engine-like" systems AFTER you've already gotten damn good at using other "engines". In fact, that's probably the best way to go about it - otherwise you're trying to make carpentry tools without having ever used a hammer.
@SkinnyBoy: Why are you so disparaging of advice that's designed to help people make games then? If you're not about making games, then obviously you're going to have a hard time gelling with a site that's all about that. Especially if that site has a long and storied history of watching hopeful newbies wasting years of their lives and losing that spark of interest because they believed (hugely incorrectly) that they had to write an "engine" first.
@SkinnyBoy, it seems to me that you keep repeating this: "I like doing these things, not necessarily for the goal of games."
And we keep repeating this: "Our primary goal is to make games, and we'll try to do it as quickly and as efficiently as possible because we want to make more games."
Please understand our response framed under that heading. If you'd like to talk about making engines... 1. Most of us won't bother with it, whether we're capable of it or not (personally I'm not). 2. You'd probably find better people to talk engine with somewhere else.
For example, going to a BMW site to talk about Shatterprufe glass and how its made is probably not gonna get a lot of response - sure BMWs make use of Shatterprufe glass, but BMW enthusiasts aren't there to talk about how to make their windshields.
Eh, not really comfortable with where this has headed.
I don't think we should ostracise people who want to make engines though. Claiming that this is "MakeGamesSA" and that those who want to make game engines should go elsewhere feels really wrong to me. Sure, making a living out of that in South Africa is probably virtually impossible (unless you're working remotely for overseas companies?). But if that's what you enjoy, go for it! And I don't think you should be discouraged from posting your experiments around here, as long as you make it clear to everyone that you're making a renderer, or making a physics engine, or whatever, and that THAT is what your goal is.
We get a bunch of people posting art, but that's acceptable (as it should be!) and nobody tells us that we shouldn't be making art, that we should be making games instead. On the other hand, I don't think any of the artists go around telling game designers that they need to study art before they can make a game, so I do kind of think that the anti-engine sentiment around here is reactive against engine programmer(s) telling other people what to do.
I just wince when people who enjoy making game engines tell people who want to make games that they need to make an engine to get there, and when those who make games tell those who make engines to GTFO. There's space for us to help each other, build each other up, etc.
And while those who enjoy making their own engines probably should be trying out existing, commercial game engines to see how others are doing it (with larger teams, bigger budgets, more experienced people, etc.), just as game designers should be playing games as a portion of their daily learning, I don't think very effective game designers spend 100% of their time playing games. Some portion of time necessarily must be spent on making them to be a game designer, and, similarly, some portion of time should be spent by an engine guy on playing around with making an engine. Granted, if it's not being used for a real-world project, it's probably less useful as an actual game engine, and sure, most of these problems are solved. But I do think that there are building blocks. I play scales before I play pieces. I do sketches and studies before I do full illustrations. There's value to doing things for the sake of learning, even if they've been done before. We recommend people make Tetris or Pacman, because even though they're "solved" problems, there is so much you learn about what you didn't know that informs what you thought about Tetris and Pacman, and what things were much easier or (more likely) much more difficult than you thought they'd be, and you learn from that experience.
I think a certain engine-oriented programmer around here has been super abrasive, in part because he goes around telling people what to do with zero game credits, zero samples of work, zero samples of cool tech, and telling people what "real programming" is while writing off all of the "real programming" that I know from experience goes on in "real" game studios. But let's not use reaction against him to push away engine programming in general?
Yes, there's a great example there - the artists and the sound guys around here engage on those topics here in a constructive and productive way.
The key words here:
1. Constructive. 2. Productive.
And thus the art and sound guys say things to assist in making games (constructively, it doesn't help saying this suck and that sucks and you shouldn't do that without replacing that with better solutions), and help them *actually* make games. I think ultimately that's where the difference is - no matter what we talk about, we want to ultimately be productive, to make things. We probably can talk about engines here if they result in results - things getting made.
We have very very seldom see any engine talk go into results, that's seemingly the problem.
I don't mind talking engines if they result in games sooner than two years later :) Grids is a great example. They're intrinsically an engine. But they made 30 games in 30 days. THAT is making stuff happen.
@Elyaradine, I agree with you that people should not be discouraged from posting things they are working on here. What I'm suggesting is that they not ONLY post here. Even though you post your art here and get meaningful(hopefully) feedback on it, I'm sure I've heard/read you say that you regularly post on other more art focused forums as well.
I sincerely hope more people want to make engines and I want to encourage people to make engines. Without them I wouldn't be able to even begin to make games(digitally anyway). So I appreciate people that make them, but I can't really help them. Unless they start asking questions on what I would like my engine to do or something. :P
Also, if I were an engine programmer, this is exactly where I would hang out; what better place to find out what types of problems people are really likely to run into, what they hate and love about existing tools, and just generally what their struggles and joys are.
(I also believe strongly that making games is the best way to learn what should be in an engine. Working on a certain layer benefits your knowledge of the design of layers downwards, not upwards as many people believe. We have also experienced it in quite a dramatic fashion first-hand, not only with the 30 games, but also with support questions about the things people want to do. Every lack in foresight (aka design problem) is a direct result in not knowing what people actually want to build, and what type of architectures and problems arise in those situations; i.e. design problems are caused by us not having made enough games.)
Though I do see learning about low-level enginy-stuff as something of a trap for many game programmers beginning their career. It's much harder to fail at learning about low-level enginy-stuff, as apposed to learning about gameplay systems, so it's a comforting avenue of research, and so also a trap (because most low-level enginy-skills aren't particularly instrumental in enabling success at game development).
I don't mean to say that people definitely shouldn't study low-level enginy-things, just that they should be aware they are doing so at the cost of not spending that time studying far more useful game development things, and if succeeding at game development is their goal knowing this might help them prioritize their time better.
But as the thread is about "Some advice for new Game Designers/Developers" I don't think it's unreasonable in that context to say: "Don't learn how to make a game engine before you learn how to make a game. Just don't. Learn to make games first".
To be dead honest, I do get tired of endless concept art posting... I fervently wish more people posting their art here would post re-skins of local projects (like @Pomb does) and get more involved in the game-making part that way. The big reason why I'm less vocal about that wish is that I don't have the experience to draw from. I'm also not certain how many aspiring game artists have been successful or not with particular approaches to growing their skills - all I have to really draw on is: Be as much like @Elyaradine as possible.
And yeah, I hate the idea of chasing people away. I do have to ask myself how many of the belligerent "engine advocates" from years past have stayed around and been productive though. How do we change that?
P.S. @hermantulleken exactly: I've built more and better "engines" since focusing on building games. It's incredibly annoying how that's always completely disregarded whenever I say it in this "debate".
P.P.S. I think the best way to stay positive is to be open about whatever reason things are being done for and accepting the experiences of others as valid when they talk about them (acknowledging the experiences of a newbie programmer and the joy they get from a toy problem is just as useful as relating the experience of an old pro) so that listening is more likely than dismissal.
@SubiyaCryolite: And what was that decision based on? I'm guessing it wasn't actual experience on your part?
There's nothing that says you can't write "engine-like" systems AFTER you've already gotten damn good at using other "engines". In fact, that's probably the best way to go about it - otherwise you're trying to make carpentry tools without having ever used a hammer.
@SkinnyBoy: Why are you so disparaging of advice that's designed to help people make games then? If you're not about making games, then obviously you're going to have a hard time gelling with a site that's all about that. Especially if that site has a long and storied history of watching hopeful newbies wasting years of their lives and losing that spark of interest because they believed (hugely incorrectly) that they had to write an "engine" first.
My decision was based on wanting to learn how OpenGL actually works. If Id stuck with JMonkeyEngine at the time I wouldn't have learned OpenGL 1.5, 2.0 or 3.0. I wouldn't know anything about Frame Buffer Objects, GLSL, OpenAL or skeletal animation. Its the same reason why Id rather code desktop applications by hand in swing than use Visual Studios form editors, I actually want to know whats happening in the background.
And that's great for the purpose of learning how this and that and that thing works. Whether that's great for making games itself is another matter altogether - and that's generally the matter that we all speak about around here :)
Learn engines if you want to learn engines, make games if you want to make games :)
My decision was based on wanting to learn how OpenGL actually works. If Id stuck with JMonkeyEngine at the time I wouldn't have learned OpenGL 1.5, 2.0 or 3.0. I wouldn't know anything about Frame Buffer Objects, GLSL, OpenAL or skeletal animation. Its the same reason why Id rather code desktop applications by hand in swing than use Visual Studios form editors, I actually want to know whats happening in the background.
Okay, I see. So I'm wondering if you'd made games before that, so you had a baseline to compare OpenGL against (otherwise, what made you pick OpenGL and it's future versions so strongly) and/or had a set of specific things that you wanted to learn to do IN OpenGL. How did you decide what to learn? And what use has that learning been so far, beyond like, padding out CVs with version numbers of things you can say you know (because that seems to be all that most of that stuff does on my own CV - I'd like to do more with it TBH) where are those things going now?
Wow... This thread has just exploded into a million pieces. TLDR: 1. Different people do things for different reasons. 2. We can all learn from each other. 3. Always take a minute and make sure you understand the context of somebody's message before replying with snark or in an antagonistic way. 4. Stop flinging metaphorical poop at people!
NOW! I would looove some advice. Relatively recently (I actually started at Ludum Dare) I got into UE4. All the shinies like the lighting and post-processing are nice, but my main motivation behind using it is for the Blueprint system (and their awesome pricing model). As an artist with no programming background, this system really excites me. While it is much simpler to pick up than straight-up programming, there is still a learning curve. I know most people would say that the best way to start learning is to create! But this is where I hit a snag.
How do you know something is worthwhile to do at this point in time? I understand that my first game will never be a finished, ship-able product, but I'm struggling with the balance of simplicity. If it's too simple, I might not learn enough. Too complicated and I might get frustrated with it and abandon it completely. How do you know if the idea you are pursuing is simple enough? How do you know it's not too simple? Is it ok to reach a point and realize you've learned everything you can from a game idea and move on, even if you didn't even nearly finish it?
I suppose what I'm asking for is advice beyond the usual "Just start making a game, but start simple" advice that most people have loaded in the barrel of their Advice-guns™. I'd love an Advice-gun™.
Sounds like what you need to do is calibrate your sense of "simplicity" of a game from both a design and implementation perspective. Right now, you have no way of knowing what doing something is going to cost you to work on, so you're looking at the advice people are giving and wondering how to evaluate it against the possibilities you have available.
The easiest way to calibrate your sense of this relative amount of work is to try to remove variables so that you're focusing on just 1 or 2 new areas of learning at a time. Basically, remake existing games to give you a sense of how difficult/simple they are to produce in whatever tool you're keen on learning. The perennial favorite is Tetris - not only is it a simple enough game to understand, it's also non-trivial enough to trip up nearly everyone that tries making it a couple of times at least ;)
Trying to make something established not only gives you a simple goal point at which you know you're "done" and can move on to something new - it also gives you a set of things to fail at, so you can know that you need to work on understanding X because you couldn't get it working and Tetris needs that before it's playable. When you're working on your own game ideas with little experience, you very rarely know what your final game is going to look like, or where it might fail, so you're searching in the dark.
Part of my own frustration as a developer right now is that my mental toolbox for Unity isn't as complete as I'd like it to be: When I look at a new game idea, a bunch of possible ways to make that work roll out in my head - Game Maker's paths are broad and well lit because I know it so well, XNA's paths are less shiny, writing my own systems is like a hike across mountains and I can see the peaks but I know there's lots of bogs and rivers and leeches, while Unity feels like looking at a city without a map and I can kinda see where I want to go but the alleyways and buildings inbetween are dark and foreboding. This happens for every game idea, because each implementation of an idea is just one possible way of making it from many in each possible environment/tool/platform. That sense of "knowing where you are" is what you're feeling you're missing.
That's a good thing to want to have, so that's an important feeling! Once you start messing with known games to see where their design space takes you "if you just do X or Y", then you'll know you're developing that sense.
My decision was based on wanting to learn how OpenGL actually works. If Id stuck with JMonkeyEngine at the time I wouldn't have learned OpenGL 1.5, 2.0 or 3.0. I wouldn't know anything about Frame Buffer Objects, GLSL, OpenAL or skeletal animation. Its the same reason why Id rather code desktop applications by hand in swing than use Visual Studios form editors, I actually want to know whats happening in the background.
Okay, I see. So I'm wondering if you'd made games before that, so you had a baseline to compare OpenGL against (otherwise, what made you pick OpenGL and it's future versions so strongly) and/or had a set of specific things that you wanted to learn to do IN OpenGL. How did you decide what to learn? And what use has that learning been so far, beyond like, padding out CVs with version numbers of things you can say you know (because that seems to be all that most of that stuff does on my own CV - I'd like to do more with it TBH) where are those things going now?
Made that in college using stock Java2D and JPanels. It was a rudimentary "engine" as well, when I transitioned to 3D(2.5D) I wanted to take a similar approach. It also helped me in landing my current day job as a programmer. The whole "I want to learn" thing went down well with them.
Wow @dislekcia. Thank you so much! That is amazing advice. Again, somebody else may have said "Remake an old game, because of reasons", but you really grounded your reasoning and gave me context to what I was actually asking. Wish I could double-heart your comment.
I have a strong suspicion I may just start with Tetris! :D
I love programming. When I started this thing called game development. I had the illusion that it's c++ or nothing. Started out using SFML and Box2D. We (@DraghtVader and I) started our first game like that. Slowly we started making a sort of engine to bridge the 2 technologies. 3 months later we had a guy jumping over platforms. Fun, yes but the same thing in Unity took as a day to accomplish. And it took as a day because of the learning experience we had from the "engine making".
The story is just to say that the engine "making" we did was not at all in vain but we slowly started losing focus on making a game which was our main focus and I think that's where the whole argument lies about engine making. It's not a waste but it does make you lose sight of the goal which you started out to achieve, if it was making games.
So here's the thing right, most indie devs don't really want to make high art, and I don't blame them, it usually requires major risk, tons of research, huge talent, lots of work, and the good fortune of having a team that has all of the above at that same point in time. You might disagree and say who's to decide what is high art right? Most humans have a basic ability to understand contrast, and the larger the contrast, the more obvious it is. Most games too, have a hook, a gimmick that separates them. Fracture had moveable terrain in a 3D shooter, Gears of War had Cover based shooting and gore, Uncharted had lush colorful jungle environments in contrast to Gears, etc etc. If you can be an indie dev and have a useful gimmick (like Ibb & Obb), already you've transcended 80% or more of the games out there and will probably get noticed because of it. Hopefully that will get you onto bigger things, and with the right group of people you might be a lead designer on something like Tomb Raider (not the reboot), or the next great virtual reality experience that pushes the medium into bold, new and interesting places. Good luck!
In the context of game engines my comment sounds very elitist, as if spending 1000 hours making an engine that never becomes a game cannot achieve 'high art' status. Or making a game that doesn't necessarily have a 'hook' or 'gimmick'. I apologize if anyone took this as such, and maybe I should have re-evaluated my choice of words in describing exactly what high art is in the context of game engines (and even games). There's undoubtedly a contextual quality to high art, where even though the creators work doesn't really stand out (like in the video above), their circumstances make for a different read. This is my brick wall as a game researcher, and due to the limited information contained in software it makes my job even harder. On one hand, its easy to break down games into components to form comparisons (this mechanic, that sprite, this setting etc etc). When I'm playing games all I see is these game design elements, not the context, the x-game designers with x-time, x-cash and x-hours of skills training in various disciplines. There are still badly managed projects though, games that are made with mixed motives, plain lazy workers and work ethic, and staff with very limited artistic skills. Knowing these elements should we call these games high art? If so then what kind of game will constitute low art? does it bottom out at a moving ball & paddle Ala Ralph Baers Brown Box? Is that the bare minimum of work to be able to say, yeah I made a game?
@silvaring: I'm not sure I understand what you mean by "high art", nor do I really see what is gained by using the term. Goal here is?
I can say that from the perspective of an indie game developer, I aspire to work on the best, most interesting, most rewarding things I can. I don't think it's fair to say that anyone who pursues a decidedly-risker-than-average-yet-lower-paying career is ever doing something to just get by, and I'd argue that anyone motivated by making a "quick million" in games isn't going to last more than 3 months when faced with the reality of what putting games in front of people actually entails.
I'm not really sure why an indie game designer should aspire to be recognised and offered the "opportunity" to work in a larger team, that smacks of a sense of gated legitimacy... Personally, moving to AAA seems like a huge loss of authorship, which is only something I'd accept if I weren't actually making things I cared about.
As for being able to say "yeah, I made a game" - that's easy: You've made a game as soon as you've given other people something to play that doesn't need you to explain it.
I'm not really sure why an indie game designer should aspire to be recognised and offered the "opportunity" to work in a larger team, that smacks of a sense of gated legitimacy... Personally, moving to AAA seems like a huge loss of authorship, which is only something I'd accept if I weren't actually making things I cared about.
To each his own :) Some people have the dream and desire to work in a large team on large blockbuster projects akin to those that they enjoy playing most. And while that might not be your slice of cake, I don't think that anyone who has those aspirations should be discouraged from chasing that dream.
@dislekcia Your game will be classified by different people, and some might even call it high art, using reasons to justify that label. When it becomes high art its basically a way of saying this game is worth paying attention to. With a world of games at their fingertips, this high profile reviewer chose to show 'your' game above all of these others. its status is thus elevated to a 'high' position.
I used the term because game designers should be aware of how their games are seen and consumed before sending them out to die/live so to speak. IF I'd just used the word art it wouldn't connote the same message, that being 'all games are art, therefore all games are valuable'.
You made a good point about the nature of game developers, to be clear I wasn't implying that developers should be or are in it for the money, I'm just referring to the difficult situation an indie developer faces when putting out a game into the wild, and the difficulties I face as a player/reviewer in deciding whether it is worth my time or not.
@AngryMoose I wasn't implying that bigger teams meant AAA. My suggestion was that game developers should not expect to make a genre defining/emerging game alone. They can make gimmicky games, or high concept stuff like gravity, maybe even an ambitious story project like Dishwasher Vampire Smile. They'll almost never make a Super Mario Bros. though, or a Wolfenstein 3D.
I'm not really sure why an indie game designer should aspire to be recognised and offered the "opportunity" to work in a larger team, that smacks of a sense of gated legitimacy... Personally, moving to AAA seems like a huge loss of authorship, which is only something I'd accept if I weren't actually making things I cared about.
To each his own :) Some people have the dream and desire to work in a large team on large blockbuster projects akin to those that they enjoy playing most. And while that might not be your slice of cake, I don't think that anyone who has those aspirations should be discouraged from chasing that dream.
I said personally. I hardly think that means I'm suggesting everyone not do a specific thing, ever... *sigh*
@silvaring You appear to be making a couple fairly plain observations, but your semantics are foreign to me.
@silvaring Personally I dislike your usage of the term "high art". It appears to me that "high art" could just be substituted with "core-gamer-targeted-games and highly popular" in all the instances where you use the term. It seems to me that you are using the term very narrowly and with a lot of personal bias. See http://en.wikipedia.org/wiki/High_culture
@silvaring I guess it's a case of you just having different tastes to me. Ibb and Obb is far more exceptional/important/relevant to me than Tombraider (which I find disgustingly colonial in its world view and otherwise generally awful, though the reboot less so).
Silvaring is talking about "high art", and is suggesting that the team that made Ibb and Obb aspire to make games like Tombraider... specifically the old Tombraiders? The ones that were about Lara Croft's cleavage and her exploits stealing treasures from savages in foreign lands.
@dislekcia Your game will be classified by different people, and some might even call it high art, using reasons to justify that label. When it becomes high art its basically a way of saying this game is worth paying attention to. With a world of games at their fingertips, this high profile reviewer chose to show 'your' game above all of these others. its status is thus elevated to a 'high' position.
I used the term because game designers should be aware of how their games are seen and consumed before sending them out to die/live so to speak. IF I'd just used the word art it wouldn't connote the same message, that being 'all games are art, therefore all games are valuable'.
You made a good point about the nature of game developers, to be clear I wasn't implying that developers should be or are in it for the money, I'm just referring to the difficult situation an indie developer faces when putting out a game into the wild, and the difficulties I face as a player/reviewer in deciding whether it is worth my time or not.
This feels pretty weird as a discussion, TBH ;) I'm not really sure what you're trying to say here... Is game discovery a difficult problem? Yes, undoubtedly. That's why here in this community we strongly advocate for rapid prototyping and constant user testing. If you have something that's rough but players can't get enough of, only then should you consider investing more resources into making it bigger to see how more people respond. Eventually, that's how you build a hit.
I mean, I'm speaking directly from experience here... In fact, there are several projects by active community members that are busy going "high" art right now, all created as simple prototypes and first shown via this forum. I kinda have to assume you don't know this, which is why this feels weird to talk about ;)
@AngryMoose I wasn't implying that bigger teams meant AAA. My suggestion was that game developers should not expect to make a genre defining/emerging game alone. They can make gimmicky games, or high concept stuff like gravity, maybe even an ambitious story project like Dishwasher Vampire Smile. They'll almost never make a Super Mario Bros. though, or a Wolfenstein 3D.
This concept makes no sense to me. Single creators have more opportunity to take risks and frequently end up innovating much more than teams, especially as those teams get larger and have more fixed costs weighing down their appetite for risk. Single creators and tiny teams have less capacity to polish, so they practically have to use innovation to stand out in the first place... Canabalt, Minecraft, DotA, Tower Defense, Counter Strike - all started by single person dabblers.
Comments
The guy in the video made all the investment fallacy mistakes, all the scope mistakes and all the resource mistakes, but managed to avoid the engine mistake and finished the game eventually anyway. That just emphasises how bad an idea it is to make your own engine - most people who try that never finish anything, even if given 13 years.
I mean, I'm curious as to what these benefits are supposed to be and if they actually exist enough to be worth bolstering the incredibly harmful misconception that game engines as imagined by the idea of "building an engine" are even a thing that exist, but mostly I'm just wondering what it is people THINK I'm saying when I write that...
If you need to do something simple, why have all the added bloat of a fully-featured engine, for example. If total ownership of your code base is important to you, then that too is a good reason to use your own. Also "engine" is not always going to be something all-encompassing. And I am putting engine in quotes because what the hell is that even? Hence me saying that making an engine should not be your goal, even if you end up with one.
The warning/advice that it's bad idea to build your own engine comes from this thing that very often happens where devs spend ages making a game engine but never actually get around to making a game. Or they do silly things like code a physics engine from the ground up, when they could have just plonked in Bullet Physics. Yeah, don't do that.
For a great example of "own engine" combined with super-productivity, I suggest following the Limit Theory developer videos. It's the dev's first commercial game but he seems to be a master craftsman. His "IDE" is just vim and clang. Not sure if he uses SDL2 though or if he codes directly against OpenGL.
EDIT: Nope, no SDL - he's just churning out code by the bucketload over there.
http://blogs.unity3d.com/2014/06/23/unity5-api-changes-automatic-script-updating/
I found this blog post somewhat amusing: http://www.gamasutra.com/blogs/TanyaXShort/20131010/201752/50_Easy_Steps_to_Indie_Success.php
@dislekcia thanks for discouraging me that the knowledge of reading hundreds of books on game engines since 2007 is hogwash. And maybe now I'll give up all the demos Ive been doing all this years and go for a macdonalds job. thanks for yr courage.
Firstly, I don't believe anyone implied that game engines just appear out of the aether, and therefore making engines is bad. Compilers certainly don't magically appear, and yet it is a bad idea for people to make their own compiler. You might try argue this last point, but I would like to see any evidence to back up such a claim. Also note that I am not saying that because making a compiler is a bad idea this implies making a game engine is therefore also a bad idea, merely that the necessity of game engines doesn't imply that everyone that needs one should make their own, as seen with compilers.
Secondly, your remark about CS or Applied Math seems to imply that somehow, just because you are able to do something (to some degree), it means you should be practically doing it at some point, which is not true. A similar situation occurs in digital security: cryptography is a difficult subject, both from an implementation and integration perspective (hence the need for relevant education), but it is well accepted that writing your own cryptography system for production is a really terrible idea, even if you are well versed on the subject.
So while the above certainly doesn't try argue that making engines is bad (although it is alluded to), it argues against the points for making engines that it seems like you are trying to make.
And just to make my view clear: I think that writing your own game engine is actually pretty similar to writing your own compiler or cryptography system: it takes a long time, and chances are that you won't do a good job in comparison to the alternatives. That doesn't mean you aren't free to study them and try things out on your own, just don't say you're making games - you're "just" researching one aspect of game development, and it's arguably not a very good avenue of research if your plan is to make a game. Also note that this comment completely ignores the very grey area around what a game engine actually is (in terms of where to draw the line), but I'm pretty tired of this subject at this point, so yeah...
EDIT: I realise my last remark about making an engine being research is not always true, but the rest of the paragraph is still valid so I just crossed out the wrong part.
EDIT 2: Just for background, also note that I have written a: small compiler, core portions of a cryptography system, and a few small game engines, but those cases were strictly for research or fun (I'm weird), and not with a realistic end goal of programming, security or games respectively.
But maybe I just like making engines for the sake of making engine not games. Its a sort of entertainment for me, and that I own it, I can do anything with it.
Why would Mark Overmass(Game Maker Creator) or Mario Zechner(LibGdx Creator) write entire books on teaching Engine Programming if they believed you can only use theirs and not be able to compete with them. Maybe its just a Science fiction movie.
And On the premises about compilers, maybe learning about them might make you invent something new that human beings have never seen before or if you survive world war 3 or global warming, your knowledge will greatly be appreciated in reinventing computers. So possibilities are endless, think about mixing cryptography with Stem cells and Natural Language Processing.
Maybe I'm weird too, but for me, just like Trevor Noah said: "Crazy is Normal"
(I'd love to attribute this, but I don't know where it's from, and Googling it takes me to someone who quoted it but didn't attribute either. :()
Though I really appreciate people who farm goats, build cement factories and start coffee plantations :) but I know those aren't what I wanna do :)
As for "engines"... Well, I don't advise trying to compete with the massive teams and budgets behind tools like UDK, Unity and Game Maker. That's especially bad business sense when trying to compete without, y'know, knowing what you're competing against. I really don't understand what it is that makes people defend the concept of an "engine" so vehemently.
I also don't understand why books are so important... I've built compilers at university, written my own renderers, collision managers, scene graphs, resource managers, network layers and stream loaders. Most of that was just implementing algorithms I'd read. You know what I'd never read about anywhere? How to build the systems at the core of Desktop Dungeons, how to keep game actions deterministic across a network, how to procedurally generate space ships or how to make a maths game that taught and inspired learners. That stuff isn't in any book ever, just like all the game-specific logic that people who love writing toy-problem "engines" continuously ignore. So yeah, maybe your book learning isn't that wonderful, it was great when you started, but now you should probably move on to actually testing your skills against the juicy problems that nobody else has ever seen: The ones lurking in your own game ideas.
And if anyone feels disheartened by my advice on this topic, make more games, that'll fix that disappointment right away :)
So we are not trying to dishearten you, we are trying to prevent failure from disheartening you. And failure is less likely if you leave the engine work to the big boys with the big budgets :)
EDIT: to make sure you don't feel that we are targeting you, here is my own experience:
http://www.makegamessa.com/discussion/76/grave-days-game-prototype#Item_34
It might seem that Grave Days is written in Unity, but don't be deceived. I used the bare minimum of the actual engine, and wrote my own engine on top of a very thin layer of Unity. I'll even go as far as to say I was ignorant of the fact that I was doing it. In the end I spend a lot of time trying to optimize, and improve performance for a large number of game entities. Sure, this will still be needed if I used Unity to its full potential, but I definitely less so. I have spent probably not even 1% of the time remaking this game the way Unity intended, and I am already nearly 50% as far in the development as I was last time.
Sure, you could say that the second time around goes quicker because I have learnt a lot (and yes I have, I have learnt how to use Unity), but at least this time around I didn't have to write a script (4 nested loops and recursion!) to try and mesh together all those goddamn tiny (NOT TINY ENOUGH) semi-transparent squares that I called my lighting system! Anyway, I'm sure you get the point :)
I was saying maybe I like making engines for the sake of making engines "NOT FOR MAKING GAMES". I think im repeating this... Secondly, my type of games might not suit unity as you all think they might. Or maybe I might not like even like unity, or it might not suit my style of programming. Or maybe I just don't like the idea of not paying for stuff that I can make myself or maybe I just like the learning experience.
Count all the "maybes" I used and make your own conclusion.
Nothing is impossible!!!
Most people would opt to use existing tools like Unity and JME however I made a conscious decision not to very early on.
I don't think anyone said you shouldn't make engines either. The point they were trying to make was that you shouldn't make engines INSTEAD of games. It's something that most people are prone to do when they start making games, I know I was. So if you like making engines for the sake of making engines, that's awesome. I know there are things I do for the sake of doing them rather than the end result. But that won't bring you closer to making games, which this forum is all about.
I'm sure there are many other forums dedicated to game engine and related topics, but this is not one of them. That's not to say you shouldn't be here though. What I'm suggesting is that finding another forum to discuss these things will most likely result in a much more rewarding experience for you.
Just to reiterate, I'm not saying you should leave the forums or not participate. I'm simply saying we are here to make games, and will evaluate everything here based on that criteria. If you aren't doing that, then I'm afraid it will be a very frustrating experience.
There's nothing that says you can't write "engine-like" systems AFTER you've already gotten damn good at using other "engines". In fact, that's probably the best way to go about it - otherwise you're trying to make carpentry tools without having ever used a hammer.
@SkinnyBoy: Why are you so disparaging of advice that's designed to help people make games then? If you're not about making games, then obviously you're going to have a hard time gelling with a site that's all about that. Especially if that site has a long and storied history of watching hopeful newbies wasting years of their lives and losing that spark of interest because they believed (hugely incorrectly) that they had to write an "engine" first.
And we keep repeating this: "Our primary goal is to make games, and we'll try to do it as quickly and as efficiently as possible because we want to make more games."
Please understand our response framed under that heading. If you'd like to talk about making engines...
1. Most of us won't bother with it, whether we're capable of it or not (personally I'm not).
2. You'd probably find better people to talk engine with somewhere else.
For example, going to a BMW site to talk about Shatterprufe glass and how its made is probably not gonna get a lot of response - sure BMWs make use of Shatterprufe glass, but BMW enthusiasts aren't there to talk about how to make their windshields.
I don't think we should ostracise people who want to make engines though. Claiming that this is "MakeGamesSA" and that those who want to make game engines should go elsewhere feels really wrong to me. Sure, making a living out of that in South Africa is probably virtually impossible (unless you're working remotely for overseas companies?). But if that's what you enjoy, go for it! And I don't think you should be discouraged from posting your experiments around here, as long as you make it clear to everyone that you're making a renderer, or making a physics engine, or whatever, and that THAT is what your goal is.
We get a bunch of people posting art, but that's acceptable (as it should be!) and nobody tells us that we shouldn't be making art, that we should be making games instead. On the other hand, I don't think any of the artists go around telling game designers that they need to study art before they can make a game, so I do kind of think that the anti-engine sentiment around here is reactive against engine programmer(s) telling other people what to do.
I just wince when people who enjoy making game engines tell people who want to make games that they need to make an engine to get there, and when those who make games tell those who make engines to GTFO. There's space for us to help each other, build each other up, etc.
And while those who enjoy making their own engines probably should be trying out existing, commercial game engines to see how others are doing it (with larger teams, bigger budgets, more experienced people, etc.), just as game designers should be playing games as a portion of their daily learning, I don't think very effective game designers spend 100% of their time playing games. Some portion of time necessarily must be spent on making them to be a game designer, and, similarly, some portion of time should be spent by an engine guy on playing around with making an engine. Granted, if it's not being used for a real-world project, it's probably less useful as an actual game engine, and sure, most of these problems are solved. But I do think that there are building blocks. I play scales before I play pieces. I do sketches and studies before I do full illustrations. There's value to doing things for the sake of learning, even if they've been done before. We recommend people make Tetris or Pacman, because even though they're "solved" problems, there is so much you learn about what you didn't know that informs what you thought about Tetris and Pacman, and what things were much easier or (more likely) much more difficult than you thought they'd be, and you learn from that experience.
I think a certain engine-oriented programmer around here has been super abrasive, in part because he goes around telling people what to do with zero game credits, zero samples of work, zero samples of cool tech, and telling people what "real programming" is while writing off all of the "real programming" that I know from experience goes on in "real" game studios. But let's not use reaction against him to push away engine programming in general?
The key words here:
1. Constructive.
2. Productive.
And thus the art and sound guys say things to assist in making games (constructively, it doesn't help saying this suck and that sucks and you shouldn't do that without replacing that with better solutions), and help them *actually* make games. I think ultimately that's where the difference is - no matter what we talk about, we want to ultimately be productive, to make things. We probably can talk about engines here if they result in results - things getting made.
We have very very seldom see any engine talk go into results, that's seemingly the problem.
I don't mind talking engines if they result in games sooner than two years later :) Grids is a great example. They're intrinsically an engine. But they made 30 games in 30 days. THAT is making stuff happen.
I sincerely hope more people want to make engines and I want to encourage people to make engines. Without them I wouldn't be able to even begin to make games(digitally anyway). So I appreciate people that make them, but I can't really help them. Unless they start asking questions on what I would like my engine to do or something. :P
Also, if I were an engine programmer, this is exactly where I would hang out; what better place to find out what types of problems people are really likely to run into, what they hate and love about existing tools, and just generally what their struggles and joys are.
(I also believe strongly that making games is the best way to learn what should be in an engine. Working on a certain layer benefits your knowledge of the design of layers downwards, not upwards as many people believe. We have also experienced it in quite a dramatic fashion first-hand, not only with the 30 games, but also with support questions about the things people want to do. Every lack in foresight (aka design problem) is a direct result in not knowing what people actually want to build, and what type of architectures and problems arise in those situations; i.e. design problems are caused by us not having made enough games.)
Though I do see learning about low-level enginy-stuff as something of a trap for many game programmers beginning their career. It's much harder to fail at learning about low-level enginy-stuff, as apposed to learning about gameplay systems, so it's a comforting avenue of research, and so also a trap (because most low-level enginy-skills aren't particularly instrumental in enabling success at game development).
I don't mean to say that people definitely shouldn't study low-level enginy-things, just that they should be aware they are doing so at the cost of not spending that time studying far more useful game development things, and if succeeding at game development is their goal knowing this might help them prioritize their time better.
But as the thread is about "Some advice for new Game Designers/Developers" I don't think it's unreasonable in that context to say: "Don't learn how to make a game engine before you learn how to make a game. Just don't. Learn to make games first".
And yeah, I hate the idea of chasing people away. I do have to ask myself how many of the belligerent "engine advocates" from years past have stayed around and been productive though. How do we change that?
P.S. @hermantulleken exactly: I've built more and better "engines" since focusing on building games. It's incredibly annoying how that's always completely disregarded whenever I say it in this "debate".
P.P.S. I think the best way to stay positive is to be open about whatever reason things are being done for and accepting the experiences of others as valid when they talk about them (acknowledging the experiences of a newbie programmer and the joy they get from a toy problem is just as useful as relating the experience of an old pro) so that listening is more likely than dismissal.
And that's great for the purpose of learning how this and that and that thing works. Whether that's great for making games itself is another matter altogether - and that's generally the matter that we all speak about around here :)
Learn engines if you want to learn engines, make games if you want to make games :)
NOW! I would looove some advice. Relatively recently (I actually started at Ludum Dare) I got into UE4. All the shinies like the lighting and post-processing are nice, but my main motivation behind using it is for the Blueprint system (and their awesome pricing model). As an artist with no programming background, this system really excites me. While it is much simpler to pick up than straight-up programming, there is still a learning curve. I know most people would say that the best way to start learning is to create! But this is where I hit a snag.
How do you know something is worthwhile to do at this point in time? I understand that my first game will never be a finished, ship-able product, but I'm struggling with the balance of simplicity. If it's too simple, I might not learn enough. Too complicated and I might get frustrated with it and abandon it completely. How do you know if the idea you are pursuing is simple enough? How do you know it's not too simple? Is it ok to reach a point and realize you've learned everything you can from a game idea and move on, even if you didn't even nearly finish it?
I suppose what I'm asking for is advice beyond the usual "Just start making a game, but start simple" advice that most people have loaded in the barrel of their Advice-guns™. I'd love an Advice-gun™.
Sounds like what you need to do is calibrate your sense of "simplicity" of a game from both a design and implementation perspective. Right now, you have no way of knowing what doing something is going to cost you to work on, so you're looking at the advice people are giving and wondering how to evaluate it against the possibilities you have available.
The easiest way to calibrate your sense of this relative amount of work is to try to remove variables so that you're focusing on just 1 or 2 new areas of learning at a time. Basically, remake existing games to give you a sense of how difficult/simple they are to produce in whatever tool you're keen on learning. The perennial favorite is Tetris - not only is it a simple enough game to understand, it's also non-trivial enough to trip up nearly everyone that tries making it a couple of times at least ;)
Trying to make something established not only gives you a simple goal point at which you know you're "done" and can move on to something new - it also gives you a set of things to fail at, so you can know that you need to work on understanding X because you couldn't get it working and Tetris needs that before it's playable. When you're working on your own game ideas with little experience, you very rarely know what your final game is going to look like, or where it might fail, so you're searching in the dark.
Part of my own frustration as a developer right now is that my mental toolbox for Unity isn't as complete as I'd like it to be: When I look at a new game idea, a bunch of possible ways to make that work roll out in my head - Game Maker's paths are broad and well lit because I know it so well, XNA's paths are less shiny, writing my own systems is like a hike across mountains and I can see the peaks but I know there's lots of bogs and rivers and leeches, while Unity feels like looking at a city without a map and I can kinda see where I want to go but the alleyways and buildings inbetween are dark and foreboding. This happens for every game idea, because each implementation of an idea is just one possible way of making it from many in each possible environment/tool/platform. That sense of "knowing where you are" is what you're feeling you're missing.
That's a good thing to want to have, so that's an important feeling! Once you start messing with known games to see where their design space takes you "if you just do X or Y", then you'll know you're developing that sense.
http://indiegraph.wordpress.com/2012/02/22/scnd-genesis-legends-review/
Made that in college using stock Java2D and JPanels. It was a rudimentary "engine" as well, when I transitioned to 3D(2.5D) I wanted to take a similar approach. It also helped me in landing my current day job as a programmer. The whole "I want to learn" thing went down well with them.
I have a strong suspicion I may just start with Tetris! :D
The story is just to say that the engine "making" we did was not at all in vain but we slowly started losing focus on making a game which was our main focus and I think that's where the whole argument lies about engine making. It's not a waste but it does make you lose sight of the goal which you started out to achieve, if it was making games.
Good luck!
I can say that from the perspective of an indie game developer, I aspire to work on the best, most interesting, most rewarding things I can. I don't think it's fair to say that anyone who pursues a decidedly-risker-than-average-yet-lower-paying career is ever doing something to just get by, and I'd argue that anyone motivated by making a "quick million" in games isn't going to last more than 3 months when faced with the reality of what putting games in front of people actually entails.
I'm not really sure why an indie game designer should aspire to be recognised and offered the "opportunity" to work in a larger team, that smacks of a sense of gated legitimacy... Personally, moving to AAA seems like a huge loss of authorship, which is only something I'd accept if I weren't actually making things I cared about.
As for being able to say "yeah, I made a game" - that's easy: You've made a game as soon as you've given other people something to play that doesn't need you to explain it.
I used the term because game designers should be aware of how their games are seen and consumed before sending them out to die/live so to speak. IF I'd just used the word art it wouldn't connote the same message, that being 'all games are art, therefore all games are valuable'.
You made a good point about the nature of game developers, to be clear I wasn't implying that developers should be or are in it for the money, I'm just referring to the difficult situation an indie developer faces when putting out a game into the wild, and the difficulties I face as a player/reviewer in deciding whether it is worth my time or not.
@silvaring Personally I dislike your usage of the term "high art". It appears to me that "high art" could just be substituted with "core-gamer-targeted-games and highly popular" in all the instances where you use the term. It seems to me that you are using the term very narrowly and with a lot of personal bias. See http://en.wikipedia.org/wiki/High_culture
@silvaring I guess it's a case of you just having different tastes to me. Ibb and Obb is far more exceptional/important/relevant to me than Tombraider (which I find disgustingly colonial in its world view and otherwise generally awful, though the reboot less so).
Silvaring is talking about "high art", and is suggesting that the team that made Ibb and Obb aspire to make games like Tombraider... specifically the old Tombraiders? The ones that were about Lara Croft's cleavage and her exploits stealing treasures from savages in foreign lands.
Silvaring has got to be trolling?
I mean, I'm speaking directly from experience here... In fact, there are several projects by active community members that are busy going "high" art right now, all created as simple prototypes and first shown via this forum. I kinda have to assume you don't know this, which is why this feels weird to talk about ;) This concept makes no sense to me. Single creators have more opportunity to take risks and frequently end up innovating much more than teams, especially as those teams get larger and have more fixed costs weighing down their appetite for risk. Single creators and tiny teams have less capacity to polish, so they practically have to use innovation to stand out in the first place... Canabalt, Minecraft, DotA, Tower Defense, Counter Strike - all started by single person dabblers.