Game Design Megathread

[Kingdaro]

So I came upon these walls of text I made back then on page 90 of this thread:

With all of this engine talk going on, I'd like to interject with a very important bit of advice. Make games. Don't make engines.

Now obviously I don't mean to just throw down the amount of work you guys have done here, but let's be honest, with the multitude of awesome frameworks and engines available, there's simply no reason to add another log in the fire when you already have plenty of options.

You could think, yeah, I'm making this engine for my future games, but that's actually quite difficult to do well without editing the engine to fit your game every time. Unless you're actually creating a game, you won't know how your future games will be structured, and the best structure (e.g. inheritance as opposed to using a component system) can change from game to game.

Another point is that engines don't impress anyone, except for maybe other gamedevs. Yeah, you could have a couple of squares bounce on the screen or some characters walk across the screen, but when you're trying to show off something that can't quite be seen, nor is a tangible, playable game, there's no point.

On the flipside, the way engines do come to light, is that they came from a game. A common misconception is that one would make the engine, then the game, when in reality, most engines come from having a game already made, just without the extra stuff. This is how people generally create their own toolkits, which is basically a level higher up from the engine: the code you always write when you start creating the game and simply don't feel like typing over and over.

In any case, this blog post can explain it better than I can: http://scientificninja.com/blog/write-games-not-engines

But again, don't make engines, make games.

Thanks for the thoughts, but for the record, I use the word 'engine' very loosely to encompass frameworks like love2d and craftyjs, and APIs such as SDL, GLEW, and so on.

With that in mind, I'll make an educated disagreement, because think about it: if you do decide to create an engine for yourself using something relatively low level like the aforementioned (or even lower if you're a masochist), unless you've written down every idea you have beforehand and know exactly how everything is going to work without making any significant changes down the line, how do you know that this engine is going to satisfy your needs? It sounds easy on paper, but it's incredibly difficult to predict your future habits and organization style. You could simply change parts in your engine to fit the current game. Yes, this works, but then you're not focusing on creating the game. This is where the problem lies.

I feel as though I failed to stress this, because this is a very important thing to realize: a small toolkit or a couple of scripts one would use to avoid rewriting code is far different from a full-blown engine. I'm talking about just spending days, weeks, maybe months on your own rendering system, realistic physics, networking, a level editor, and so on, vomiting in a bunch of garbage your future games may not even need, while possibly even missing some important bits your game will need.

I'll also say that, again, the general population of game development won't nearly respect you as much for making your own engine, than if you spent the time working on that engine making games. Imagine if every post in this thread about an engine was instead a gif or screenshot about a different game? Wouldn't that make you much more exited for the creativity and progress coming out of the thread?

And I won't deny it: a game engine can be a fun little thing to work on as a hobby, and very much as a learning experience.  But I personally believe that, what you learn from making a game engine, you'll learn eventually as you make more games, and that the knowledge you obtain isn't any more useful than just trivia. The most you'll usually need to know in technical terms is how to make a game loop, and a good bit of knowledge on design patterns in game development. There's also stuff like memory management and efficiency, but if you aren't brain dead and/or loving handicapped (e.g. loading an image on every update, having 500,000 dynamic objects on-screen) low-level issues like this shouldn't be a problem, as most engines(/APIs/frameworks) handle this for you, or at least allow you to easily handle it on your own.

Continuing from my last point, in game design, the last thing you should be worrying about is the underlying technology behind your game. Depending on your needs, a good goal to aim for is 60 frames per second and cross-platform compatibility. At this point, it's fast and efficient enough, and the gameplay experience won't have changed for the end user who just wants a fun game, regardless of what you've used. You also need to think about the actual mechanics of the game, how to make it fair and balanced, difficult but not colossally impossible, visually appealing, depending on your graphical style, and juice. Creating an engine almost always distracts from this.

On the subject of employment, I feel like this topic is somewhat irrelevant, but it's apparently not as obvious as it seems that game companies will value games more than game engines, because they can tell you understand how to create engaging interactive experiences, but a basic understanding of a game loop won't impress anyone. Games like Dust: An Elysian Tail, Freedom Planet, and Distance (racing game from refract) are what get people hired. The engines and tech behind these has to be massive (even in Distance's use case, Unity) but just showing off the tech itself instead of what you can really do with it, you won't get very far. On the flip side, if you're being hired because of your work on engines and/or game architecture, you simply aren't a game developer, and your end goal isn't to create games. There are some special cases, but I won't go into detail.

I'll end this post off on this, and by now, I hope I will have made myself clear. Keep in mind that this is in the perspective of game development, and nothing more. The goal here is to create games. The engines(/APIs/frameworks) available allow you to do this and have given every tool you need to express your creativity in any language or environment you please. When the goal here is to create games, making an engine is, in my opinion, simply a complete waste of time. If there's some sort of quirk in the current engine(/API/framework), or some licensing issue, or just something under the hood that simply does not allow to use it, move to another, there are plenty available. Plus, the more tools you learn to use, the more tools you'll know how to learn and pick up quickly. Search and explore, because there are hella options out there.

With this in mind, I really, really recommend you watch this video, because it's incredibly insightful, informative, and eye-opening in some ways, and I gained a lot of my personal principles from this video and other similar resources.

Surprisingly, one of the few things I've said more than a year ago that I actually still happen to agree with. Somewhat insightful looking back on it.

[Ad Bot]

[McJob]

I'd like to point out that my friend wasn't hired by Tt Games because he could build engines; they didn't give a stuff. What they cared most about, and what he was most passionate about was a very specific part of the engine; the renderer. If you love working on engine-level code and want to do that as a job, work on a specific part and get hired to do that. If you want to make games, you're wasting your time making engines when there's a million open-source alternatives already out there that you can easily tweak if need be, yet are light-years ahead of where you're at.

Me personally? I'm a tools/systems kind of guy. I really love the nitpicky design of things that make life easier for the end developers. Not huge engine stuff, just little methods/functions or scripts that a dev can pull that abstracts away a lot of the annoying complexities. I love making localisation systems, timer functionality, debugging/error libraries and stuff like that.

I'm probably going to end up working outside of game design and in more generalised programming, but I just want to make the point that there's so much to do on video games, if you plan on being part of a team it's important to pick your battles and figure out the very specific thing you love doing most, and get really loving good at it. If you want to work as an indie, then you don't have time to forget around; you need every shortcut you can afford, and that includes using premade engines and code libraries.

[Bushido]

WE

DO

IT

[Gytyyhgfffff]

sieg heil

i just realized that isn't a hand but it sure did look like one

[Flamecannon]

[Frequency]

he do it

[Blue Screen]

The default Paint thing in here kinda sucks, but at least it kinda got the job done. It's not pixel-y yet (i need to find something to make pixel art lol)
The weapon is for a game I'm going to make (you know the same one where i laid out the difficulty level plans earlier in here somewhere)
This gun is really meant to be "simple" and not at all complex because the army that uses these are literally a buncha idiots. maybe.

It comes with an energy core to shoot lasers (yet uses a clip for some reason). The energy core also allows for a laser bayonet on the front of the grip to extend and then you can shank people with that laser bayonet. (I got the weapon idea from Major Mayhem, a game on the App Store, but I modified the weapon to look vastly different. plus it doesn't come with a laser bayonet in there lol)
(potential cringe warning)

(yes, the base is meant to be white.)
you can put your opinion if you want, i still need to draw the rest of the weapon set lol
it really looks better on paper imo
If anyone can tell me where to get something to draw pixel art or something (preferably free), that'd be great.

[Gytyyhgfffff]

ok that looks decently good
also for a pixel art program, try paint.net. it isn't designed for pixel art, but my friend uses it and can make some pretty fantastic things using it
also paint.net is really good for image editing in general, even if you don't end up using it for pixel art get it anyways it's way better than paint

[Blue Screen]

ok that looks decently good
also for a pixel art program, try paint.net. it isn't designed for pixel art, but my friend uses it and can make some pretty fantastic things using it
also paint.net is really good for image editing in general, even if you don't end up using it for pixel art get it anyways it's way better than paint

gotcha, thanks.

[Bushido]

is this what you were thinking

anyway just use paint

[otto-san]

paint doesn't support alpha so it's not great for actual game assets but it's pretty alright for designing stuff or doin simple lil drawings

[randomtroll39]

I have done the most basic of stuff in the field of game design.

I made a game and you're a floating donald Annoying Orange head pushing back mexicans from the border.
On scratch btw.

[Plastiware]

paint doesn't support alpha so it's not great for actual game assets but it's pretty alright for designing stuff or doin simple lil drawings

I use paint for actual game assets, but then again Game Maker 7 transparency is derived from the color of the lower-left pixel of the image (for some reason) so alpha isn't necessary.

As for why I still use Game Maker 7, it supports BASSMOD and I'm not switching to GM Studio only to have to overhaul my music playback systems.  I love modular music formats too much to let GM7 go.

[ZSNO]

paint doesn't support alpha so it's not great for actual game assets but it's pretty alright for designing stuff or doin simple lil drawings

It actually does KIND OF support alpha, it's just hard to get it to work correctly. Forgot the steps to do it, but it worked in my one class...

[beachbum111111]

This guy has seen some stuff