Jump to content

  • Log In with Google      Sign In   
  • Create Account

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


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
16 replies to this topic

#1 turquoiseptato   Members   -  Reputation: 128

Like
1Likes
Like

Posted 09 April 2013 - 03:50 PM

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?



Sponsor:

#2 ultramailman   Prime Members   -  Reputation: 1570

Like
0Likes
Like

Posted 09 April 2013 - 03:56 PM

You can start with SDL, and using a language you like.

#3 AllEightUp   Moderators   -  Reputation: 4209

Like
0Likes
Like

Posted 09 April 2013 - 04:05 PM


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. :)



#4 Servant of the Lord   Crossbones+   -  Reputation: 19512

Like
16Likes
Like

Posted 09 April 2013 - 04:15 PM

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 Pythonbiggrin.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 without 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.

 

You said, "But let's say I know nothing!". Okay then, start here, and learn to crawl (basics of programming) before you walk (Pong and Tetris) before you run (a original 2D game of your own design). The process is slow, but very much worth it! smile.png

If you need help, there are thousands of gentlefolk ready to help and standying by on these forums when you have a question that Google can't answer.


Edited by Servant of the Lord, 09 April 2013 - 09:00 PM.

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#5 Jutaris   Members   -  Reputation: 475

Like
3Likes
Like

Posted 09 April 2013 - 04:19 PM

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!


My Site -- My Music  -- My Ramblings -- My Game

 Basic Flying Rules:Try to stay in the middle of the air. Do not go near the edges of it. The edges of the air can be recognized by the appearance of ground, buildings, sea, trees and interstellar space. It is much more difficult to fly there.

Come join us for some friendly game dev discussions over in XNA Chat!


#6 turquoiseptato   Members   -  Reputation: 128

Like
0Likes
Like

Posted 09 April 2013 - 04:34 PM

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, 09 April 2013 - 04:35 PM.


#7 Servant of the Lord   Crossbones+   -  Reputation: 19512

Like
2Likes
Like

Posted 09 April 2013 - 05:07 PM

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, 09 April 2013 - 05:07 PM.

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#8 vleugel   Members   -  Reputation: 252

Like
1Likes
Like

Posted 10 April 2013 - 12:48 AM

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.



#9 AllEightUp   Moderators   -  Reputation: 4209

Like
3Likes
Like

Posted 10 April 2013 - 01:51 AM

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.



#10 EarthBanana   Members   -  Reputation: 902

Like
1Likes
Like

Posted 10 April 2013 - 06:51 AM

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



#11 Servant of the Lord   Crossbones+   -  Reputation: 19512

Like
5Likes
Like

Posted 10 April 2013 - 11:30 AM

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.

Absolutely. A game, even if you make it without using an 'engine' that's pre-made, has components in it that can be called an 'engine'. The term 'engine' is used very generically.

I'm in no way saying start making levels before your game can display the levels, nor am I recommending to just 'code it as you go'.

Yes, design and plan out the architecture of your game, which includes the structure that makes the game run. My point is, don't try to make that structure so generic that it'll fit any game. Make the structure specific to the one game you are currently focusing on. If you make a game, you make an engine that is custom-made and specific for that game, whether you intend to or not, whether you know about engines or not. Later, you can remove those 'engine' parts, make them more flexible, and use them for another game. This becomes your 'engine'.
But if you try to make a engine that is flexible from the get-go (without having lots of experience), without having previously made multiple games, and without having a specific game in mind, your engine becomes useless because it lacks a game to keep the engine's features and goals in-check.

I'm not arguing that your game shouldn't be planned out, and engineered skillfully, but rather that you should skillfully engineer the game and engine together, so the requirements of the game actually steer the development of the engine, lest you make an engine that serves no purpose and fits no game without heavy modification.

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.

But the key there is "after finishing a couple of games". You already understand how games work, before you were able to make re-usable components that work with games. If your very first programming project is making a game engine, you won't know how to make the engine because you never made a game.
 

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.

Definitely. This applies to all software programming. Reusable pieces of code should be created for everything from text editors, to websites, to games. Reusable pieces of code on their own don't become engines. 'Make games' doesn't mean, 'Code poorly' or 'Don't plan', it means (when starting out) 'focus on your current project (the game), not on your next few projects'. It means, don't write your code for imaginary projects down the line, but write it for your current project today. Definitely write it reusable, clean, and stable the first time - you'll be able to adapt it and use it when you get to those later projects, and overtime it'll become very flexible and even more stable. But trying to write it flexible the first time (when you're a beginner), results in not useful pieces of code even for your current project.

Writing code without having solid requirements in mind, results in code that doesn't really fit any purpose.

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.

Yes, exactly! That's one of the primary points 'write games, not engines' is trying to get across. You phrased it alot better than I did.

I'm not at all trying to say, don't write clean code. All code should be clean, almost all the code should be reusable, self-contained, and stable. I'm trying to say to write functional code (whether it be an engine or a helper library or just a few functions), you must have a goal in mind to steer the requirements, or the code usually becomes too general to use without you having to write boilerplate over it to make it usable.

Almost all games have 'engines', and so 'write games, not engines' doesn't mean to make a game without making the parts that run the game - it means to make a game (including the parts that run the game), but don't try to make a super-flexible engine before you even have a game in mind - tailor the engine to the game, the engine is part of the game, so let the game drive the design of the engine.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#12 vleugel   Members   -  Reputation: 252

Like
1Likes
Like

Posted 10 April 2013 - 12:07 PM

I don't think a beginner is really considering all kinds of low-level stuff when he talks about a game engine. And telling him to just code the game without thinking of the engine, might let them think they should rush into programming the game logic and skipping a good game design. But I tend to agree to most points of the last posts here and in the end it might actually be a good thing if you let the beginning programmers find out their code is not re-usable, so they can learn from their mistakes :)



#13 wizardpc   Members   -  Reputation: 282

Like
1Likes
Like

Posted 10 April 2013 - 01:02 PM

As someone that has coded a framework 3 times now  (I wouldn't call it an Engine, but more of "reusable classes" for my games), I would advise making SMALL games and then designing an engine/Framework around that. 

 

After my 4th or 5th game, I scraped my design, and I'm currently reworking my framework to be more "engine" like, and I'm actually happier this way.  But I would have no idea what to look for if i just started by attempting to build an engine.  I'm not sure how much of this is related to a 2D engine since the concepts are easier, but there is still resource management and data structures.  Start small. But always think about "How could I reuse this if I wanted to make another game".



#14 3Ddreamer   Crossbones+   -  Reputation: 3156

Like
1Likes
Like

Posted 10 April 2013 - 02:41 PM

Hi,

 

Making a 2D game engine should only be considered a novelty hobby or learning project.  To make a professional quality 2D game engine, you really are only reinventing the wheel and spend a good 5 to 10 years doing it when you could be making marketable games and making money most of that time!


Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software.  The better the workflow pipeline, then the greater the potential output for a quality game.  Completing projects is the last but finest order.

 

by Clinton, 3Ddreamer


#15 warnexus   Prime Members   -  Reputation: 1432

Like
1Likes
Like

Posted 10 April 2013 - 09:34 PM

If you know nothing, then you need to start from somewhere and build off from there. It is the only way to learn and gain an understanding of a particular subject.

 

If you do not know anything, then you should not even begin building an engine. It is a good challenge if you know enough.

 

Learning the basics is like riding a bike with training wheels. Learning GUI and graphics is like riding a bike with the training wheels off.


Edited by warnexus, 10 April 2013 - 09:48 PM.


#16 PoliticalChaos   Members   -  Reputation: 151

Like
0Likes
Like

Posted 11 April 2013 - 09:05 AM

I've recently started a game project, myself being the only developer and working in collaboration with 3 artists. I settled on the Unity Engine for my 2D game because of how much is already done for you as a game programmer can focus on gameplay and not the boring stuff like creating collision libraries and object factories and object managers.. etc the list can go on forever. Also, the asset pipeline in Unity is extremely robust and can pretty much take anything you throw at it as far as 2D/3D assets. Give it a try if you have the time - well worth it.



#17 Nercury   Crossbones+   -  Reputation: 766

Like
1Likes
Like

Posted 13 April 2013 - 05:01 AM

Your engine is only good for what you test it for.

 

The big part of writing a reusable and good code is being able to test it in a real-world scenario. In case of a game engine, I would discuss that it is near impossible to write a good game engine without writing a game. Even then, this makes this engine only tested for this specific type of game [1].

 

Why it is so? Because a use-case is the main factor that drives any software. A good game code works for game-related use case, and not for an idea of a game-engine. If we test your engine by executing some demo of 3D terrain and a skybox, then our engine is good for making a demo for 3D terrain and a skybox. If we try to build a game on top of that, we will most likely find that our engine needs to change. Because our use-case have changed.

 

Do we really need an "engine"?

 

Why do we even want to write game engines?

 

I think we do not like the idea of our code being used for one game only. Why rewrite, when we can reuse the same thing again and again? Let's separate our engine-specific and game-specific code and make engine reusable this way.

 

Well, the problem is that games are quite different. And we like different games. Even in 2D side scrollers, we want to make new wildly insane mechanics different for every game and maybe even the level. The bad things start happening when the game-specific stuff starts to creep into our engine. Now, instead of being optimized for a single game, our engine needs to be optimized for both use cases. And sometimes it is not feasible, and we may end up using separate engine versions for separate games. We should have just made different games without wasting time for one engine.

 

The "good" code.

 

Let's just accept the real world, and embrace it. In the real world, no one ever creates perfect code (except me, but that is a joke [2]). Things break in the real world. Sometimes we need to rewrite big portions of the code. And we learn, often the hard way, that writing a good code requires a knowledge of what a bad code is/was. 

 

And sometimes a good enough code for one game may be a bad code for another. And vice-versa.

 

It depends on what it is used for.

 

Group code by the Use Case.

 

The big thing driving a good software design nowadays is called decoupling and separation of concerns [3].

The Big Idea is to create the tools, not frameworks or engines. A tool is self-sufficient. It should not know about anything else but itself, and require the minimum of third-party components.

 

Inject a bit of pragmatism here. It is OK to copy-paste a helper function from our "engine" into the tool to make it more self-sufficient. Even better, optimize this helper function to work better for our tool. Our tool can have its own "vector" type, or use plain arrays best suited for its job, instead of using engine's "vector" type. It may not be DRY [4], but it might be OK.

 

A game is a test for the tools, as well as the reason the tools exist. It should remain that way.

The question of deciding what "tools" to write should be dictated by the requirements of the game, not a vague idea of what possible games there might be.

 

How to write a tool?

 

Let's write a game, and let the tools be the solutions to the problems we encounter while writing a game.

 

For example, write an input handling the way it is best suited for our game, and make it more and more tool-like and decoupled as we complete it. This way we can keep an eye on suitability for the game and the performance of our tool.

In the end we can move this "tool" into a separate library. We may use a software like CMake [5] to avoid thinking too much about compilation and linking. We may even write a small demo application that uses nothing but this tool

 

We can write a small demo applications to demonstrate that our solutions work properly without the dependencies of the full game. 

This is good for several reasons:

  • If we ever want to evaluate our tool/solution for inclusion into another game, it is easy to see if they are suitable, because a use case is clearly demonstrated in a small amount of code that is required for a demo.
  • This motivates to avoid adding dependencies to our libraries, because we will need to add dependencies to our demo applications.
  • We see more immediate results while developing a game, because we have the working demo applications sooner than the finished game.
  • In case something breaks or needs improving, we can use the demo as testing grounds instead of launching now-big game with all the other clutter.

And even if we do not succeed to completely move our tool into a separate library, our code is still better and more decoupled, because it is more "tool-like".

 

[1] Write Games, Not Engines, scientificninja's blog.

[2] “Nobody actually creates perfect code the first time around, except me. But there's only one of me.” [Tech Talk: Linus Torvalds on git, Google, 15 August 2007].

[3] Managing DecouplingBy Niklas Frykholm, GameDev

[4] DRY - Don't Repeat Yourself

[5] Cross Platform Test Driven Development Environment Using CMakeBy AllEightUp, GameDev

 

(should I expand this into a full article? there is much more to say on this subject)


Edited by Nercury, 13 April 2013 - 05:04 AM.





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