Gravity Force DS

[Gonzo]

Hi folks,

I like to introduce my first DSGM project, which is a remake of the already known Amiga Gravity Force. Until now it is about 40% completed: I managed some basics like Map, Camera movement, general ship movement (still need more adaptions), flash lights and a lot of sprites.

Here you can find infos about the origin game:
http://www.mobygames.com/game/amiga/gravity-force

One major problem is, that the sound thrust sounds ugly. It is (re)started in each Step event if up key is pressed. Is there a function to check, if a sound is still playing?

And I have in mind, that PAlib has the ability to show a keyboard. Does someone used it with DSGM before?

Controls
DPad - left/right to rotate ship
DPad - up to fire a bullet
A - thrust

01-27-11
2nd Beta with these changes:
- sound is ok now
- new level with four different enemies
- enhanced ship control with Gravity and Friction (but still not perfect)
- own collision routine
- own Path routine to move enemies along a predefined way
- friendly fire to prevent, that enemies kill themselfs
- status values are beeing refreshed now (score, lives, fuel ...)
- landing is very buggy
- dropping of boxes not supported yet


02-10-11
3rd Beta is ready:
- landing is ok now
- dropping of boxes done
- new main menu (but "Mission" is the only available gamemode)
- hi-score
- keyboard support to type-in password or hi-score name
- Savegame via FAT
- rebased to DSGM 5.12
- still only two levels (prepare for more...)


03-15-11
4th Beta:
- finally, I'm happy with ship control
- own font
- Misson has 10 levels now (including two types of bonus boxes)
- new game mode Race with 10 Levels
- bugfix in save game

[YoshiInAVoid]

Very nice.

Will oyu add in gravity or friction or will he keep moving for ever?

[Gonzo]

I want to have the game feeling as near to the Origin as possible and yes, gravity and friction are done (but currently disabled). Do you have any suggestions to my problems?

[gamebox]

Odd... the score and fuel are always at the maximum... and when you touch somthing it just plays a sound efect.

But! the improvment of it was a lot better! but why did you make so many frames for the ship when you could have just used rotation?

Oh. And could you add "how to play" to the main menu?

[James]

Do you have any suggestions to my problems?

I'm working on it.

[James]

Alright Gonzo - get 5.11 and you can do it.

The function Is_Sound_Playing() returns true if there's a sound playing. That will let you do what you need.

[Gonzo]

Thank you very much James. I'll check it.

Edit: yes, now it's better. But this is a global solution affecting all sounds.

[Gonzo]

Greetings,

the first post is updated.

[pichubolt090]

Love this!

[lucky]

Very impressive work Gonzo!!
And in fact really addictive to play.
I have some questions ...
Whats the deal with the files ActionWorks.h and GameWorks.h
Are they some system files, part of the DSGM and if so way have you changed yours?

I was surprised to see function definitions i a .h file , is this good C or a little dirty way to work in DSGM.

Lets say I want do write a function that access some PA lib functions, should a put it in a .h file or should I put it in a script inside DSGM, whats your philosophy regarding this when you make your games?.

[Thungbard]

I'd say overall, if possible it's best to edit the .h files as little as possible, here's my reasons:

- If you ever decide to share the source of something with others, they'd have to also edit their header files to reproduce errors you're having trouble diagnosing, etc. whereas with a script any strange code you use is stuck to your .DSGM file

- After a while your header files are going to be polluted with an excessive amount of useless functions that you have no real use for if you keep adding to it whenever you need something for a particular game you're making at the time. Unless you're making functions that you intend to use for lots of different games it doesn't make any sense to keep altering the header files to add one time use functions.

- If there is a function of some sort that you do plan on using in every game you make, you're better off creating a custom action for it in my opinion, or if it's too complex a loadable script.

[Gonzo]

Whats the deal with the files ActionWorks.h and GameWorks.h
Are they some system files, part of the DSGM and if so why have you changed yours?

I was surprised to see function definitions i a .h file , is this good C or a little dirty way to work in DSGM.

Lets say I want do write a function that access some PA lib functions, should a put it in a .h file or should I put it in a script inside DSGM, whats your philosophy regarding this when you make your games?.

Thanks for your approval lucky,

I patched the "ActionWorks.h", because there is no fixed point movement for objects out-of-the-box and it was the simplest solution for me. Normally you should avoid that, because it is a generated file which probably change on the next DSGM version.
If you want to create new functions, then scripts inside DSGM is your fist choice. But this becomes impossible, if you want to use self-defined types like structs or pointers as arguments. That's why I declared some special functions in my own "global.h"...

BTW: I updated my first post.

[lucky]

Ok I understand.
Is it so that your own added .h files (in your example global.h) are merged with ActionsWorks.h when you have compiled. When I have done something wrong in my added -h the compiler reports error in ActionWorks.h.

/lucky

[Gonzo]

No, if you add a header file example.h to the project (via GUI Tools > Game Settings > Coding), then DSGM will add an include rule #include "example.h" to GameWorks.h. And if you have any failures in the file, the compiler reports them as example.h failures (as he should).

If you add a new function via GUI scripts, then Compiler locate failures in GameWorks.h. This behaviour is normal, because all scripts are copied (and translated if they are in DBAS form) to GameWorks.h.

[lucky]

Ok I remember now the errors appeared in GameWorks.h

Correct me if I'm wrong but is it like this that all the actions that you are able to do in DSGM are in fact defined in ActionsWorks.h and ActionsWorks.h is just a wrapper to PA lib or have I missed some steps.
(I'm currently at work and can't studdy this my self on my computer)

And Gonzo, thank you for taken time to answer my questions!

[Gonzo]

And Gonzo, thank you for taken time to answer my questions!

No problem, I'm at work too and mostly have to wait on the compiler

In fact, all the action code is located as text inside the DSGM executable and if you open a project, the source code files are beeing created. Where ActionWorks.h is not affected by any part of your project, but the other files like main.c, Defines.h and GameWorks.h.

And yes, the actions are either direct calls to PA_ functions or self-written sources to enhance the PAlib.

[Gonzo]

HI,

I'm back after a longer break, bringing the 4th beta. Most of the problems are solved, except Nifi. This network stuff make me sick. On my first trys I saw, that there is a lot of straying data in the air, so I implemented a statemachine with ID handshake to ignore all unwanted stuff. And ofter that, I usually get a buffer overflow, if I try to receive some data with a paket size of >400 bytes...

Does someone have a working project, transfering more, than just text messages?
And why do we need to send an u16 on each u8 data?