A checklist of basic game elements


Blue Protoman

Well-Known Member
Joined
Mar 6, 2010
Messages
4,117
I've decided to start working on SDL alongside the rest of C++. I'm partway through the chapter on classes in my book, but I've decided that I need to mix it up a bit. It's too early now, but at one point I'm going to do some tech demos revolving around game elements just so I can get the logistics behind them down. These are what I can think of, any more that I missed or that you think would be a worthy challenge, let's hear 'em.

  • Menu (with mouse button)
  • Menu (with button-controlled cursor)
  • A platformer character moving, jumping, and collecting
  • Pressing a key to spawn items (will be key with some demos)
  • A shmup character moving, shooting bullets, and collecting powerups
  • A speedometer in both mph and km/h that is adjustable on the fly
  • A top-down car that can rotate, accelerate, decelerate, and shift gears
  • Collecting and reloading of ammunition
  • Collecting and using things of an inventory
  • Collecting, switching, and using different weapons



I won't be doing this for a while, but it's nice to plan like this. Any thoughts?
 
Being able to press T to make the characters pants fall down... That's an important one :D
 
Start easy, and increase the difficulty a _little_ bit on each step.


A plateformer should be at the end of your list, not on #3


I would say :


1) draw a simple menu on screen


2) make it button-controlled


3) add mouse support


With that you'll have your 2-4 nexts weeks busy :)


Then choose a _simple_ game, aka something that dont involve physics, collisions detections ( my minesweper was that step ;) )


Build the logic behind it. Add the graphics. Add a menu.


Then get more docs about collisions detections and start a little plateformer


etc etc etc
 
Yes, BP, a thought: Make sure you pay attention to your chapter on classes. Some of it is not as easy to truly "grok" as it is to go "mmhmm, mmhmm *flips page*". For instance, it took me the longest time to grasp the concept of polymorphism and I still have trouble using it sometimes.


That said, I'm learning SDL and game programming in general as well and I'll give you "advice" (Can it really be called advice if I've developed it for my own use, yet it remains untested? I guess I'll just say I Think This Stuff Is A Good Idea Based On Intuition Formed By Years Of Non-Game Programming And What I've Read About Game Programming, Combined.)


One of the things you'd want to do is build a very light, very simple "game engine". Do this for a simple project so you don't have to do it fifteen times while you're writing a serious game.


If you're planning on doing any networking between games, extend one of your demos (How about the car one?) to use networking. Do something like developing an interface class, separate from the Car class (which each Car owns at least one of), to send commands to the car ("Driver"), and writing three base child [oops] classes, "HumanDriver", "CPUDriver"; "NetworkDriver"). I'm thinking of doing something like that myself, very soon.


Also, ensure that you remember to regulate your game's timing separately from the framerate. Due to the ever-changing state of your game, you don't want to draw the screen for every single movement-- the frame rate requirement would then approach infinity and your (and more importantly, your user's) graphics card's ability is... not infinity. Also, you don't want your framerate dictating the speed of your program-- not only will the speed jump back and forth as CPU frequency scaling, other applications, etc. change the amount of cycles your program has available, but the game will also run faster on one machine than it does on another. Use clock ticks to regulate speed, not "loop iterations per second".


There are more, but I'm sure you've got enough to start with, and I'm sure there are more informed people that would be of much more help than myself.


Oh, and be prepared to run into disappointments; be prepared, as a rule, in general! For instance, I am writing a game right now that is just a simple board game, yet it's taken me a couple of months past my self-imposed deadline. Why?

  • It turns out SDL is entirely retarded (according to what I thought it could do; I use the term in jest... but I truly thought it when I was having all these issues!).It cannot rotate an image. At least, not fast enough to render it real-time. I ended up using a combination of trigonometry and no less than 15 pre-rendered images to "simulate" rotation, and it is not a project-portable solution (I can't just re-use the function; it was built specifically for this game).
  • It has no idea how to flip an image either. You have to do this yourself, by individually manipulating the pixels.
  • There's no concept of "moving" an image around; you actually change where you "blit" it onto the background, and repeat the entire process whenever you want to draw a frame. This seems like common sense now, but it really puzzled me a couple months ago.
  • SDL can render images. SDL can respond to clicks. But SDL cannot automagically create a button and assign some action to it (Can anyone more advanced tell I'd worked with a GUI framework like WxWidgets after this one?). You have to do this yourself by keeping track of where the button is and checking to see if any given click event happened in that range.
  • Pretty much: SDL will not hand-hold; SDL will not sugar-coat. SDL is pretty much raw interaction with the basic ideas of drawing frames and handling events, and that's it.
[*]Computers are a lot slower than we think they are. Millions of instructions per second does not mean millions of lines per second. Things like blitting frames and manipulating pixels have at least O(n) complexity which doesn't sound bad but it certainly slows things down when you are drawing/manipulating 800X480 = 384 000 = .38 million.[*]I just didn't have a solid plan. I thought I could just jump in... and I'm kinda glad I did, because I'm learning from it. Still, before I start another project, ever, I will put in substantially more planning time-- no code, no drawing, no composing music or sound effects... just planning until planning is done.




 
Last edited by a moderator:
I don't expect to make Final Fantasy before I start college. Hell, not even Pac-Man. I'm not even starting with real games, just tech demos featuring some of their elements to get the logic down. And that's AFTER I complete all (or at least most of) these LazyFoo tutorials. Early in the summer I had a goal; start making a game by the end of the summer. Yeah, right, as if that's going to happen now. I realized that about two weeks ago.
 
Last edited by a moderator:
Early in the summer I had a goal; start making a game by the end of the summer. Yeah, right, as if that's going to happen now. I realized that about two weeks ago.

Hah. Well you could do what I did, jump right in and learn it as you go. As a warning, though, it (very slowly) produces a God-forsaken heap of functional yet illegible code, and the error to trial ratio is somewhere approaching 1.


I'm going to release my project under (L)GPL/CC-BY-SA, but instead of making a contribution to the community, I feel that I'll actually be creating a burden!
 
Heh heh, I was raised on a "Do it right the first time" mentality, so on further consideration, that Tron remake I wanted to do so bad can probably wait a year or three.
 
Heh heh, I was raised on a "Do it right the first time" mentality, so on further consideration, that Tron remake I wanted to do so bad can probably wait a year or three.

I was raised on the same mentality. However, since I was also raised to be a racist, a misogynist, and a conservative, and am none of them today, I suppose it's an overall good thing that nothing really stuck.


(in other news, AquaAnalogue has family issues today; film at eleven)
 
Yeah, but doing it right the first time isn't a bad thing. Even mistakes are right if you learn why they're mistakes.
 
Of course, even mistakes have a time and place; it's better to screw up now, as a senior in August, than in college or the workplace when the time for learning is running out.
 
Of course, even mistakes have a time and place; it's better to screw up now, as a senior in August, than in college or the workplace when the time for learning is running out.

You'll screw up then too; but please don't take that as I have a low opinion of you. I found I made massively more mistakes when I started working as a professional programmer. There's pressure on for deadlines. Things get overlooked/missed. Thankfully, our work environment is very fluid. My friend says I'm "Agile" without the labelling. We never roll back unless the problem really takes too long. Just constant small releases. When implementing the new system, I think we got up to 15 releases in a single day! I still release lots of bugs, and scramble to fix them when reported. Just the nature of the environment.


Do not think that time for learning is running out. After all, there's so much to learn, so many technologies, you can't stop, otherwise you'll slowly be out-dated. I still know x86 assembler, and would love to carry on using it, but it's just not even close to practical for anything more than just minor optimisations within an app/game. I know a guy who still codes C64 games, whilst it sounds fun, this is the perfect example of getting stuck in a rut. It's a shrinking niche market.


I think one of the reasons why a lot of my projects don't finish is because it gets past the point I'm learning from it, so I ditch it in favour of something new. The Collector was my last full game that I forced myself all the way through. I am happier now I did that, but it was hard going. You'll also probably find a few bugs in the networking code too... ;)


Whether you develop professionally or for fun, you can't guarantee there won't be cockups, but don't let that dissuade you. The finished product is always worth it.
 
Last edited by a moderator:
Of course, even mistakes have a time and place; it's better to screw up now, as a senior in August, than in college or the workplace when the time for learning is running out.

You'll screw up then too; but please don't take that as I have a low opinion of you. I found I made massively more mistakes when I started working as a professional programmer. There's pressure on for deadlines. Things get overlooked/missed. Thankfully, our work environment is very fluid. My friend says I'm "Agile" without the labelling. We never roll back unless the problem really takes too long. Just constant small releases. When implementing the new system, I think we got up to 15 releases in a single day! I still release lots of bugs, and scramble to fix them when reported. Just the nature of the environment.


Do not think that time for learning is running out. After all, there's so much to learn, so many technologies, you can't stop, otherwise you'll slowly be out-dated. I still know x86 assembler, and would love to carry on using it, but it's just not even close to practical for anything more than just minor optimisations within an app/game. I know a guy who still codes C64 games, whilst it sounds fun, this is the perfect example of getting stuck in a rut. It's a shrinking niche market.


I think one of the reasons why a lot of my projects don't finish is because it gets past the point I'm learning from it, so I ditch it in favour of something new. The Collector was my last full game that I forced myself all the way through. I am happier now I did that, but it was hard going. You'll also probably find a few bugs in the networking code too...
wink.gif



Whether you develop professionally or for fun, you can't guarantee there won't be cockups, but don't let that dissuade you. The finished product is always worth it.

Have you ever created multiple smaller programs with the intent to merge them into a larger program or game? Or have you integrated multiple programs seamlessly before?
 
Have you ever created multiple smaller programs with the intent to merge them into a larger program or game? Or have you integrated multiple programs seamlessly before?

I suppose the answer is yes. For example, when I was writing a colouriser routine (tint a bitmap) that converts the pixels from RGB to HSL, then use the SL with a new RGB to colour it, I ended up writing a seperate app to perform this function alone. When I was happy with the code, I embedded it in the game.


I'll often write my "test" apps in VB.NET, because I find it quicker, but convert them to the game's code later
 
Back
Top