Bad Practise C-Programming: My Idea of Game Development!

Making games? Alrighty! Though I have done a few gameish-things in the past, I’ve never really thought of making anything worth playing, as it has all been just for my own experimenting and learning. I’ve usually done most of my programming using just a text editor and a compiler, and I’ve always been a little skeptic about FRAMEWORKS.

There must be millions of frameworks around for game development, and it seems like picking a single one can be a tough task. At this time, I barely understand how big a game framework can actually be, though I know it must obviously have a little something more than just a means of rendering graphics and playing sounds.

As I’m not a Windows user, it’s a fact that those oh-so-popular Unity engines along with their friends are practically out of question at the moment, but fortunately, I wouldn’t need that 3D stuff anyway, so I could get along with a simpler solution.

Say I wanted to make a game right away! I got a couple of hours… What to do… Let’s see… Google… download… the Oxygine package? What’s that? How do I use this? Where do I start? Oh, the Readme. But… no, I don’t understand. Trashed it.

How about Angel 2d? They say it’s a cross-platform game prototyping framework for C++ and OpenGL, geared towards setting a game up and running in no time!  That sounds cool. Download… Unpack… Readme, readme… Found it! Install dependencies, yeah, cd there… make… Done!

Then what?

Going through the documentation… Got it! It’s a FRAMEWORK! So you’re supposed to throw your code in and just “make” it again? Oh, I hate frameworks! Why can’t you just have your OWN code compiled against some libraries?? The main source file already calls some functions like “theWorld.Initialize();” and “theWorld.startGame();”.

theWorld?? Where’s MY world?! Deleting…

Now I get it. I should have a high-end graphic development environment running with nice sprite editors, scripting WIZARDS and debuggers… and Windows! Ha! I’ll show ’em…

I’ll just apt-get install libsdl2-dev libsdl2-gfx-dev libsdl2-image-dev build-essentials…
mkdir game… cd game/
Now THAT’S a framework!
gedit game.c &

YES! On with the code, at last!

Let’s see… we need… a checklist! Say we have a nice idea for a little top-down single-screen block puzzle game:

-a window? 640×640 will do.
-a game menu? Nah.
-a game loop? Check.
-handleKey(), update(), draw() functions? Can do!
-graphics? Gimp!
-physics? Nah.

A story? I can make up a story!

“A nasty crew of colored blocks is taking over the world! Go, Smileyface! Shove ’em back where they came from and save the day!”

And a name? It’s obvious! “Smileyface and the Colored Creeps!” Way to go, Smiley! Let’s define some constants!

(50 lines of #defines)

Phew, that should do it. Then we divide the screen into blocks, each the size of 32×32 pixels, which evaluates the 640×640-pixel screen down into 20 blocks per axis. Then we define some blocks.

(more #defines…)

Yeah, #defines for GREEN_BLOCKs, RED_BLOCKs… All the blocks. And walls. And holes where to shove those blocks.

Then we DRAW those 32×32-pixel blocks, along with a nice background and the player face using Gimp and the all-mighty Pattern Fill! These we store into an array of SDL_Surface struct pointers. Then we create some variables representing the player and the game area. Let’s make the player ALL-GLOBAL while we’re at it, just to minimize all the hassle!

And the SDL? GLOBAL. ALL-SO-LIBERATINGLY-GLOBAL SDL_Surfaces for the screen, temp buffer, background and those tiny little 32×32 blocks. Initialize the whole set and there you go!

How about the game world? Let’s make it a 2-dimensional integer ARRAY! Classes, you say? Ha! This is C, so deal with it!

int level1[20][20] = {
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1},
{1,2,0,0,2,1,2,3,0,0,0,0,0,0,0,0,0,0,2,1},
{1,0,0,0,4,1,0,0,4,0,0,0,0,4,0,0,0,0,0,1},
{1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,4,1},
{1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,1,0,3,0,0,0,0,3,0,0,0,0,0,0,1},
{1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,4,0,0,1,0,0,0,0,0,0,0,3,0,0,0,0,0,1},
{1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,5,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,4,0,0,0,1},
{1,0,3,0,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,1,0,0,0,0,1,0,0,4,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,1},
{1,0,5,0,0,0,0,0,0,0,1,0,0,0,0,4,0,0,0,1},
{1,0,3,0,0,3,0,0,0,0,1,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,1,0,0,3,0,0,0,0,0,1},
{1,0,0,0,5,0,0,0,0,0,1,0,0,0,0,0,0,0,0,1},
{1,2,0,0,0,0,0,0,0,2,1,2,0,0,2,0,0,0,2,1},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}
};

Nice! On with the functions! First we need something for capturing keypresses… Oh, it’s in the SDL library already! Let’s just say if we press the ESC key, the game exits, and if we press the arrow keys, we just set a flag that a certain key is pressed.

Next in line is the update() -function! Here we check the flags and see if a key is pressed. If a flag is set, we chance the player’s x- or y- position accordingly, taking 32 pixel steps, that is, going one block at a time. Then we clear the flag.

In the very same function, we iterate through the game world with two nested for-loops. For each object in the array, we check for collisions with the player and move the blocks in the array according to the player’s direction if necessary (that is, we push them if we’re about to hit them). Finally, we draw each of these objects onto the temp buffer, taking an image from the image array (the INDEX in the image array would be the same as the VALUE in the game world array, whoa!), calculating the position in accordance to the for-loops’ counter variables and calling SDL_BlitSurface() on each. Please note, mr. SMILEYFACE! This function has all the game logic in it, that is, if we PUSH that CREEPY block back in the HOLE it came from, we should DELETE the block from the array FOR GOOD! Additionally, we should be really careful not to walk through walls!

What else… Oh, the draw()-function! That’s a short one. We draw the temp buffer onto the screen and… yup, that’s it. The main()-function would be as simple. We call init(), and get some serious looping until the end of days! Okay, until the ESC-key gets pressed. In this loop we call handleKey(), update() and draw(), plus a little delay() in the end. And then we go again. And again. And. Again. Show those blocks, mr. Smiley! Get ’em to the holes! GO, SMILEY!!

Then we trash the stupid game and move to the PS3 in the living room.

 

smiley

Advertisements

3 comments

  1. You should try HTML5 and JavaScript gaming. I have created quite a few already…you can create from scratch if you want or you can use the ‘frameworks’..

    Liked by 1 person

    1. I once did that Breakout game using the canvas element with JS, and yeah, It sure is a little smarter than making “games” in C…

      Like

  2. […] had created a HTML5 and JavaScript game, ages back. A post by leeskine made me post this. You can find it […]

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: