views:

294

answers:

10

Hi, I would like to write some simple Mario-like game from scratch using language C. But honestly I have no idea how to do so, and I can´t find any good tutorial for this, which is for free.

But to the actuall question, I have only written WinAPI programs so far, so all event handling and user input was handled by OS, with minimum work, But to develope game, with for example menus with non-rectangular buttons, animations, and so, I guess, there is no such thing in WinAPI taht could help me with this more than just some basic routines mouse pointer location and keypresses.

So, is the right way to write your game to write entire draw part of game engine by manipulating objects for player, enemies, and even background yourself, and than just use directdraw for output to screen?

EDIT: I actually want to learn how to write games from scratch, becouse it must be great programming experience, and if you consider games like Commander Keen on DOS, created with no framework or libraries, but still so great.

A: 

In short, yes - there's nothing in the WinAPI that will help you much. However, there are dozens of game engines that you could build your game on that would take a huge amount of gruntwork out of creating the game itself. A bit of Googling will help you.

(Personal recommendation: although it's technically a 3D engine, something like Unity is an excellent engine that includes tutorials for creating 2D games. Unity isn't C, but it does make your life a lot easier...)

Dan Puzey
+6  A: 

A good approach to this would be to have a look at the SDL library. I'm not saying it's necessarily the best library for 2D games, but it's easy to get started with and the web is flooded with tutorials and open source code samples for simple homebrew 2D games written using SDL.

kasperjj
A: 

EDIT: I actually want to learn how to write games from scratch, becouse it must be great programming experience, and if you consider games like Commander Keen on DOS, created with no framework or libraries, but still so great.

This is actually not quite right. Commander Keen (and any DOS games) do use libraries: the ones provided by DOS, BIOS, etc. Without libraries of one form or another, you wouldn't be able to do anything useful with C. For game programming, you really do want to leave all the low level details to someone else.

I'd recommend Allegro as a beginning game programming library.

Cogwheel - Matthew Orlando
Sorry, I wasn´t clear, yes they used, but only for things like control input, and sending the whole renderen scene to the LCD. (Actually CRT back than). But There was no routines for DOS that could help a game development like managing the screen objects, maybe physics, etc, like todays engines do have.
B.Gen.Jack.O.Neill
actually most DOS games only ever call into the BIOS/DOS for filesystem handling, the tend to pretty much totally replace the DOS keyboard handler.
Spudd86
In that case, pretty much any graphics library will do. Allegro and SDL both have ways you can manipulate the display pixel by pixel. Another somewhat minimalist option is PixelToaster (http://code.google.com/p/pixeltoaster/), if you felt like giving C++ a go.
Cogwheel - Matthew Orlando
@spudd86: but in order to do that, you still need some sort of library to set up the interrupt handlers, or you need to drop down into assembly (in effect, your own library). Of course, now we're certainly moving away from the OP's point ;)
Cogwheel - Matthew Orlando
+3  A: 

I do recommand the SDL too, but you should definitely have a look on lazyfoo tutorial, which is just great.

Aif
+1  A: 

What are you guys talking about, the WinAPI has low level drawing routines.

Although using an established library like SDL is probably a better idea you could create your own abstractions to the WinAPI drawing routines without too much difficulty.

Then it's just a matter of creating the while loop that has all the drawing instructions and interpreting input. For 2D games this isn't too difficult.

Fredrick Pennachi
A: 

I also used SDL, but try to look at HGE. It requires at least DirectX 8.0 so your applications will work only on Windows but on their forum you will find many topics on how to port it to OpenGL. In my opinion HGE will be easier to learn than SDL, because SDL is a low level library and you will have to learn how to handle many things by yourself. HGE is more ready to start just out of the box.

virious
A: 

Check out this one Game dev starting

They have realy a big resource related to game programming and a lot of beginner stuff. SDL is good, but you should consider about learning basic game techniques before start coding and even before start thinking about the api/libs you use.

Clear out how much "intelligence" you need (Ki), consider about loading/Saving a an early time, ... so much things that you should keep in mind if you want to finish your project. Do you need a game editor? (Also..work) What about sound/graphics? Writing all this stuff on your own will take a lot of time (if you do not have experience). Creating the content is another big issue which can consume a lot of time, if you make it at all.

Maybe it will help you to have a look on some dev kids, because that will give you the idea how their engine works. Like this one (outdated) Dev kid

InsertNickHere
+1  A: 

When I started programming I started doing it with Allegro, back in the good old DOS days. It was the first usable library which worked with SVGA libraries, and had a good sprite support. Then version3 came and they added support for windows (using GDI and Directy X, you could choose at runtime which engine to use). The linux port came to life, and all is good.

It's a very basic 2D library, and it will teach you the very basics of graphics and animations. Now it even contains audio support which is a very needed addition (well, I still remember V 2.9X...). They are in betas for version 5, and I think this is an interesting project for you to look into.

http://www.talula.demon.co.uk/allegro/

elcuco
Allegro 5 even has a complete demo of a 2D side-scrolling game
Leftium
A: 

Hey there,

I've just started a similar project a few days ago, you can check it out over at GitHub.
It should give you some ideas about how the game is structured. As well as some details on a scrolling 2D map with collision (which turns out to be quite complicated if you want to get it 100% bug free). Oh, and it's using SDL as many here have already suggested.

As for me, this is my first C project. But I'll have to admit that I've done similar stuff in Java and Python before, so this was a good way for me to quickly learn C. And since it's learning and not any productive stuff, I'm using plain C99, which makes the task even "funnier".

But back to the game, you really need to think about your design before you start coding, write it down on a sheet of paper, or if you're like me and you don't have tree stuff in reach write it in pseudocode.

Think about as many possible game states as you can, nothing's worse than having to re-implement the whole player/map/whatever stuff from scratch just because you did not think about feature XYZ before.

Design is very important, if you don't have a goal to begin with, your project will reach a point where it fails, just like my Tuff did, well it also failed due to missing music and somebody who would have designed enemies, etc.

Speaking of graphics and such, bear in mind that the game will consist of much more than just the plain code. If you aren't good in graphics then take that into account while designing. Because you will quickly lose your motivation when the only things on the screen are colored rectangles.

Ivo Wetzel
A: 

Action Arcade Adventure Set (originally published as a book) is probably one of the most complete tutorials on how to write a 2D side-scrolling game. Although an older reference, many fundamentals for developing a 2D side-scroller have not changed.

Full source code examples and some tools to develop a side-scroller are provided as downloads. There is only one external library used to handle graphics primitives. As this is an older DOS program, you may have to use a DOS emulator like DOSBox or modify the examples for more modern environments.

I suggest you skim chapters 1 to 9 and focus on chapters 10 to 17.

Leftium