"Game with one control key" challenge(CLOSED!)

[Lachie Dazdarian]

Artillery comment(to red_Marvin):
Liked the code. Saw some stuff I didn't know before. Like how to define
the irregular terrain. All in all I liked how you packed it all up.
Like the *drumdoil* thingie. He,he. What I disliked is that you
cramped a complicated game control system into one control key. I mean,
I never would start this kind of game with one control key restriction.
For my entrie I did had an idea about player controling a gun or
catapult but he would only have an ability to control the velocity while
the angle is fixed. While you hold the key velocity raises and when you
release it you shoot. Constantly wind would change while the player would
have to kill hordes of stooges running toward the gun/catpult. Maybe
he would have to, in the same time, let certain type of stooges to
pass.

So the biggest problem of you entrie is that player can't speed
up the slow pace of the game. Continue, I would like to see the RelLib
version but don't expect to have a chance against fast paced entries.

Cha0s: I'll simplify it. Usage of mouse for in-game control is NOT allowed. I've updated the rules. Also the deadline is now
prolonged until 25th of this month. You can join whenever you want. I mean all you need to do is to finish your entrie before the deadline and submitt it.

Worked on my entrie this weekend, of course. Didn't worked on it as much
I expected to since I'm doing this rotation disc stress calculation for
the second weekend now. I finished it this weekend and when I saw how
my stress diagrams were garbled I knew I made a mistake. Found it
and re-corected part of the calculation. So I'm still not finished
with it. I hate engineering.

Anyway, about my entrie. Finished the main menu image which turned out
to be very niffty. Maybe too niffty for a mini game. Basicly finished the
in-game routines. All types of player's death and some special routines
related to the end of each level are finished. It works nice. Finished
almost all sprites/tiles for level 2. My inabilty to draw a crocodile
forced me to implement giant snakes in the game.
Did some work for the level 3 graphic which most people will find
to be a big suprise. That is, if I find time to implement it. Now
I must input all the data for hazards appearing in each level. Since
levels are quite long while narrow that's a tedious and time consuming
work. It turned out to be very hard to tweek boat to hazards collision
properly but I don't think I can do much there. First of all game is
side-top view so RelLib sprite collision routine won't work. Second,
it's hard to implement that routine on the collison of objects with
changeing sprites(animated objects).

I hope to finish my entrie next weekend, which will be a 3 day long
weekend for me.

So, what about you? C'mon people give me some details! If mean if you don't want to reveal much about your entrie just post some progress information.

[Phydaux]

I really like this challenge, I've been trying to think about a game I could code with just one key for ages, and have had many other ideas come about, so thanks

The hardest thing is thinking of a game that wouldn't be any better with multiple keys, otherwise the game would just feel restricted.

I've come up with a really simple idea, that should only take a few days to code. It's a puzzle game, kinda. Hopefully I'll be able to make it 1up, 1up vs 2up, and co-operative.

I won't be sending it in till the last week-end 'cos I'm always tweaking my code (I don't have any 100% finished projects). So you'll just have to wait to find out what it is.

[red_Marvin]

Well, for the input system, the one in the rellib verision is much
more easy to use, but I'm thinking of a new worms-like
type where you see a crosshair at the appropirate angle out
of your tank, and the angle is going back and forth until you
press space and the the velocity is determined by how long you
hold the spacebar down...

Hm. out of memory problem, can it be that
n& goes to far too big in the delay function?


EDIT:: I tested it both with the IDE and EXE in XP (2.6GHz)
so It's probably not that... Hm... How much memory
do you enable? I'm not any computer wiz really, so it would
be good if you could post suggestions...

EDIT 2::Tested again and now the EXE runs way to fast where it
has to do with the delay function but normal else :\

EDIT 3:: I just realized I left some "debug" code in the
displayendmsg sub and that you will always get the message
"DRAW GAME" at the end of the game

[red_Marvin]

Double post, I know, but I want to keep you informed

I have now coded a new aiming routine: (more worms-like)
A crosshair is shown out of the appropirate angle from the tank
and the angle goaes back and forth from 0 to 180 till you
press space, then a bar shows the velocity and when you
have reached the desired velocity you release the space bar...
This is a faster and easier (the angle and velocity is shown
graphical instead of in figures) way of input which makes
the game approx. 42 times as fast-paced...
I also have fixed a bug...
BUT I will not post it here yet since I want to look closer at the
delay problem...

I think I know the solution to the "subscript out of range" error:
Does the error occur while generating the terrain?
If so then try going into the options menu and press space at the
Terrain type: tile" so it changes to "terrain: type single color"
Try to start a new game, does it work?
If yes, then copy the 64.put to your pp256 images directory
and try to open it in pp256 (you need pp256)
For me it says "bad file mode"
Does it the same for you then I probably my standard terrain
texture file is probably corrupt...

Edit:: Excuse my bad spelling, it's late and I shall go to bed NOW!

[Lachie Dazdarian]

I like the changes you desided implement n the game.

For the delay, why don't you use the TIMER? I mean you can get the maximum of 18 FPS but that's OK since you are not makeing a space shooter with fluent graphic for which you need like 25-30 FPS.

You can get "subscript out of range" error if you for example, load a PUT file which has 9 sprites but somewhere in the code you use a RelSprite statement with a sprite number 10 which isn't there.
Also, when you've once saved your PUT file it shouldn't be corrupted. Unless you write stuff over it with QB programm but I don't know why and how you might have done that. Check your code. Don't write stuff on your PUT file outside PP256.

[red_Marvin]

The only functions directly using the .put file is "initimagedata" and
makeimageindex :/ and they shouldn't contain any bugs I think...
But the things in my above post did happen...


About the delay: You mean delete the calcdelay sub and change
the delay sub to somerthing like:

Code:

SUB delay (t!)
  starttime!=TIMER
  DO:LOOP UNTIL TIMER>=starttime!+t!
END SUB

Is that what you mean?
Well I think the projectile would go too slow then...
Hm, I could always make the projectile move further in on loop iteration
tha before... (loop iteration might be bad english)

But back to topic: Would this make the game more XP friendly?


The above function doesn't work, It's WAY to slow

[Lachie Dazdarian]

t! must be 0.04 if you want to get 18 FPS. You can modify your game easily so that projectiles fly with reasonible speeds. Multiply some values in your projectile formulae.

I really have to see your code to know the exact problem. This is basicly shooting fish.

[red_Marvin]

Do you mean a timer routine waiting 0.04 scs is too slow, I tested,
and it got slow or I had to change the movement steps and it got
too blocky...

Latest verision here: http://www.freewebs.com/red_marvin/v03.zip
If it won't work, go to my site and download it from there...

[Lachie Dazdarian]

Downloaded it. Don't know when I'll be able to check it though.

[red_Marvin]

How would you like these functions implemented?:

Fog of war

Teaming