Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Beginners Guide To DarkBASIC - Pull the other one!

Author
Message
Scimac
19
Years of Service
User Offline
Joined: 25th Apr 2005
Location: Leigh, Lancashire, UK
Posted: 10th May 2005 00:26
I'm giving up on this book. It seemed to start so well explaining everything well but as soon as you get to the interesting stuff involving graphics and game loops all the clarity seems to have dissapeared to be replaced with unexplained code.

Can anyone give me some advice as to where to turn. I've worked through the book to learn the basic commands but still I don't feel confident enough to create a basic program. Any advice would be a bonus.

I'm using DarkBASIC Pro, so ideally any tutorials will be for the DBPro software.

Thanks in advance
HowDo
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 10th May 2005 03:14
You'er not alone most books are like that, they get you going but just when you want them to do the next bit Duh!, they give up.

I think they have to give up because every one out there is thinking along a diffrent line, which is good otherwise we all be like asupemarket!

Have you tried doing any of the very old games that were out there in the eighty's when it all started, they may look like crap, but its how they worked was something else.

Which way are you thing of going 2D, 3D, FPS or RPG, this will lets all know which way you like to be guided.

Hope wsome of this helps but if not post again.

In Space No One can Hear You Scream! (When your comm Line is cut?)
zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 10th May 2005 04:30 Edited at: 10th May 2005 06:04
Scimac,
The reason that the books do this is because every game, is well... different. The difficult part is in understanding how to use logic to control the flow of your game.

It's basically a process of figuring out what data you need to store, how to store it, how to retrieve it, and how to use it to drive the display/graphics in the game, and finally how to update all of the logic for the next frame.

Sometimes this is is easier in a procedural language like DB (as opposed to object oriented) and in some cases it's easier (albeit usually messier - at least the way I write code)

====
All games have one major outer game loop. It can look as simple as this




So, gameover is a variable. In this case it could be an int or a bool type. As long as gameover is = 0 the game will loop. If gameover is set inside the loop to anything other than 0 (ie. 1) the game exits.

====


OK. I know that all the above was pretty obvious. But lets take it a little further.

So lets further define the game loop.
A video game: Is basically a continous loop that performs logic and draws an image on the screen, at a rate of 30 FPS or more. (Nowadays, 60 FPS is usually the mininmum

Here is a General game loop architecture from TOFTWPG by Andre Lamothe. (His explanation here will suffice)

Initialization:
-Allocate Memory
-Load Files
-Build tables
-Initaialize variables etc...

Main Event Loop:
-Exit? Y/N
If YES then break out of the loop and perform cleanup processes
such as:

Close files
Realocate memory
Exit back to the O/S

If NO then we Enter the game loop. This is where all the action takes place until the user quits, or the game ends. Most every game does the following
-Init Timing (ie. sync rate &/or other timing code to control the speed of the game events
-Retireve Player Input (KB, Joystick, Mouse etc...)

Main Logic
This section contains the majority of the game code. Artificial Intelligence, physics systems, and general game logic are executed and the results are used to draw the next frame on the screen.
-Game AI
-Collision Detection
-Physics
-

Render Next Frame
In this section, the results of the player's input and the execution of game AI and logic are used to generate the next frame of animation for the game. The image is usually drawn on an off-screen buffer area , so you can't see it being rendered, then it's copied very quickly to the visible display. [*note The buffering, and sync rate described here is performed automatically for you with DB's Sync rate and sync commands]

Now everything is locked to a certain FPS (or other additional timing code] and we go back to the beginning of the loop

=====

OK. So now your probablly like "Great, I already knew that", so the question becomes how do I make all of this happen???

Unfortunatley this is where every game, (and programmer for that matter differs on approach). Making the case worse is that usually looking at a finished games code doesn't help much, as even with good commenting the amount of logic and things going on become hard to follow if you were not the one programming it, debugging it, adding to it, re-coding it etc...

So what can one do? The most important thing (IMHO) is to understand data structures - what they are, How they work, and finally how to put them to use to make keeping track of all the logic taking place on every frame somewhat manageable. Almost every game, in fact I can't think of one that I have worked on that doesn't, has arrays. Usually mulitdimensional arrays. Your really need to understand them. From there you can move on to other data structures such as stacks, queues,
linked lists, Binary Search Trees etc...

More important than understanding how to define these structures, and how to get data in and out of them, is understanding how to use them to implement logic in your game.

=====

Say for instance the game tic-tac-toe. If I wanted to keep track of of the players X's and O's as well as open spaces, I would consider using a 2-dimensional array.

An empty board woulod look like this:

First in the initialization part of the game (before the main loop) I would dimension my array (allocate memory space for it). A tic-tac-toe board is a 3x3 grid for a total of 9 spots.

dim board(2,2)

(*note in DB arrays start a 0 snd up to the number in the dim statemeny. So 0 to 2; is a 3x3 grid)

Next I would initialize all values of the array to 0. Now I'll show you the method I use to fill a large array. (Keep in mind that a small array such as 3x3 can be easy to maintain, but the following code will help you see how to initialize a large array as well; say 100x100 or more)


for y=0 to 2
for x=0 to 2
board(x,y)=0
next x
next y


so now if we looked at the data elements in the board array it would look like this



That would be the logic for an empty board. Now in the main game loop whe a player tries to place an X or an O all I need to do is check whether or not that location is = 0. If so, it's empty and a mark can be placed there. If it's something other than 0 say 1 or 2 then the spot is already taken.


(note: the logic could be that..)
0=empty space
1=an X is here
2=an O is here


I'll continue with this tic-tac-toe example in a little bit. Let me know if you understand thus far.

~zen


the chode
19
Years of Service
User Offline
Joined: 27th Apr 2005
Location: desert
Posted: 10th May 2005 12:12
did i waste my money if i ordered it 50% cheaper, and have very very little programming skills?

Dude
zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 10th May 2005 13:40
@the chode,

I have the book in question, and I really don't think it's a waste. I mainly purchased it so that I can refer to people's questions about it, as I had plenty experience in other languages (and even I picked up a few things here and there from it).

It's great for beginners and helps them get "started" with the language and the core concepts of programming in DB and some DBpro. You can learn alot from it.

It's just that no one book is going to give you all the answers. The book's goal is to cover a wide variety of topics.

~zen


Scimac
19
Years of Service
User Offline
Joined: 25th Apr 2005
Location: Leigh, Lancashire, UK
Posted: 10th May 2005 17:41
I think I owe an apology as the title of this topic is a bit harsh towards the book. I've read chapters 1 - 9 which gives are core understanding of basic programming where all is explained very well and the programs are clear to follow and understand. I've just been reading chapter 10 which introduces bitmaps which I thought I was understanding until I got to the game at the end of the topic. The problem with the source code is that its not very well commented towards beginners and it has only confused my learning. Maybe its just me

Thanks for all the replies. I've not managed to read all of your repliy Zen, but I will during my lunch today and repost.

Celeron 2.0GHz, 256MB DDR, GeForce FX5200 128MB Ram
zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 10th May 2005 22:40
@Scimac,

You don't have to appologize. A lot of people share your feelings about the book. Mostly though, because it's not advanced.

I'll look at chapter 10 today and see if I can see what's going on.

~zen


Scimac
19
Years of Service
User Offline
Joined: 25th Apr 2005
Location: Leigh, Lancashire, UK
Posted: 10th May 2005 22:47
Not had the time to look through this lunch. I'm going to re-read the chapter and work through the program on paper so that i can follow it more clearly. After all this is what programming is all about

DBPro, Celeron 2.0GHz, 256MB DDR, GeForce FX5200 128MB Ram
zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 11th May 2005 03:48 Edited at: 11th May 2005 04:13
Continuing with my tic-tac-toe example...
(hopefully someone is finiding this useful)

The approach that I will use here is to focus on the major sections of code. Then I will pull them together into a full program.

Note: For simplicity sake I will first have the board in the top left corner.

Each square of the gameboard # will be a 32*32 tile like this. so the topleftcorner of the topleft square is at (0,0). Later We'll move the board to the center of the screen and deal with the offsets.

OK. So lets look how we would change the values in the board array if a X player places an "X" in the center square



if the previous code executed the board array would now look like this


OK. That was pretty easy. But we are missing something crucial. I never bothered to check whether or not the space was already occupied.

So how would I check to see if if the space was empty???
Well, if you remember from above our empty board is when all the array elements were set to 0. So hence, 0 means the space is empty. Following this logic what we will want to do is read the board array location first, and IF it is equal to 0 then it is empty.



I snuck something else in:
-The variables playerXpos and playerYpos
These variables keep track of where on the grid the player is.
These variables will be updated as the player moves.

so say we always start the player in the center of the tic-tac-toe board. We would initialize the variables to:
playerXpos=1
playerYpos=1

Remember, our board array is a 3x3 grid. the location of the top position is 0,0. Following is a text diagram of the (x,y) coordinate pair for the board.

(0,0) (1,0) (2,0)
(0,1) (1,1) (1,2)
(0,2) (1,2) (2,2)

So, as you can see the center position is (x=1,y=1). Here is another way
to look ar our board array [board(2,2)].

board(0,0)=0
board(1,0)=0
board(2,0)=0
board(0,1)=0
board(1,1)=1 since we just place an X in the center
board(1,2)=0
board(0,2)=0
board(1,2)=0
board(2,2)=0

I think it's much easier to envision it the way that I used above, as it floows what the board actually looks like



I have to return to work as my lunch is over. But I'll cover something else real quick.

playerXpos and playerYpos will need to be updated accordingly as the player moves around the board. Basically it comes down to this

pseudo code (fake code)
------------------------
if the player moves left and is not at the left edge of the board
then subtract 1 from playerXpos

if the player moves right and is not at the right edge of the board
then add 1 to playerXpos

if the player moves up and is not at the top edge of the board
then subtract 1 from playerYpos

if the player moves down and is not at the bottom edge of the board
then add 1 to playerYpos

----

I'll turn this into actual DB code later and also define the right, top, left, and bottom edges of the board

~zen


zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 11th May 2005 11:20 Edited at: 11th May 2005 12:29
So lets set up some game constants and convert the idea above into DB code



Now that we have some groundwork let's tie some of these snippets together.




Scimac
19
Years of Service
User Offline
Joined: 25th Apr 2005
Location: Leigh, Lancashire, UK
Posted: 12th May 2005 03:01
@zen

I've been able to look through your tutorial and it is definatly helping. It has definatly clarified the use of arrays for me. Looking forward to the next section

With regards to the ImageShuffle source at the end of chapter 10, my biggest query is with regards to the data statements at the beginning. I understand that this data is read into the MovingMatrix array but I don't know if this data is purely random numbers or if they are specific for calculating the valid moves.

DBPro, Celeron 2.0GHz, 256MB DDR, GeForce FX5200 128MB Ram
zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 12th May 2005 10:39 Edited at: 12th May 2005 10:57
Scimac,

I had let some students borrow the book. I know they returned it to me, I just have to check around the office for it. I'll post tomorrow about chapter 10.

=====================

Moving on with the Tic-Tac-Toe example. So far we have:
1. An intiailized board.
2. A way to respond to player movement.

Our next steps will be:
1. To place a mark "X" or "O"
- Check to see if the space is open
- If the Space is open upate the board array

After that we will need to:
2. Alternate turns for Player 1 and Player 2
3. Add routine to check for a WIN
4. Display graphics to coincide with the game logic
5. Create an AI opponent
6. Touch things up, possibly make the game 3D, add FX, music.
7. Make the game more intersting by being able to play on mulitple boards at one (I'll explain this more later)

So let's get moving!

Confession: At first I thought that I would let the player move around the board and press the 'enter key' to make a mark. At this point I would check to see if the space is unoccupied, and if so place the mark there and update the board array.

Well that's kind of stupid!

What we really want to do is prevent the user from ever being able to move to a space that is occupied. So the check for occupied spaces should be tied with an AND statement in the movement code. Thus when they press enter, we already know that they are over an unoccupied space.

The reson that I am typing this: is just to show that while working on something even as simple as Tic-Tac-Toe; you will sometimes find yourself saying, "Hmmm??? There might be a better way to do this."


So I will place tie in the collision check with our movement code.
It will be slightly more difficult, but well worth it in the end. And we are better off changing it now than later.


Login to post a reply

Server time is: 2024-09-23 19:31:38
Your offset time is: 2024-09-23 19:31:38