Building A Game Engine + Game

You are in no position to even contemplate creating a game engine. Use an existing one such as Unity.
Then start making simple games such as Tetris or Hangman or Pac Man.

You need to learn to walk before you learn to run. Your first project isn’t going to be the game of your dreams. I still haven’t made my dream games from 20 years ago (mostly because a lot of fun new ideas have come in the meantime)—I never expected to just start there. You have to work up to it.

You should not plan on starting a “real” project for at least a year, but 2 or 3 is better. Trying to make your first project be your dream game is the best way to absolutely ruin that dream and frustrate yourself during the learning process. That’s like me trying to build my dream house without ever having built a house before. Even if it looks close to what I want, I wouldn’t trust it to hold up against a strong wind.


L. Spiro

Believe it or not, my current game is meant to be practice and a fun idea before I start another dream game. I was just told by some people in chat that making an engine is easy (Game from ground up). I will stick to Unity and learn C# in this case. Thanks L.

You are in no position to even contemplate creating a game engine. Use an existing one such as Unity.
Then start making simple games such as Tetris or Hangman or Pac Man.

You need to learn to walk before you learn to run. Your first project isn’t going to be the game of your dreams. I still haven’t made my dream games from 20 years ago (mostly because a lot of fun new ideas have come in the meantime)—I never expected to just start there. You have to work up to it.

You should not plan on starting a “real” project for at least a year, but 2 or 3 is better. Trying to make your first project be your dream game is the best way to absolutely ruin that dream and frustrate yourself during the learning process. That’s like me trying to build my dream house without ever having built a house before. Even if it looks close to what I want, I wouldn’t trust it to hold up against a strong wind.


L. Spiro

While I don't necessarily agree with the first two sentences (which I will explain in a moment), but L. Spiro still has a point. You mentioned that this is just for practice/fun, so by all means start off small. Then if you want to tackle something larger, go for it.

I personally don't like the idea of beginners using a pre-written middleware engine in their first game, but others do. Back when I first started (and many of us), we couldn't rely on some middleware engine to make up for our minimal experience. Call me old fashioned, but only wimps have to rely on an engine (and tbh, I believe that many devs in this day and age with such easy access to middleware engines lack the talent/skill to do it themselves, nor are they interested in learning to do so). If you want to use C# and Unity, go ahead. It might actually be a better fit for what you want, however it's not black and white; meaning just because you're a newbie doesn't mean that you should use a middleware engine and nothing else.

I recommend trying both for yourself, then making your decision based on your experience, not everyone else's.

Shogun.

I think for a practice/learning game, it's definitely doable on your own without using Unity or another engine. Nothing in your description of your game is terribly complicated in and of itself, relatively speaking, other than the AI, which you'd have to code yourself, even if using an engine.

Realize that it's going to take longer to develop. But, if your goal is to learn, and not to simply finish a game, I think doing it without an engine is a fine choice and you'll certainly learn a lot in the process. On the other hand, if you're using an engine, you'll have more time to dedicate to gameplay mechanics, artwork, etc.

Both are valid routes I think. But, you'll get different things out of the process either way.

That said, and given your starting-from-scratch-ness, You'll want to do a few things first and you certainly have a few obstacles in your path. You'll need to choose a language. If you forgo an engine, you'll likely want to choose a library such as SFML, SDL, pygame, etc, depending on the language you choose. And, you'll need to become slightly proficient in your programming skills (even if using an engine). It will take time, to be sure, but it's certainly within your reach. And, it will be quicker using an engine.

This forum has tons and tons of resources though, and just searching through them, you'll likely be able to answer most of your questions, and if not, people are generally happy to answer a new one. The beginner FAQ will get you started on most of the things you need to do (language, libraries, engines, etc).

And, welcome :)

I think your first problem is focussing on the engine.

Just forget about the entire concept of an "engine".

Just make a game first. Most game engines started out as a game and then they extended the code to make it configurable as a library.

Forget about advanced and somewhat abstract concepts and just start writing what code you think needs to exist to accomplish the task at hand (heavy emphasis on task-at-hand).

You will fail alot. You will make alot of mistakes. You will learn from these mistakes and you will become an expert level coder over time.

Just make a basic game. Any game.

Once that works, try making it multiplayer.

Just keep adding layers of detail until you think your creation is good enough to share with other people, then share it (on gamedev.net dev journals of course).

This is the path you must take young jedi.

You use different kinds of OrBs to take over the bases of other colors and those of the
neutral color. OrBs can also be used to defend your own base. To create OrBs, you need
a mineral called Thium. Thium can be accessed by taking over Quarries. Each base spawns
with one quarry. To upgrade your orbs, you must attack enemies and gain xp. The neutral
bases do not attack, they merely defend. The other colored bases, however, attack neutral
bases and your bases. Your objective is to get all the bases on the map to become your
color.

This actually sounds like a nice starter project. Its a very simple RTS game.

Just make it 2D, learn SDL with c++. Your orbs will be bitmap squares that you move around by 2d xy coordinates.

AI can be handled by just "brute-forcing" it. Simply attack the closest target by using the distance formula.

I made something like this on my TI-83 in high school (that was like 14ish years ago). TI-83's can network with just one calculator so you could play your friends.

It was a badly made ripoff of total annihilation where everything was drawn as line segments.

The most popular TI-83 game i made in high school was a text-based RPG called "gansta-life". It was totally all rng (random number generator).

The teachers used to have to manually erase the calculators every day. When they found out who made the games they threatened to suspend me until the physics teacher (who was also a programmer) stepped in and saved me. I wasn't so lucky when I hacked the server because I didn't feel like taking a test. "We can see by the Novel logs that the person who deleted test.exe was sitting at this computer!"

I have a few more questions:

What compiler should I use to make a game engine?

What do you need to make a game engine?

Is it possible to make a game without an engine, and if possible, how?

Before you even contemplate writing a game or an engine, you need to learn to program.

There are plenty of languages that are good for beginners; personally I'd recommend python or C#.

Call me old fashioned, but only wimps have to rely on an engine (and tbh, I believe that many devs in this day and age with such easy access to middleware engines lack the talent/skill to do it themselves, nor are they interested in learning to do so)

Yes, everyone should reinvent the wheel....

Honestly, when was the last time you saw someone telling a chef they should build their own kitchen?

Well I'm gonna go make a Tetris game or some shit.

AFTER TRYING:

I couldn't do it

and I was using Javascript

I think the programming had an error

I suck at this

Time to practice spawning different colored cubes.

I have a few more questions:

What compiler should I use to make a game engine?

What do you need to make a game engine?

Is it possible to make a game without an engine, and if possible, how?

If by compiler you mean IDE, it's pretty subjective, and the pros and cons of each depends on a lot of things such as your language, OS, needs, etc. I use CodeBlocks, many swear by Visual Studio, others compile themselves, there are a lot of options. The actual compiler is a different thing, but I'm going to guess you're not asking about that.

Like others have mentioned, don't worry too much about a "game engine" at this point. People mean a lot of things when they use that term. But, at this point, especially if you're eschewing a premade engine, worry about making a game (well, worry about learning to program, but you can learn to program by making games), and the "engine" will follow (the "engine" really being the underlying framework of things you need to make your game run).

Depending on what you mean by "engine," It's totally possible to make games without a premade engine like GameMaker or Unity. Like others have mentioned, premade engines are a great tool for making games and can streamline the process considerably. Though, depending on what you're looking to learn and get out of the process of making your game, it may/may not be your best option.

To make a terrible analogy, think of furniture. You can go the IKEA route, and you'll still have to put it together yourself (this is like a premade engine), but IKEA has assembled the necessary parts for you and generally made things easier. Or, you can start from scratch,chop down some trees, sand everything yourself, and make your furniture from the ground up. There isn't a right/wrong solution to this. It depends on what you want out of the experience.

Its very draining to build an engine and a game at the same time. I did it and it exhausted my desire to code.

Call me old fashioned, but only wimps have to rely on an engine (and tbh, I believe that many devs in this day and age with such easy access to middleware engines lack the talent/skill to do it themselves, nor are they interested in learning to do so)

Yes, everyone should reinvent the wheel....

Honestly, when was the last time you saw someone telling a chef they should build their own kitchen?

Yeah, try telling that to the founder of Epic ("herp de derp, don't write your own engine, use the quake engine" even though his specific goal was to make games better than id Software could), or let's tell that to Bungie when they started writing Halo back in '97. Better yet, tell that to everyone else 10 years ago back when engines like the HL engine were well out of affordability for the average joe. Yeah, we were stupid for writing our own engine and taking time to learn good engine design practice, weren't we? Derp de derp!

Seriously, do you twits even THINK before you post this nonsense? Writing your own engine is NOT reinventing the wheel... that is, if you do it right. What I mean is that you don't have to write everything from scratch. Example, there are various SDKs, libraries, tools, etc. that you can easily integreate into your own engine so you don't have to spend time on the most tedious things such as physics, scripting, math, etc. My engine uses nothing but open source libraries that can be used in commercial projects, and it's fairly complex, even after a couple of months of refining it (still could use some more improvement, but it evolves with every new game I plan/write). Just wish I had more time for it. Heck, depending on the compiler, the minimum binary size ranges from 2.5 to 14mb; that's alot of content, and much of which can be excluded if necessary.

It's not rocket science, and I assumed it was common sense, but I guess my sister is right: common sense isn't so common. Sorry for ranting, but I'm sick and tired of this piss poor argument/example of why you SHOULD use a middleware engine. If you want to, great, if not, come at me with something of more substance than that hunk of BS because I've stomped it every god dang time!

Shogun.

EDIT: I was in a rush when writing this (job interview), and I could have written this a bit better and less angrily. I sent ChaosEngine a personal apology.

Now, I've talked to the OP in the gamedev chat once before. One reason he asked this question was because he said he can't afford licensing fees. So I initially suggested writing an engine (a basic one) as a learning experience. If he wants to start off with a middle ware engine, do it but don't expect to be able to sell it legally.

Reasons to write an engine:
- No licensing fees.
- 100% customizable; optimize wherever and whenever.
- As portable as you want/need it to be.
- if it's good, YOU can license it any way you want to!
- Freedom of open source or not, your choice.

Reasons to use a middleware engine:
- You need to slap something together quickly.
- You can afford the licensing fee, and your team is familiar with the engine.
- You lack a team and don't have the luxury or experience to put together a complex engine.
- A middleware engine will likely go through more testing/dev time then your ever will.
- You want see how other engines work before writing your own.

Now, I chose to write my own engine because of the reasons above. With all the frameworks and tools available, writing your own isn't re-inventing the wheel. As for the chef comparison, ifnyournkitchen does not suit you, then build your own, or seek help in doing so. The engine should work for you, not vice versa IMO. My engine suits my needs quite well so far for the time I've put into it.

Lastly, I still stand by my original statement. Using a middleware engine isn't bad especially considering how complex games have come to be today (and frankly can be a better idea considering the options or lack thereof), but this is the first generation of indies who are generally too lazy or unskilled to even write their own engine and couldn't do so if their lives depended on it. 10 years, hell, even 5 years ago, we didn't have such a pitiful excuse to rely on so much.

Call me old fashioned, but only wimps have to rely on an engine[/quote] You're old-fashioned. Seriously though, no need to resort to name calling. No one insulted you, they were just disagreeing. You don't serve your arguments very well by being so judgmental of people who do it differently than you would. As for Tim Sweeney, if he came to me back in day saying he had no experience programming and he wanted to make a game engine I'd have said "what's a game engine?" because they didn't really exist back then. Tim Sweeney got where he is by being into programming a young age and working on it for years and making more and more complex games as he went on. Back then just making a text based game was impressive because that's all anyone was making. It's easy to be enthusiastic when you have little competition and expectations were low from consumers. Not to mention he had been into computers and programming for around 20 years before Unreal was released. All that being said I think the 'build a kitchen' analogy was weak. A better analogy might be growing your own ingredients to be a chef. Believe it or not there are chefs who do this! But I wouldn't call a chef who doesn't do that a 'wimp'. I think it's macho posturing to insist there's one true way to make games and those who don't do it that way aren't good enough. If the OP wants to make engines I say go for it and if they just want to use Unity go for that too and if they start one way and switch later because they realize they'd prefer the other way, I say go for that too.

Writing a little-e engine isn't hard -- writing a big-E Engine is. If your needs are simple, small, well-defined, writing your own engine is viable -- if you have a commercial interest or need major features that are missing from commercial middle-ware, writing your own Engine is viable. Otherwise, middle-ware engines are attractive -- sometimes they're expensive, but how much time and effort will you expend before you reach break-even?

If your needs are complex, large, evolving, then your little-e engine is going to have a very hard time keeping up. Your little-e engine is not Unreal, or Source, or Unity for that matter. They're generally well-proven, adaptable, scalable, and battle-tested -- things a little-e engine usually isn't.

That said, OP really does need to learn to crawl -- its hard to say where to start because we don't know what their experience level is. Often times, jumping into an Engine, even a simple one like Unity, for someone who's plain inexperienced isn't going to be as educational as starting with a basic gaming library like SDL2 or SFML -- in fact, the shear breadth of something like Unity can be frustrating and overwhelming for a green programmer just trying to make a simple idea happen because they have no idea how to start. But for someone who knows generally what they're doing with their programming language and who has fairly grand ambitions, an Engine like Unity or Source, or Unreal is probably the fastest path to success, and especially if they have commercial ambitions time-to-market is a strong argument on its own.

Call me old fashioned, but only wimps have to rely on an engine

You're old-fashioned. Seriously though, no need to resort to name calling. No one insulted you, they were just disagreeing. You don't serve your arguments very well by being so judgmental of people who do it differently than you would. As for Tim Sweeney, if he came to me back in day saying he had no experience programming and he wanted to make a game engine I'd have said "what's a game engine?" because they didn't really exist back then. Tim Sweeney got where he is by being into programming a young age and working on it for years and making more and more complex games as he went on. Back then just making a text based game was impressive because that's all anyone was making. It's easy to be enthusiastic when you have little competition and expectations were low from consumers. Not to mention he had been into computers and programming for around 20 years before Unreal was released. All that being said I think the 'build a kitchen' analogy was weak. A better analogy might be growing your own ingredients to be a chef. Believe it or not there are chefs who do this! But I wouldn't call a chef who doesn't do that a 'wimp'. I think it's macho posturing to insist there's one true way to make games and those who don't do it that way aren't good enough. If the OP wants to make engines I say go for it and if they just want to use Unity go for that too and if they start one way and switch later because they realize they'd prefer the other way, I say go for that too.

Yeah, sorry about that. I'm used to getting attacked over this, so I get defensive rather quickly. When someone responds that way, I see it as a mockery, and it makes me angry. Either way, I shouldn't have used the word twit. One of these days, I should bring up that guy that insulted me up and down for writing my own engine (while failing to back up his own claims for not doing so).

Good perspective about Tim Sweeny. Although I don't believe this really helped me much in my endeavours, I had a mental affinity for programming since I was 4 (Commodore 64 days), but didn't touch C++ until January 2003. Since I couldn't just download unity, Unreal or Source, I (and the vast majority of us) learned C/C++, the required APIs, then either read up online about writing engines, or bought books on the subject. It wasn't THAT much work, but it wasn't instantaneous either (the point you are making).

I also agree that the chef argument about building a kitchen isn't the best comparison. Now that I think about it in person, it's like saying you should build your own computer components from scratch. The vast majority of us don't have the money for that, even if we wanted to because that's beyond the skill of one person in general.

Lastly, I never said anyone using a middleware engine was a wimp, but those who solely rely on it and couldn't write their own (even a basic one), let alone understand the concept/benefits of writing one, are wimps.

Writing a little-e engine isn't hard -- writing a big-E Engine is. If your needs are simple, small, well-defined, writing your own engine is viable -- if you have a commercial interest or need major features that are missing from commercial middle-ware, writing your own Engine is viable. Otherwise, middle-ware engines are attractive -- sometimes they're expensive, but how much time and effort will you expend before you reach break-even?

If your needs are complex, large, evolving, then your little-e engine is going to have a very hard time keeping up. Your little-e engine is not Unreal, or Source, or Unity for that matter. They're generally well-proven, adaptable, scalable, and battle-tested -- things a little-e engine usually isn't.

That said, OP really does need to learn to crawl -- its hard to say where to start because we don't know what their experience level is. Often times, jumping into an Engine, even a simple one like Unity, for someone who's plain inexperienced isn't going to be as educational as starting with a basic gaming library like SDL2 or SFML -- in fact, the shear breadth of something like Unity can be frustrating and overwhelming for a green programmer just trying to make a simple idea happen because they have no idea how to start. But for someone who knows generally what they're doing with their programming language and who has fairly grand ambitions, an Engine like Unity or Source, or Unreal is probably the fastest path to success, and especially if they have commercial ambitions time-to-market is a strong argument on its own.

IMO, it depends on what you are actually writing (engine wise). The majority of my custom engine I built wasn't even written by me, and it's a rather long and comprehensive list of libraries/tools. Putting it all together didn't take very long for me, and it's steadily growing. Last I checked, it was like 400,000 lines of code altogether. Putting it together was the most challenging part because one poor design choice can lead to an evolution of cancer all over.

And as you stated, a commercial middleware engine has gone though greater testing then the average custom engine written after it ever has; which IMO is the best reason to consider a middleware engine.

Shogun.

Shogun, my response to you was probably overly flippant.

IMO, context is important here. Of course, I'm not saying that no-one should ever write a custom engine.

But I'm guessing that Tim Sweeney didn't post on gamedev.net asking for help learning to program just before writing Unreal. He had a big team and years of experience behind him.

If you know what you're doing, and you have specific requirements that are not met by an existing engine, then write a custom engine for all the reasons you outlined.

But you don't have to write an engine and using a 3rd party engine is a perfectly valid choice, unless you think that the Batman Arkham games were made by wimps? Also, Borderlands, XCOM, Dishonoured and the Mass Effect series. And that's just UE 3.

Finally, while some chefs might build their own kitchen, no-one ever calls them a wimp for not doing so or even not being able to. And no-one in their right mind would suggest that you need to build a kitchen before you learn to cook.

Building a kitchen and cooking a meal are different skills.

So is building an engine and creating a game. You might not be a shit hot engine programmer... no-one cares. Hell, let's be brutally honest. No-one apart from other programmers gives a rats arse about your code. It could be horrific, but if your game works and is fun, that's all that matters.

As for Tim Sweeney, I think he summed up his background leading to the first Unreal quite well in this keynote. The first 20 minutes or so are more important as it really shows that even he had to start somewhere.

Based off the first sentence of making a game from scratch - having an engine is entirely up to you. An engine is not a requirement to make a game at all, though in certain aspects it helps get you started. Making pong in UE4 or Unity is, in my opinion, pretty overkill and completely unnecessary.

Many of my first games had no engine at all. I had a tiny wrapper over DirectX 9 which really just contained a pointer to my device and took a texture to draw a sprite. Since I was using circles as my characters writing a basic collision detection system was easy. I could have used libraries but my goal was to learn how the innards worked, while also making a game I thought was fun.

Now did I make mistakes? Yes, I made so many mistakes it was astonishing the game would even run. For example after the enemies on the screen died I made more spawn. This really meant - reloading the textures for my enemies and allocating memory each time. The noticeable lag this caused was eventually fixed and I learned from it. Granted external libraries might have solved this for me..maybe.. I wanted to learn how to make those libraries compared to just how to use them.

If your goal is to just make a game without all that extra effort just use middleware. It is indeed much faster to develop with :)

I think if you have to ask which compiler to use then you need to learn programming first.

The answer is which ever compiler you know how to use best.

If you use an engine, it will be which ever compiler supports the language the engine is written in.

Most people don't consider gaming to be a serious affair, but game programming is very serious.

Its right up there in complexity with the coding that they use to forecast the weather or to make robotic cars.

Those guys have one disadvantage, they must adhere to reality where in games we just approximate everything.

Game coders are tier one programmers (with tier three pay).

Well I'm gonna go make a Tetris game or some shit.

AFTER TRYING:

I couldn't do it

and I was using Javascript

I think the programming had an error

I suck at this

Time to practice spawning different colored cubes.

Javascript is not an easy language for developing games (mainly because you are stuck trying to work around html5 dom elements and that whacky javascript functions-are-classes stuff). In fact making games from javascript was nearly impossible until the last 5 years.

You should try something easier like maybe java using the swing gui library (just download netbeans ide).

Swing allows you to draw stuff to the screen relatively easily.

When you are ready for the big boys (or girls) then learn C++ and SDL and then move on to OpenGL.