Beginner's Guide to Game Programming

[Moosader]

My latest tutorial I've been working on has been entitled
"Beginner's Guide to Game Programming: A Problem-Solving Approach"
(phew, sounds like a book title x_x)
And I need some peer reviews before I get into the videos.
Right now it's incomplete and has stuff highlighted that I need to update (like on page 30 I don't remember if I need a copy constructor for the struct I wrote, lulz), but will hopefully be done soon (hopefully my wrist stops hurting so bad so I can type better)

What is it?
Episode 1: Makin' Pickin' Sticks is... a guide on making Pickin' Sticks.
The guide assumes you know your C++, and covers newb topics in both Allegro and SDL, such as graphics, keyboard input, sound, text, timers, and then towards the end goes into the more general things like random numbers, bounding-box collision detection, design docs, and super-basic game structure.

The goal of it is to teach people all the building blocks they need to actually write the game, but not just record myself code it start to finish... Have them do the hard part.
I feel that that way, they are learning better by doing than by watching.

Of course, questions are always open and I intend to post extra videos answering major questions. The whole points is to get people used to the basics though.

I think in the future it will gravitate away from a specific library and more towards "Here's how you'd do physics", "Here's how you do maps", type theory, etc.



Anyways. I haven't felt very articulate lately so I'm not sure if the guide comes off as really dull, or hard to understand. I would just like some peoples to read through it and give constructive criticism before I move on to doing the video versions.

Download here:
http://moosader.com/tutfiles/GameProgramming_1.pdf

[thejahooli]

My only complaint would be that you dont explain the code for allegro and sdl (e.g page 10) so for someone that has never done any of either of them will probably find it quite confusing.

[Amarant]

You don't need a copy constructor for that struct, the compiler will automatically generate code that performs a shallow copy. And since it doesn't contain any pointers that should be more than enough.

One thing you should probably adjust is the drawing code you use in the allegro examples. In these examples you call 'release_screen' but you never call 'acquire_screen' beforehand. Also the documentation states the following regarding 'acquire_screen': "You never need to call the function explicitly as it is low level, and will only give you a speed up if you know what you are doing" indicating that you could just leave out the call to 'release_screen'.

So where you have:

Code: Select all

blit( buffer, screen, 0, 0, 0, 0, screenWidth, screenHeight );
release_screen();
clear_bitmap( buffer );

you could replace it with either:

Code: Select all

acquire_screen();
blit( buffer, screen, 0, 0, 0, 0, screenWidth, screenHeight );
release_screen();
clear_bitmap( buffer );

or:

Code: Select all

blit( buffer, screen, 0, 0, 0, 0, screenWidth, screenHeight );
clear_bitmap( buffer );

Note, that the code you provide actually causes a crash/lockup of the program on linux (something I noticed when trying to compile your Goat Puncher code).

References:
http://www.allegro.cc/manual/api/bitmap ... ire_bitmap < acquire_screen calls this.
http://www.allegro.cc/manual/api/bitmap ... ase_bitmap < release_screen calls this.

[hurstshifter]

Excellent guide. Doesn't get too detailed but I think its better that way; clean and simple!


Check on page 21 in the SDL code for WAV files though. It looks like you meant to add in the proper code there but never got back to it? I'm guessing this is why you wrote "ASDF" on each line before a section. Its all video related functions.

[Moosader]

Excellent guide. Doesn't get too detailed but I think its better that way; clean and simple!


Check on page 21 in the SDL code for WAV files though. It looks like you meant to add in the proper code there but never got back to it? I'm guessing this is why you wrote "ASDF" on each line before a section. Its all video related functions.

Yeah, I've left those blank for the moment because I haven't been able to sit down in a place I have internet access to work on it.


And yeah, the acquire screen thing someone told me was bad to use, but I didn't really know the extent of it. Thanks for the info Ama.

[resatti]

Moosader, Why did you put what i said about god and russia and tetris at the end of the post

theres nothing wrong with it or anything

its just.... ....i said that...





COOL

[programmerinprogress]

Moosader, Why did you put what i said about god and russia and tetris at the end of the post

theres nothing wrong with it or anything

its just.... ....i said that...





COOL

it's her signature

Now after that formality...

I read through your tutorial, seemed pretty consistent, if I was starting to program in SDL or allegro, I would find it to be a really good resource

The point about the missing audio section for SDL, I have never encountered anyone actually mention MIDI in an SDL project, I don't think it's part of SDL_mixer, and i've never seen it anywhere, so i'll be interested to see if you manage to find any additional libraries that enable that sort of functionality...

Apart from that, very fluent, well laid out, and incredibly helpful

[K-Bal]

Looks very good Go, write the book now! :D

[Moosader]

Moosader, Why did you put what i said about god and russia and tetris at the end of the post

theres nothing wrong with it or anything

its just.... ....i said that...





COOL

Lol. I just liked the whole "God exists and Tetris is proof" thing, so I put it in my sig. :P

The point about the missing audio section for SDL, I have never encountered anyone actually mention MIDI in an SDL project, I don't think it's part of SDL_mixer, and i've never seen it anywhere, so i'll be interested to see if you manage to find any additional libraries that enable that sort of functionality...

Ahh. I haven't used midis myself, and I couldn't research it without internet so I left it as-is. Will fix doomdoomdoom.

I also updated the Pickin' Sticks page http://moosader.com/game-pickin-sticks.html as more of a "directory" of Pickin Sticks related/inspired games, though I probably should have designed it a little better (it loads a bunch of YouTube files. Maybe I'll just use screenshots)

[Moosader]

I've started to update the videos on youtube, and update the written version simultaneously as I get to incomplete sections.

The playlist is here: http://www.youtube.com/view_play_list?p ... 6F495BD17E

Actually I'd really appreciate some feedback from some comments I've gotten from people and want to know if it's something to be concerned with or not.

It's better to put your DLL's in the system32 folder.

Many people have argued against this so far, as so have I. What do you guys think?

non power of two textures/images should be not much of an issue these days.

A bunch of people also supported this but I know it can occasionally cause some issues if your textures aren't. I've only has issues when using XNA on certain laptops, and nobody's seemed to complain with my Allegro stuff (A lot of sprites I've used are 48x96). What do you guys think?

why is my internet suddenly so freaking slow?!?!?!?!?!?

Why is eatcomics' internet so freaking slow?!

[avansc]

umm. i think its a bad idea to put them in system32. reason being is that there can be version differences. so you can make your app work and break something else in that process.
keeping them in your project folder is fine. and imo a better practice.

[Bakkon]

I just keep the DLLs with the executable, so if I want to distribute my program to someone else, it's easy to zip up the folder and ship it off without bugging someone to put stuff in their system32 folder. Also, version differences, as above.

[eatcomics]

I do the same thing bakkon. It's way more convenient for the user, and convenience is the key to success, you wanna make things as simple as possible to set up... Because most people just wanna play....

[avansc]

you can make installers that put the correct dll's in the correct places, i dont think its about convenience, its about compatibility and not fuxing up the compatibility of already working applications that may be dependent on the same named but different versions of a specific DLL or library.

[dandymcgee]

you can make installers that put the correct dll's in the correct places, i dont think its about convenience, its about compatibility and not fuxing up the compatibility of already working applications that may be dependent on the same named but different versions of a specific DLL or library.

Well I think it's both really. I run many of my applications from my flash drive on computers where I don't have access to install anything (school), so having the .DLLs in my project's folder is very handy.