Jump to content

  • Log In with Google      Sign In   
  • Create Account


Will a 2D Game Engine complex to make?>


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 StealthPandemic   Members   -  Reputation: 156

Like
0Likes
Like

Posted 23 March 2014 - 04:11 AM

Hi,

 

I was wondering if a 2D Game Engine will be hard to create? I was looking into to create graphics like these:

 

http://steamcommunity.com/sharedfiles/filedetails/?id=210952339

http://indiestatik.com/wp-content/uploads/2013/07/STF_future1.png

http://indiestatik.com/wp-content/uploads/2013/06/ble.jpg

 

My experience as I know Java, HTML5 (Which i also like to create Web-based game too), Python and a bit of C++ (Still learning).

 

Thank You.

 



Sponsor:

#2 ProtectedMode   Members   -  Reputation: 1103

Like
0Likes
Like

Posted 23 March 2014 - 04:17 AM

In what language and using what libraries do you want to program your engine?

 

First of all, don't look at graphics, or how it looks. For example, the second screenshot you linked is just a noisy background with a few sprites and some text on it. This doesn't depend on the engine, this depends on the art team.

 

Creating an engine is certainly possible. But graphics will only be a small part of your engine. Other parts will be physics, input, AI, and eventually networking. You will need a lot of experience to proram a reasonable engine. But I can assure you, 99% of all existing engines that can draw sprites, can handle the graphics of the screenshots you posted.



#3 Aldacron   GDNet+   -  Reputation: 3095

Like
4Likes
Like

Posted 23 March 2014 - 11:15 PM

The short answer: the complexity of a 2D engine depends largely on how you choose to implement the renderer and what sort of features you decide to support. You can look at it in terms of technical complexity and architectural complexity.

Go back to the 90s and the renderers were called 'blitters' and often involved handcrafted assembly and algorithmic tricks that caused faster code to be generated (all of which are largely irrelevant now with the modern optimizing compilers we can work with). Today, you can choose between a variety of graphics APIs, both hardware accelerated and pure software, to use as the backend of a sprite renderer. Using deprecated, immediate mode OpenGL or older versions of Direct3D (or even DirectDraw) might be less complex than other approaches, whereas using a shader-based approach can introduce a range of complexity. This is the sort of thing that significantly contributes to the technical complexity. 

Then there's features. Each feature you support will introduce a certain amount of technical complexity in the implementation details, but also architectural complexity in how they interact with each other. The more features you add, the easier it is to find yourself with a dysfunctional API without a good sense of planning ahead.

Consider a minimal functioning 2D engine: basic sprites (with no transparency or animation), basic audio (sound effects). You can make a number of games with that alone and is about as small of a complexity as you can have. Start adding in more features like transparent sprites, animation, basic collision, streaming audio, networking and you greatly increase the range of games you make, but you're also driving up complexity both technically and architecturally. Add more features like particles, lighting, rigid body physics, support for thousands of players, and other advanced concepts and you continue to increase the complexity.

I think making a 2D engine is a great learning exercise, especially if you take this approach of increasing the complexity. 15 years ago it was much like a right of passage for aspiring game developers, but there wasn't a whole lot of room for features -- most 2D engines back then were all fairly similar in terms of the feature set. There's a much broader range of possibilities these days, so start out with something like the minimal engine I mentioned above, perhaps using shader-based OpenGL or D3D for the renderer backend. Use that to make some simple games, like Pong, Breakout, and Tetris. Then look at adding additional features and consider how you need to expand or modify your architecture to support them. Then make more games using the new feature(s). Then go back and do it again (another new feature and a couple of new games using it). This will give you some valuable experience. Then later on, if it's something you're interested in, you can take that experience and apply it to developing a simple 3D engine, or in using an existing, fully-featured engine to make a more complex sort of game. 



#4 superman3275   Crossbones+   -  Reputation: 2010

Like
0Likes
Like

Posted 24 March 2014 - 11:13 AM

I really don't suggest making a 2D game engine.

 

You will naturally accrue an "engine" of sorts after making a variety of games.

Unless, of course, you've already programmed games and are doing this to learn OpenGL. In that case:

 

Try looking through some other libraries (SFML, SDL, etc.) and see how they handle creating games. Don't copy them, but understand what someone using an engine wants. (This should be easy if you've already used a 2D Library). Then, try to implement these features. Be warned, making a 2D Engine takes a long time, and with the plethora of libraries available today, it's kind of pointless.


Edited by superman3275, 24 March 2014 - 11:15 AM.

I'm a game programmer and computer science ninja ph34r.png!

Here's my 2D RPG-Ish Platformer Programmed in Python + Pygame, with a Custom Level Editor and Rendering System!

 

Here's my Custom IDE / Debugger Programmed in Pure Python and Designed from the Ground Up for Programming Education!

Want to ask about Python, Flask, wxPython, Pygame, C++, HTML5, CSS3, Javascript, jQuery, C++, Vimscript, SFML 1.6 / 2.0, or anything else? Recruiting for a game development team and need a passionate programmer? Just want to talk about programming? Email me here:

hobohm.business@gmail.com

or Personal-Message me on here smile.png!


#5 DareDeveloper   GDNet+   -  Reputation: 917

Like
6Likes
Like

Posted 24 March 2014 - 11:43 AM

I am torn regarding the article.

 

When you write a game instead of writing a framework and using it for a game, that often leads to problems with the cross-cutting concerns.

You end up with tangling and scattering, you do not go for separation of concerns. The "writing an engine" approach leads to better auto-pilot decisions.

 

On the other hand I love the TDD approach. In theory you can write a game and keep the functionality you are adding clean ... and the architecture flexible.

The problem is that there are many ifs for that to go well ... most people do not think about adding functionality the right way until they have played the thought of what adding a feature as engine functionality would look like.

 

So I like the engine approach and think about that as best-practice-training-wheels.

I guess a combination is the best compromise: writing a game (or several games at once?) while writing the engine features that you need at the moment.

Guess that is what the article tries to suggest but not places the focus on ...


Edited by DareDeveloper, 24 March 2014 - 01:07 PM.

Given enough eyeballs, all mysteries are shallow.

ProcGames.com


#6 Nathan2222_old   Members   -  Reputation: -400

Like
-3Likes
Like

Posted 24 March 2014 - 12:28 PM

I really don't suggest making a 2D game engine.

You will naturally accrue an "engine" of sorts after making a variety of games.
Unless, of course, you've already programmed games and are doing this to learn OpenGL. In that case:

An article written 7 years ago, seriously? When you were posting, did you get confused between a 3d and 2d engine? If you were talking about a 3d engine then i would disagree less (disagree) but 2d engine, then i disagree as i've seen 1 year for that "long time".
How does one accrue any reasonable engine between a racing, puzzle and rpg game? If you said writing a game without a game without an engine but with libraries, then i get it considering you have to make the parts work together which will lead to an engine.
@stealthpandemic: make the engine if that's what you want and Aldacron gave really good tips.


UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


#7 dejaime   Crossbones+   -  Reputation: 3949

Like
3Likes
Like

Posted 24 March 2014 - 05:27 PM

I guess a combination is the best compromise: writing a game (or several games at once?) while writing the engine features that you need at the moment.

Guess that is what the article tries to suggest but not places the focus on ...

I agree with you, and always feel like this article is misquoted.

Sure, there is the classic you don't necessarily need an specialized engine speech (what I also vouch for). But the most important paragraphs are the last two, where he says one should "grow an engine" by making several simple games. This allows you to really see what works and what doesn't earlier, and in the end you'll have a better result than an engine built based simply on theory, but with little to no real use until it is in a really advanced stage, where changes are way more problematic...

He preaches against this making an engine as an end thought, in contrast with making an engine as a means to an end.

Of course, I have made games where most of the code was so specific it had little use outside, and would require more changed/new lines than kept ones. If one wants to follow what that article says, he still has to keep in mind all of those engine concepts, and not ignore completely and just make what the specific game requires...

 

As for me, I can say I searched a 2D engine for my last project, but none fit my requirements.

So I am coding it along with the project, and I am pretty sure that, when I go over to the next one, It'll take 1/2 the time, even less.

 

So, my friend, if you want to create a 2D engine, go ahead! But make it differently. Create a simple game while keeping your code clean and decoupled. Then pass the reusable parts to another project and, again, keep it clean and decoupled while adding more features. You'll have a nice and cooperative collection of tools in the end.

 

... or plan and create an engine, based on theory. You can put a simple 2D engine up and running in a few months.

Just remember you can run into one of these:

http://jb.404whylo.com/1279/Reality-101-Failure


Edited by dejaime, 24 March 2014 - 08:34 PM.


#8 Nathan2222_old   Members   -  Reputation: -400

Like
-2Likes
Like

Posted 24 March 2014 - 05:54 PM

So, my friend, if you want to create a 2d engine, go ahead! But make it differently.

You deserve a +10.

Edited by Nathan2222, 25 March 2014 - 10:32 AM.
Removed unnecessary quote contents -- please don't quote a large post just for a throw-away remark.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS