Posted: 3rd Nov 2011 5:20
can you tell me please!!!!!
Posted: 3rd Nov 2011 11:02
Look at the examples and modify them until you can launch out by yourself. That's what all programmers do!
Posted: 3rd Nov 2011 12:02
That's a very complicated question but there is a relatively simple answer...

1-Decide what you want your game to be like
2-Create some basic resources (sprite images etc.)
3-Step by step try to get the sprites doing what you want (IE.Step 1-get your sprite to show on the screen, Step 2-get your sprite to move how you want)

That's all game making is really. Coding in AppGameKit is very simple once you understand the basic way a game works:

Setup code (IE. loading images and turning them into sprites)
Game loop/s (IE. a section of code which repeats over and over. Different parts of the loop are used depending on user input)

Loading images...

+ Code Snippet
image = loadImage("myplayer.png") `<<<<load the image and assign it's ID to a variable called "image"
spr = createSprite(image) `<<<<create a sprite using that image and assign it's ID to a variable called "spr"


A simple game loop looks like this...

+ Code Snippet
do
    gosub get_user_input:
    
    gosub make_stuff_happen:
    
    sync() `<<< This updates the screen
loop


The process will go through a subroutine called "get_user_input:" that looks like this...

+ Code Snippet
get_user_input:
    px = getPointerX() `<<<<get the mouse  position in x
    py = getPointerY() `<<<<get the mouse position in y
return `<<<<<return to the main loop


Then it will go through the "make_stuff_happen:" subroutine that might look like this...

+ Code Snippet
make_stuff_happen:
    setSpritePosition(spr,px,py) `<<<<this puts the sprite at the mouse position
return


Subroutines and functions must always be placed after the main game loop.

That's a fairly basic intro. I suggest taking a look at the examples that come with AppGameKit for more detail (until some tutorials become available).

Hope that helps!
Posted: 3rd Nov 2011 13:01
Baxslash, always extremely helpful as ever! Quick question whilst we are on the subject, I've always used functions instead of subroutines, is there a benefit to subroutines? Or is it just user preference?
Posted: 3rd Nov 2011 13:10
I've always used functions instead of subroutines, is there a benefit to subroutines? Or is it just user preference?

It's mostly preference but there is an advantage to using functions.

Any variables declared in a function are only temporarily kept in memory so you know you have a clean way of doing something without clogging memory up. You can just have the function do what you want and return nothing or a variable result.

The main thing I find is that using functions for everything (something I keep trying not to do!) means you need lots of globals or arrays to pass data into and out of the functions.

The best way to use a function is for a simple task that requires little or no passing of information to / from the function.
Posted: 3rd Nov 2011 13:18
Ok, I see... So perhaps I should change all my functions to subroutines... I have my game structured like this (all functions)...

+ Code Snippet
Level1_Media() // creates the sprites etc necessary for this level

do

Level1_Load() // positions sprites etc for level
Level1_Start() // does the level stuff...

sync()
loop


So I guess you are saying it would make more sense to use subroutines for these? This will be my first game created with AppGameKit so would like to make sure I don't get into the wrong habits already! Thanks!
Posted: 3rd Nov 2011 13:31
There are no hard and fast rules and using functions is fine for loading media as long as you have a system in place for passing the data in / out.

I prefer to use functions for specific tasks like controlling the camera or checking for a collision or getting a distance between two points, that kind of thing and use subroutines for my game loops and menus...

If you find you are using a lot of global variables then switching to subroutines might help. If you store most of your data in arrays then it's not so important as they are global anyway.

I wouldn't worry too much just bear in mind the advantages of both.

Some people prefer to run the whole game in one huge "select / case" routine in the main loop... it's all about what makes sense to you really.
Posted: 3rd Nov 2011 14:01
Thanks Baxslash, I appreciate your insight...
Posted: 3rd Nov 2011 14:55
Glad to help
Posted: 3rd Nov 2011 20:15
I never use subroutines, I allways use functions, and declare the needed variables as globals. Subroutines are soo Commodore 64 / Qbasic, if you ask me
Posted: 3rd Nov 2011 22:20
Well call me old fashioned but I like to choose the right tool for the right job

Actually I'm lying I used to be a blacksmith and one of my favourite motto's was "Every tool is a hammer, except a screwdriver (that's a chisel)"...

I do like to have a separate setup routine and you can't declare UDT's in a function... come to think of it AppGameKit doesn't really like them in subroutines at the moment either!
Posted: 4th Nov 2011 0:19
Yes the UDT thing is annoying, needs to be set at the top of the MAIN file, messing it up... hope they fix that, so I can hide those ugly codes in another function, in another file.
Posted: 4th Nov 2011 10:58
hope they fix that, so I can hide those ugly codes in another function, in another file.

I always thought UDTs were kind of beautiful...compared to some of the other code I've seen anyway.

As for the 'as old as time itself' debate of Subroutines vs Functions I'm one of the guys who always uses functions. It's not that I don't like subroutines it's just their lack of use in other languages. As far as I know, C++ doesn't support them so I only use functions incase I want to convert the code to C++. I'm sure baxslash will find a way to combat that arguement though.
Posted: 4th Nov 2011 11:09
As far as I know, C++ doesn't support them so I only use functions incase I want to convert the code to C++.

That's a fairly valid point.

The easiest way to convert a gosub would be by copying the contents of the routine straight into your code which would be a bit of a fudge.

Using arrays as a way of storing your general data and accessing that through functions would appear to be the best solution.

I'm sure baxslash will find a way to combat that arguement though.

In this case I have to admit that you got me Hodgey! In the interest of making games easier to translate from BASIC to C++ (and probably other platform specific languages) using subroutines would complicate things. Looks like I have some recoding to do...

If you are sticking to making games in basic then subs still have a place (in my humble opinion)...
Posted: 4th Nov 2011 12:13
Looks like I have some recoding to do...

If you're happy with using a tonne of globals it might be ok.

If you are sticking to making games in basic then subs still have a place (in my humble opinion)...

I couldn't agree more.

Oh, to answer the original question (or to add to what baxslash said) it might be worth downloading the free version of DBPro and going though some of its tutorials such as TDK's tutorials. Since AppGameKit and DBPro are so similar it shouldn't be too hard to translate what you learnt in the tutorials to AGK.
Posted: 4th Nov 2011 20:10
I suspect the OP (Original Poster) thought that AppGameKit were a "click and drag" like, game app creator system, not a programming one? Not sure if the nice AppGameKit homepage really explain that part good enaugh for beginners...
Posted: 7th Nov 2011 18:30
I would suggest typing in random stuff tell it works lol. Then keep on adding to the random stuff and get it working tell finally you have something that resembles a game. Maybe all random stuff will do something, but if it does not do what you want, change it tell it does.
Posted: 7th Nov 2011 18:37
Trial and error is definitely part of the process, but to be a good, or even great programmer, you must know why something works the way it does.
Posted: 7th Nov 2011 18:47
Game programming is an art, you can learn it, but if you don't have talent, you might as well go program accounting software instead
Posted: 7th Nov 2011 19:15
Something that I should of done when I was developing my current game is organize bitmap names. Also organize variable names for example. Lets say you have an inventory in your game for equipping items.
One thing I should of done is name the pictures buy there designation of where they need to go instead of weapon 1, ice weapon 1, maybe something like this

weapon1rlc1 -meaning that the sprite, is the first weapon in row one column one.

1st step, organization done right will reduce programming time buy 1/2 I would assume, because I have to keep looking at what pictures are named and what pictures are attached to those names. Since I am highly disorganized for this game I would find it easier the next game to make something faster.

The rest of the step are trivial compared to organization. So when you make a sprite make sure you give it a name you don't have to look up.