What should be the components of a 2D side-scroller game?

I'm very new to programming and I'm just trying to scratch a curiosity itch here.

If making DOS-type 2d games with sprites, what different components would one have to be familiar with?

Would there be any reason to use Dx or OpenGL with such games?

Would it be worthwhile to make use of libraries, or would such a program be so simple to write that it wouldn't matter, and might just bloat the app? Or would it maybe be corner-cutting and depriving of a learning experience to not do all the programming oneself?

How is the 2d artwork merged with the code?

Do basic 2d games actually have something that is considered to be a game engine, or are they just a few pages of code that the compiler understands apart from a defined engine-base?

are you familiar with any programming languages, or even the concepts of programming? from the tone of your question, it seems like you are not.

Correct:

Quote:

I'm very new to programming and I'm just trying to scratch a curiosity itch here.

That's something of a problem. Learning your first programming language takes quite a bit of effort so you might want to look into Game Maker or something of the sort. If you are intent on learning to program to make this game, don't start out with the mindset of "I will just learn to program while making the game!", that doesn't work. Games involve graphics and sound and whatever else that just leaves you learning too much at once.

I'm not that good at game programming (or programming in general), but I will try to answer your questions.

You might have to be familiar with some 2d graphics programming, scaling/rotating/animation of sprites, collision detection, some basic physics, basic AI, input handling, event programming, sound and probably some other things.

You can use DirectX and OpenGL. There are, however, some libraries that only aim for 2d graphics though and are easier to use such as SDL.

On a protected mode operating system such as Microsoft Windows or GNU/Linux you need to use APIs to get access to the screen/graphics card. On DOS you could just access the video memory directly but that won't work so well with multitasking and probably for security reasons too. Games beyond tic tac toe aren't simple to write but even then tic tac toe pulls knowledge from a lot of different areas.

You can store it in files and load it in at runtime or I guess you could compile it into the code. Probably easier for any sizable game to load in at run-time so that you can change art without recompiling the code.

In my uneducated and limited view of game programming, you can kind of do both. You can write your game procedurally and kind of 'script' all your events directly in to the code; this approach will not get you beyond fairly basic games though, I don't think. I believe that usually a game engine is written that will cover as 'tightly' as possible all of the functionality that the game will require and then the artwork and scripting is done on top of that. I do believe this depends on genre though, space shooters and adventure games require different amounts of art/scripting.

Like I said I'm not very knowledgeable on game programming so anyone here feel free to correct me on absolutely anything that I am wrong about.

Thanks for that information, it has helped me get a better feel for what's ahead :)

I think that you're doing "premature optimisation", the term we use for when someone worries about optimising their code before they've even got anything written. When you can write the code, then you can worry about those kinds of things. I have written games (I'm writing one now), so I feel I can comment here.

Just the mention of game "engines" is enough to show me that you're not au-fait with things. An engine isn't a particular "thing", sure we refer to "the Quake engine", etc. but it's really just an infrastructure for the code you have written, a nice way to re-use code among similar games. There isn't a famous "card game engine", for example, but almost every card game has one. Hell, there are point-and-click-adventure "engines" (e.g. SCUMMVM, etc.), there are pool game engines, there are FPS engines (Quake, Half-life, etc.), there are command-and-control-game engines (e.g. Red Alert). But in the same way that you can say that Team Fortress 2 is a "Source engine" game, so are most of the newer Counter-strike games. And they all use the same "engine", but they all have different features and capabilities. Basically "engine" is a really poorly defined thing, that basically means the surrounding infrastructure for a particular game. I have an "isometric game engine". I've used it to write several isometric games. But it constantly evolves, changes, can't be separated out into it's own thing and if you wanted to do something differently to how I have done it, or something I haven't done in it, then you have to change the "engine".

By "DOS-type", you also don't understand. Do you mean DOS? No. You wouldn't write a DOS game in this day and age, because of the reasons mentioned. What you mean is "old-fashioned", and nothing to do with DOS at all. You mean a 2D game with sprites. There's nothing inherently DOS or Windows about that, and people are still writing them all the time (the last indie bundle I bought included a call-center simulator like SimTower, 2D side-on, with sprites, and that was for Windows). So you really shouldn't be mentioning DOS at all. I assure you, it would not be sensible to program in DOS at the moment and you don't want to confuse. "2D side-scroller" would have been fine (Sprites? Basically every game for the last 25 years that draws on the screen uses sprites - it's just a term for a particular set image that you put on the screen at certain locations to represent something, e.g. a wall, or a door, or a character).

I'll assume you're talking about a mario-type game. Well, you'd need to know how to load sprites from disk, "blit" sprites to the screen, how to represent and move characters in code (i.e. mathematically describe the arc you want them to take when jumping, etc.), take input from controls, maybe load and play sounds, etc. If you've never programmed before it could take you a few hours to work out how to do the simplest of those things, so worrying about using "the best" method isn't really the best way to go about things. It's like learning to drive for the first time and thinking you have to do it with the perfection and timing of a Formula One driver, or being a medical student and expecting to have to deal with performing brain surgery on your first day.

The way you do use libraries or write code depends on many things, from your experience to the performance you require. For a simple 2D game, DirectX or OpenGL might be considered overkill (i.e. you don't need their sort of performance), but if you use a supporting library like SDL (which makes all the above things very simple), then you'll find that in the backend it might use them anyway. Or you could bypass SDL and do it yourself - some people do so that they can make the games look prettier or they can learn how to use those libraries. There's no reason TO use them, but there's no reason NOT to, if you're learning. My games are generally written in an old version of SDL, but I also coded an OpenGL backend into it after a few days of reading books. The fact of the matter is that it's not that big a deal and you can always change later if your code is any good. Your code *won't* be good enough to worry about for a long while yet (not to sound condescending - hell, I was a first-time programmer many years ago so I've *made* all the mistakes that I tell people to avoid already, and still do, so I'm not claiming to be perfect).

Similarly for other things - sure you can write code to enumerate and read input from every input device on the computer, or you can use a library which will save you having to learn the insides of Windows device driver enumeration - it depends if you want to know how that library is doing things, or you just want to use a library to read from the joystick / keyboard itself in one command. Maybe the library doesn't support multiple mice like your game requires and you have to code that bit yourself - it's all a choice. For a beginner, I don't think you want to get into things too complex too early, the complexity can be discovered when necessary. It's like learning to drive a car and your first lesson is all about the thermodynamic properties of high-octane fuel under pressure - sure, it's cool to know but you probably would rather get into the driving seat first and learn about that later in your own time. It won't help you get the car started if you don't know how to turn the key, for instance.

App-bloat? When your final non-debug executable passes 10Mb, you can worry about app bloat. I have a 150,000 line C game with SDL, five SDL libraries, OpenGL, OpenSSL, zip libraries, a PNG image library, a QR-code library, etc. The final executable is about 200Kb (i.e. not worth worrying about), the associated DLL's cover a Mb or two (still not worth worrying about), and the data for sound and graphics for the 2D game is about 10Mb (still not worth worrying about but larger than all the code put together). Games just aren't that big, especially if you're sticking to 2D, and certainly if you don't have a line of code. And the reason the OpenGL code puts a megabyte onto your application? Because your application will use a megabyte of code that, otherwise, you'd have to write yourself anyway!

2D artwork tends to be stored in separate files. My game literally uses just PNG files saved in a ZIP file. Others use the raw PNG files. Going through my Steam library, at least 20+ games use just normal PNG files sitting in their folders, and even more use just normal OGG/MP3 files for their sounds. Others bundle them in proprietary containers so people are hindered if they try to "steal" them for their own game (a pointless endeavour). Then the library (or hand-written code) you use loads up those files into memory, converts them into a format suitable for the screen/soundcard and your code tells the computer where and when to draw them on the screen / play them through the speakers.

But you're really just getting ahead of yourself. Pick up a tutorial that you can understand. Do it the way they suggest. When you're confident and writing games without their help any more, then you can question the way they've done it, and try to improve. It's like learning to drive a car again - you will never drive the way you do on your first lesson, or even on your driving test, once you get used to driving. You will not step into a car for the first time and balance it on the clutch, and judge the first corner perfectly at something approaching a safe, but close to the limit, speed. It just won't happen. You'll be taught to hold the steering wheel in a funny way, pull off more slowly than anyone would in everyday life, you'll be in a car that's at the peak of its maintenance and safety (and probably has things like power steering, ABS, maybe an automatic gearbox, etc.), you'll be overrevving and scraping the gears, because when you start out in something you don't want to be worried about getting it perfect. You're learning. Though the high-theory might be interesting (e.g. steering into a skid), you're not in a position to apply it and certainly won't do it correctly first time even if you tried (don't!).

Take some baby steps. Find yourself a 2D game tutorial, no matter what it uses, one that you can understand, follow it through. And when you have a couple of games under your belt (even if nobody would play them but yourself!), then you spot bottlenecks and shortages in the libraries and techniques used and optimise them (by writing your own, learning more of them, using different libraries, etc.).

Until then, it's all just speculation. Basically you're asking people "I want to be a brain surgeon, but I've heard they only use ceramic scalpels and a certain anaesthetic - I need to find some so that I can play about with live brains when I go to my first biology class".

Honestly? Just start learning now. It'll be at least months or years or (from what I see of about 90% of people who ask me about programming) never before any of this actually matters in any game you write.

I would like to stress "Keep it simple stupid". When you do reach a point of creation, do exactly what you intended to do from the onset. Do not add ideas as you go along (save those for perhaps a later game). Do not try to do something completely out of your skill - "I want to make a MMORPG!"

I finally finished a graphical Tic-Tac-Toe game, but previously had failed to finish a Space Invaders type of game because I kept trying to add in things (powerups! powerups would be cool...), eventually it became such a convoluted mess that I just stopped working on it altogether. I took a step backwards and did Tic-Tac-Toe.