Jump to content
  • Advertisement
Sign in to follow this  
turquoiseptato

I want to make a 2D game engine! Where do I start?

This topic is 1867 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Guys I feel ready to make a 2D game engine, I have the knowledge of many language and library and whatever. But let's say I know nothing! What would you recommend me to learn to make a 2D game engine? What programming language? what library? which programming technique or algorithme should I learn?

Share this post


Link to post
Share on other sites
Advertisement
Guest Hiwas


Guys I feel ready to make a 2D game engine, I have the knowledge of many language and library and whatever. But let's say I know nothing! What would you recommend me to learn to make a 2D game engine? What programming language? what library? which programming technique or algorithme should I learn?

If you want a starting point for C++11 work, you could take a look at the repository I'm setting up for my next set of articles.  Tutorial  The directory "WithSupportLibs" sets up a C++11 cross platform environment which supports SFML and Horde3D (you don't have to use the 3D portion, I just put it in as an option as it is small and works well enough even though dev work seems to have stalled on Horde3D).  I'm sure there are other starting points but figured what the hell, this may be interesting to you since the build environment has been well documented through the series of articles I wrote. :)

Share this post


Link to post
Share on other sites

Well, you have quite a few options available to you. 

 

On the C# side you have XNA/MonoGame which is a pretty great framework that's very easy to get cooking with. You also have Playstation Mobile for Vita/PS Certified Android if you want to go that route.

 

There's also a ton of C++ options. I found SFML and Allegro 5 to be pretty easy to use, and if you can get the project setup right Cocos2d-X is pretty great as well, although a lot of the tooling is available only on Macs. You could also rough it and go straight to OpenGL/Direct X, but that's probably not the best plan for a 2D project. Of course, SDL is an option, I just personally prefer the more object oriented solutions.

 

Over in Java land, you also have quite a few options. LibGDX is the only one I'm at all familiar with, but it seems to be pretty feature rich and was rather easy to get going. It's also compatible with Android which I find to be a nice positive.

 

The number of available programming languages and SDK's is pretty much too great to count so it all comes down to what you want to do and what platform you want to do it on. Already know a language? Find an SDK/API that looks interesting and use it. Want to learn a new one? Go for it!

Share this post


Link to post
Share on other sites

If your goal is making a 2D game engine, but no game, then cool. But if your goal is making a 2D game, then make the game, not an engine. Engines aren't really used for 2D games much, and focusing on the engine and over-engineering it leaves you without a finished playable project at the end.

 

Regardless, it doesn't matter what language you use, or what libraries. Use the language you already know best, and the libraries you are already familiar with, and work with those. Unless your goal is learning a new language or a new library, and not completing a game. wink.png

 

Is your goal: (pick one)

A) Making a game

B) Making a game engine without a game

C) Learning a new programming language

D) None of the above

 

If A, let us know what language you already are most familiar with, and someone can recommend a good 2D graphics library for that language.

If B, let us know what language you already are most familiar with, and someone can recommend a good 2D graphics library for that language and some architectural articles or books.

If C, learn Pythonsmile.png

If D, could you elaborate on your actual 1 (one) primary goal for this project?

 

Note: There's nothing wrong with wanting to make a game engine as a goal - it's really fun to do - just realize it comes at the expense of actually making a game.

Many beginners think they need an engine to make a game, but that's not true, and they end up tripping over their 'engine' and failing to produce a game. This is the only point I'm trying to get across. The idea of an engine is appealing, but misleading, to game developers.

 

Engines come out of games before games come out of engines. Engines are the reusable components of pre-existing games wrapped up in a consistent and easier to use interface for future games - but focusing on the engine without a solid game in mind leads to an engine that isn't usable for any real game with heavy alterations - unless a developer has already made a half-dozen real games, in which case the real-world requirements of engines are already in his mind.

Making an engine instead of a game is putting the cart before the horse - from finished games come the knowledge and re-usable pieces to make engines.

Okay I'll tell you what I know. So I know: javascript, C++, python, C and ruby. And I'm more familiar with javascript, C++ and python. My main goal is to make a game engine, which is b. cause I mainly wanna learn how a program can make another program especially how a game engine can make a game. I only know 2 library pygame and SFML for c++.

Edited by turquoiseptato

Share this post


Link to post
Share on other sites

A game engine doesn't exactly 'make' a game, a game is built ontop of an engine (if it already exists) or a game is built directly, and the engine is refined from the generic and re-usable pieces of the game.

 

By 'game engine' do you mean something like Game Maker (which is a game engine and a game editor)? Or are you really just interested in the software part of the engine?

 

The term 'game engine' isn't super well defined. Some people mean one thing, others mean a similar but different thing. At what point a game engine ceases to become a library (or collection of libraries) and starts becoming an 'engine' is unclear. I like to think of it as the point where the libraries start to include higher level logic. ([1] [2] <- more of my thoughts on the topic)

 

I would suggest sticking with C++ and SFML, or else Python and PyGame, since either of those combinations are ones you know.

 

Then, to make your engine, I would have some clear genre in mind (to make it loads easier on yourself), and work towards making a engine for that specific genre (say, a tile-based RPG or a turn-based strategy). I would create tools (a map editor, mainly) for working with that genre, and write the code to support logic suited for that type of game.

 

Because different game genres require different logic, if you make your engine's logic too general to fit every genre, you might accidentally end up with a library or framework instead of an engine. Or, you could figure out some way of making the logic of the engine re-arrangeable to suit different genres - but even then I'd suggest having at least one clear-cut genre to work towards at first before creating a pluggable logic system to expand to other genres.

Edited by Servant of the Lord

Share this post


Link to post
Share on other sites

Servants post very cleary states the opinion of most people here: make a game not an engine.

Although I agree with most of its points, I personally think it is a good idea to start with the engine.

 

The question to ask yourself is; what is an engine?

I like Servants definition; reusable components fromt the game.

Although everyone has its own programming style, I personally don't think you should start with the game logic of the game without getting any visual output.

I like to start setting up the core components in order to draw a screen, implement all input/visual/audio APIs in an easy to use manner, setting up a basic gamestate system, entity manager incl. messaging etc. etc. I think this is actually a good programming behaviour, start by making a planning and design of what you actually need for your game. For instance in the first game you make you could decide to leave out the audio and you could just use if-statements for handling the gamestates.

 

Later one when you make another game, you can then re-use these core components of your game for the next game, while slowly introducing something new (if you feel that you actually need it or makes development easier), such as a scripting language. If you implemented something in the engine and you don't need it for the next game, you can just leave out these code files.

 

I got the same advice when I started: make a game not an engine. But after finishing a couple of games I felt like I realy couldn't re-use much of my code.

Mostly because I thought things weren't done efficiently or weren't easy to use. At that point I started doing things the way I described above, using carefull design and starting from the ground up and now I can just use this framework I made and start coding the game almost right away.

 

So to summarize my advice: spend some time making a good design, if you write a very good reusable piece of code it'll safe time in the end by avoiding having to recode everything again. But don't try to implement all kinds of features you're not going to use in the current game, you can easily implement those features as soon as you write the game you'll need it in.

Share this post


Link to post
Share on other sites
Guest Hiwas

Unfortunately I have to disagree with most of this.

 

The question to ask yourself is; what is an engine?

I like Servants definition; reusable components fromt the game.

Although everyone has its own programming style, I personally don't think you should start with the game logic of the game without getting any visual output.

I like to start setting up the core components in order to draw a screen, implement all input/visual/audio APIs in an easy to use manner, setting up a basic gamestate system, entity manager incl. messaging etc. etc. I think this is actually a good programming behaviour, start by making a planning and design of what you actually need for your game. For instance in the first game you make you could decide to leave out the audio and you could just use if-statements for handling the gamestates.

Without having created a game, new folks have no idea about anything you just said and would not know where to draw the lines.  Any simple game would let them understand how things interact a bit better, at which point they may understand the implied context here.

 

Later one when you make another game, you can then re-use these core components of your game for the next game, while slowly introducing something new (if you feel that you actually need it or makes development easier), such as a scripting language. If you implemented something in the engine and you don't need it for the next game, you can just leave out these code files.

Sorry, nothing a new programmer does is likely going to be reusable, they just don't understand the relations enough to write "generic" the first time out.

 

I got the same advice when I started: make a game not an engine. But after finishing a couple of games I felt like I realy couldn't re-use much of my code.

Mostly because I thought things weren't done efficiently or weren't easy to use. At that point I started doing things the way I described above, using carefull design and starting from the ground up and now I can just use this framework I made and start coding the game almost right away.

 

So to summarize my advice: spend some time making a good design, if you write a very good reusable piece of code it'll safe time in the end by avoiding having to recode everything again. But don't try to implement all kinds of features you're not going to use in the current game, you can easily implement those features as soon as you write the game you'll need it in.

 

The classic case of chicken and an Egg.  Till you *have* written a game or two, you don't know what bits are important, much less where to start.  Sorry, I just highly dissagree with most of this response.

Share this post


Link to post
Share on other sites

yeah someone says game engine a lot of times their talking about all the programming responsible for interacting with the low level graphics api (like opengl, directx) or sound library (directsound, sdl) - and things like collision detection and physics - and plenty more stuff - but the point is...

 

you make a 2d game you have to - to a certain level - incorporate all that stuff in to the game. There are certain ways to structure this stuff to make it so you can make multiple games using the same code (all the graphics, physics, collision, sound stuff) but until you have made at least one game how in the world can you know how to structure it?

 

I mean make an engine if you want.. its just chances are you will want to rewrite most of the engine when you go to make a game that uses it

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!