Sign in to follow this  

Transition/What should I do?

This topic is 3496 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Okay, I started programming in C++ about 3-4 months ago. I originally did it as a senior project for High School as something I always wish I could do (create my own video game). I followed through a tutorial called Wrath Lands and was able to create a replica in which I transformed into a Star Wars Text-RPG adventure game. After that I started going through a programming book called Beginning Game Programming with C++. After reading through the book I created my own Tic Tac Toe game for two players. And after that I finished a program that I made unique from previous tutorials called Treasure Hunter. I had some rocky points but through this site was able to fix my mistakes and create the game. Now, I want to start getting involved in something more than just console programs. I want actual 2D graphics or programs that at least run smoothly without the requirement of hitting the enter button (if you play treasure hunt I use system("cls") to remove previous text... I want it to be smooth with no flickering screends). What should be my next step? Should I go onto trying some directx/opengl components and learning graphics? If so I simply want to go from console programs to 2D games not 3D... What would be the best graphics library to use? And finally should I not even get involved yet with graphics and simply work on more console programs? To see the projects(games) I made visit the following link: http://geocities.com/aslan649/games.html All of my games are in zip files... enjoy.

Share this post


Link to post
Share on other sites
When it comes to making 2D games, you can learn a language like OpenGL or DirectX--the hard rout or you can learn SDL--SIMPLE direct-media library.

OpenGL can do things easier, like draw a polygonal shape (not necessarily 3D, but it does that too), and stuff like that. The harder stuff is...everything else like initializing it, or drawing things on screen.

SDL is--well--simpler. You can easily start drawing things on the screen and focus at making a game, not making graphics. Unfortunately, it doesn't have ready-made functions for drawing simple things like lines and polygons. It does draw boxes for you, though.

Which you use is your choice. The end goal should be OpenGL, but you might not even need it. You can make good enough games with SDL, and you can write your own code to expand it. SDL doesn't really limit you if you do extra leg work; there are plenty of beautiful games that were made with it. But, I don't know if they also used the graphics part of SDL.

Might have forgotten to mention: SDL does graphics, audio output, controls, etc.

Share this post


Link to post
Share on other sites
seriously, i would suggest delphi. It has many ready-made gfx handling abilities, and can give you a platform for developing opengl/directx games when you've got the basica ideas of bitmap manipulation under wraps.
i would avoid console games, as i'm sure the type of games you want to develop are graphic based. therefore, get used to dealing with graphical concepts as early as possible, while learning good coding practice (such as collision detection, animation, basic optimisations, pixel access on screen, etc).
keep your initial games simple as possible, even if its something like moving the mouse pointer to avoid the falling blocks on the screen, etc. this sort of project is ideal for establishing and fortifying good coding practice so that when it comes to more complex games (and always code games, as they're the best way to learn!), you can simply build upon previous projects and concepts that you have mastered.
that's why i suggest delphi. it's visual, you can make projects very quickly with it, but you still have all the power of any other language such as c++.
(delphi is also ojbect oriented so you can tap into that later, althouth you can ignore oo and code games the normal way which is what i would suggest for the first few years).

basically, all gfx games have this common structure:

1. a main game loop - limits the speed at which a game plays, and also is acts as a 'commander' of the rest of the game, such as checking for collisions, updating characters, checking scores, etc
2. memory assigned for graphics, with graphics loaded (such as bmp files - again , delphi shines in this area for simplicity)
3. an interface (so users can begin a new game, etc)
4. sounds (i would avoid sound coding initially though, as it can be deceptively complex)
5. cleaning up everything when the game is quit (ie freeing up memory used to hold graphics, etc)

so, in the 'avoid the falling blocks with the mouse pointer' game, it would look like this:

load block image(s) into memory
setup intial game states (such as gameover=false, and where each block should fall across the screen initially, and set their y values to -10 so they wont' appear on screen (will be out of screen range 'above it')
anotherwords, you would have an array to hold block y positions such as:
blocks:array[0..max_blocks] of integer; // note this is pascal format

maingameloop()
- if not game over then do the following:
-update falling blocks (increment y position)
-check for collision between mouse and any block (iterate through a for loop
using co-ords of mouse against co-ords of all blocks, which would be stored in an array [game over if collision, eg stop iterating through maingameloop()]
-check if any block has reached bottom of screen and add points for each that does (again iterate througha for loop checking y co-ord)
-clear screen (so previous graphics erased ready for new block draws to begin)
-draw blocks (using delphi's '.draw' procedure [nice'n'simple])
-pause before next update (to force 30 frames per second, etc)
(no need to draw pointer as windows draws it for you)

etc, etc.

Share this post


Link to post
Share on other sites

This topic is 3496 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this