Goat game

[Rev]

:rolling: I'll show it Jeff Minter the next time I see him.

 

 

interesting...

[freewheel]

Snow level is already in the planning stages.

[pimpmaul69]

I didnt realize the kick was added. I wish it only lasted for a second. It seems too easy to get out of a jam.

[freewheel]

I didnt realize the kick was added. I wish it only lasted for a second. It seems too easy to get out of a jam.

 

Been playing with it. It does, but then you'll miss a lot of points. However it sounds like you guys are play-testing way more than I am right now so I may just have to take your advice

 

Not entirely sure how to code in a time limited kick, but I'll poke around.

[+Tarzilla]

Played with it some just now. Turned my speakers on, now I have the tune stuck in my head. Now I have to go listen to Steel Panther or something to get it out!

 

I don't think you should be able to just hold the button down, a kick would play better if you pressed the button, the goat spins (maybe some 3d-ish rotation) executes the kick, then spins back, timing would be a skill to be practiced. As it is now, pressing and holding the button makes you invincible, plus in certain cases, the goat continues walking to the left on the front two legs with the back legs extended. Kicking definitively adds variety to the game play.

[freewheel]

OK. Fun morning. Keep in mind this is not the final implementation, just showing some of the pieces.

 

I've divided the game up in to 4 stages, that correspond to seasons. I'm envisioning the game progresses through each season in order, as you hit a certain number of points or what have you. So far the stages play identically (not yet sure how to mix it up given how the game works, but thinking about it). This is just a graphical update. For right now you can skip to whatever stage you want, to see how it plays. I've made the "bad" objects black so that they're obvious - I realized that with things changing every level, it might get just a bit confusing.

 

People say there are few games with "endings", so I'm thinking of the 4 stages, you play through each of them, and debating a boss fight at the end of some sort (no idea about this yet). Culminating in the resolution of the "story".

 

Curious what people think. Also I'm hitting 15.5KB for the file size, so I need a quick bit of reassurance that I can actually go to 32KB before caring about space (see other thread)

 

 

 

goat.bin

[+nanochess]

Curious what people think. Also I'm hitting 15.5KB for the file size, so I need a quick bit of reassurance that I can actually go to 32KB before caring about space (see other thread)

 

 

Don't worry, keep checking the generated CFG file (it lists the addresses range used) and just insert ASM ORG $D000 and/or ASM ORG $F000 in some strategical points of your IntyBASIC source code.

 

It should read something like:

[mapping]
$0000 - $1EFF = $5000

When the $1EFF exceeds $1FFF then you should insert the ASM ORG directives, a typical "full" game would look like:

[mapping]
$0000 - $1FFF = $5000
$2000 - $2FFF - $D000
$3000 - $3FFF - $F000

[mthompson]

People say there are few games with "endings", so I'm thinking of the 4 stages, you play through each of them, and debating a boss fight at the end of some sort (no idea about this yet). Culminating in the resolution of the "story".

 

Curious what people think.

 

I'm just a casual player, but I'm happy to contribute my impressions if they'll help. I like the 4 seasons/stages idea. It make sense and gives you an interesting way to increase the difficulty. I also really like the addition of the kicking but agree that the goat should turn back around after half a second to make the tactic more of a skill maneuver.

 

Also, maybe I'm missing something or maybe the game hasn't progressed far enough, but is there an advantage in moving forward instead of laying back towards the left edge of the screen to eat the good stuff? I can't tell if the point value increases when I risk moving toward the farmer. Also, when the speed picks up, I can just hang out at the top of the screen and pick up points without moving. Adding the kicking element may have created that situation, but having to better time the kick might correct it.

 

Great seeing how a game evolves. This one looks like it'll be a lot of fun.

[freewheel]

Wow. So, you guys have been clammoring (OK, maybe I'm exaggerating a wee bit) to get the kicking motion be a temporary thing. I've been avoiding it for a couple of days because I thought I had to re-factor a shit-ton of code to implement it. Turns out it was just 3 or 4 lines and a minor adjustment in something. So yeah, here it is. I'm super impressed. I want to continue on other things but I didn't want to get too wrapped up in glitz and show, while the gameplay suffered. Consider this my way of saying thanks for the push

 

Here's the kick. I'm not sure on the duration myself. It was tricky to make it so that after you kick, you can't just kick again instantly (basically holding the button down kept him kicking anyway). So there are 2 things - how long he stays "kicked", and how long after a kick before you can kick again. I'm very interested in feedback on those, both are independently adjustable. And you guys were right, I find it makes the gameplay a fair bit trickier. My hunch right now is that he stays "kicked" a bit too long.

 

Also - the farmer changes color as the difficulty ramps up. What do people think about that? Obviously I'm gonna have to fix some of his colors if I keep it (he'll disappear into the background at times) but I'm wondering if I should just scrap it? Would it be obvious enough that the difficulty is increasing simply by watching the objects move faster?

 

 

goat.bin

[freewheel]

 

Also, maybe I'm missing something or maybe the game hasn't progressed far enough, but is there an advantage in moving forward instead of laying back towards the left edge of the screen to eat the good stuff? I can't tell if the point value increases when I risk moving toward the farmer. Also, when the speed picks up, I can just hang out at the top of the screen and pick up points without moving. Adding the kicking element may have created that situation, but having to better time the kick might correct it.

 

 

There is no score advantage for being closer. To be honest I just tossed the ability in from the start and never thought much about it. I find that when *I* play, I move around the whole field a lot. You can sneak around and get a few more items that way - but yeah, it's certainly not essential.

 

My current thinking is that the harder stages will have some obstacles in the field. For example the winter stage might have large blocks of ice that you cannot move through. It doesn't give you reason to move forward per se, but it at least makes it a bit more interesting/challenging once you have.

 

I haven't thought about this much - what kinds of things *could* be easier/harder by the horizontal movement? Like how could that improve the game?

[+DZ-Jay]

I haven't thought about this much - what kinds of things *could* be easier/harder by the horizontal movement? Like how could that improve the game?

One thing I suggested on my first comment was to have the goat move faster than *most* items, in order to allow the player to catch things he missed.

 

What do you think?

[freewheel]

One thing I suggested on my first comment was to have the goat move faster than *most* items, in order to allow the player to catch things he missed.

 

What do you think?

 

I haven't addressed it for 2 reasons. One, because I'm lazy and it will require a complete re-write of all MOB movement code. Two, because I think it would make the game a bit too easy. Part of the challenge is that you have to pay attention to what's coming down the pipe and plan your movements/positioning accordingly. Missing items, and decreasing your score, is part of the "fun". Combining the two reasons: In case it's not obvious, I'm doing some very simple integer math to move things. At their slowest, they move exactly one pixel for every run of the main game loop - so without making the game glacially slow, I don't see a way of speeding up the goat without making it way faster and therefore just way too easy.

 

But overall I don't really know how easy/hard the game is in an overall sense yet.

[catsfolly]

Just played it for a bit.

 

I like the four seasons. Fall and Winter are the best now - they have a nice look and the objects are fairly easy to identify.

 

In the summer level, I had trouble identifying the objects - do we have a red cell phone receiver, an old white can, and an old tire??

 

The kick is better now, Although it takes a bit of getting used to. It's good that you can't stand there all day and be invincible...

 

I think the objects getting kicked should either explode or fly away. The current version leaves itself open to certain disturbing answers to the question "Where did that hammer go exactly?"...

 

Here's a wacky idea - maybe when you kick back a rock (or hammer or grenade or giant black cheerio), it goes straight back and then takes out a section of the farmer's fence? When the whole fence is gone, the level ends???? Just a thought...

 

(In the past, I have found that many suggestions people give to "improve" your game should just be ignored - either the suggestion is impossible, or would take more time than the results would be worth, or it is just plain a bad idea. On the other hand, some suggestions are great ideas that make all the difference. The trick is figuring out which is which! When in doubt, go with what feels right to you... It's your game...)

 

Catsfolly

[freewheel]

Objects (last one is the harmful object):

 

Spring - shirt, can, fish, rock

Summer - can/bucket, popsicle, wiener, tire

Fall - pumkpin, apple, bone, hammer

Winter - stocking, candycane, yellow snowball, grenade

 

In the tradition of all great 8-bit games, you'd need to check the manual to see what these are supposed to be But yeah, they're subject to change. People have given me some really great ideas already. Certain things are just damned impossible to do (or too much work for too small a benefit) but I'm always open to suggestions with these things. I'm surprised at how difficult some items are to render in an 8x8 monochrome sprite, and yet some things work surprisingly well (VERY pleased with the pumpkin/jack-o-lantern).

 

As far as kicking things back.. the fence isn't really doable although it's a very neat idea. I was debating kicking it back at the farmer - it may be doable but may break other things, so I'm kinda on the fence (ha) about it. I was also thinking it could be used as a temporary power up, to make the goat move faster for a few seconds for example. This would make things extremely "interesting" at higher skill levels when things are moving damned fast already. I just have to make sure I don't mess up the collision detection as a result. For now it's just bonus points. I find that as I play more, trying to kick that damned rock gets more an more risky so it at least adds to the challenge. The reward is huge though, so it's worth it.

 

Anyway, once I flesh out the actual stage progression and decide what score moves you between them, etc, I think it'll be a bit more clear what the "goal" is, as well as what strategies work and whatnot. THEN people will have some very good feedback on a lot of the subtler mechanics.

[freewheel]

Hm. Making the kick animated had.. mixed results. Balancing the speed of the kicking motion with animation doesn't work for my tastes. Right now, the intermediate animation flashes by way too fast to be useful. Extending it to be really visible makes the kick itself way too short. Making both work.. the entire motion is just waaaaay too drawn out and starts to mess with the gameplay. I've left the framework for the idea in, but I just don't see it working without sacrificing on the actual fun. Hell, I still wonder if the kick itself is too long as it is. Maybe this would look good if I dedicated 8 frames of animation to it or something, but that's just WAY too many cards to consider for one animation.

 

Another idea floated to me is to have the goat head-butt the bad stuff instead. Not a bad idea, but I think just the head/shoulders/horns moving would be too subtle. And to be honest, the back-kick is just such a goat thing to do and awesome. The headbutt might make an appearance in a boss fight however, when there's not so much on-screen.

 

On I go...

Edited October 31, 2014 by freeweed

[freewheel]

 

Don't worry, keep checking the generated CFG file (it lists the addresses range used) and just insert ASM ORG $D000 and/or ASM ORG $F000 in some strategical points of your IntyBASIC source code.

 

It should read something like:

[mapping]
$0000 - $1EFF = $5000

When the $1EFF exceeds $1FFF then you should insert the ASM ORG directives, a typical "full" game would look like:

[mapping]
$0000 - $1FFF = $5000
$2000 - $2FFF - $D000
$3000 - $3FFF - $F000

 

I definitely hit the basic ROM limit tonight. Kinda bizarre to watch the game not load at all, after literally one extra line. Just so I understand this:

 

With the mapping above, you get 8K words at $5000, 4K words at $D000, and 4K words at $F000, yeah? For a total of 16K words, or 32KB as measured in 8-bit bytes? And it's just a matter of inserting the appropriate ASM ORG directive at a reasonable spot in the code (ie: not in the middle of a proc)? Is 16K words a limit, or are there other memory areas I can load into without page flipping etc? I'm thinking limits in terms of absolute limits for the hardware/emulators, but also in the commonly available cartridges people are publishing on these days.

 

I can see this being a bit of a juggling act unless one is VERY strict in where they add new routines etc. Easy to fully allocate the first 8K words, work in the next chunk, then go back and add a line or 2 to the first block. BAM! Need to modify the memory map.

 

Let me know if I've completely misunderstood how this works. I can't find the thread where this was recently discussed in depth.

Edited October 31, 2014 by freeweed

[+DZ-Jay]

I haven't addressed it for 2 reasons. One, because I'm lazy and it will require a complete re-write of all MOB movement code. Two, because I think it would make the game a bit too easy. Part of the challenge is that you have to pay attention to what's coming down the pipe and plan your movements/positioning accordingly. Missing items, and decreasing your score, is part of the "fun". Combining the two reasons: In case it's not obvious, I'm doing some very simple integer math to move things. At their slowest, they move exactly one pixel for every run of the main game loop - so without making the game glacially slow, I don't see a way of speeding up the goat without making it way faster and therefore just way too easy.

 

But overall I don't really know how easy/hard the game is in an overall sense yet.

Understood. It was only an idea to give purpose to the lateral move. As it stands, there is no reason to move forwards or backwards, just up and down.

 

Typically, in these kind of games (like Food Fight), the player has free reign over the board and the idea is to catch as many items to score.

 

Obviously, this shouldn't be for all items.

 

About the new kick, I haven't had a chance to test it, since I'm away on holiday right now. In any case, I don't think it needs "animation" per se, just a two frame "legs in the air, legs down" affair.

 

Keep at it! This game is looking better and better.

[catsfolly]

 

I definitely hit the basic ROM limit tonight. Kinda bizarre to watch the game not load at all, after literally one extra line. Just so I understand this:

 

With the mapping above, you get 8K words at $5000, 4K words at $D000, and 4K words at $F000, yeah? For a total of 16K words, or 32KB as measured in 8-bit bytes? And it's just a matter of inserting the appropriate ASM ORG directive at a reasonable spot in the code (ie: not in the middle of a proc)? Is 16K words a limit, or are there other memory areas I can load into without page flipping etc? I'm thinking limits in terms of absolute limits for the hardware/emulators, but also in the commonly available cartridges people are publishing on these days.

 

I can see this being a bit of a juggling act unless one is VERY strict in where they add new routines etc. Easy to fully allocate the first 8K words, work in the next chunk, then go back and add a line or 2 to the first block. BAM! Need to modify the memory map.

 

Let me know if I've completely misunderstood how this works. I can't find the thread where this was recently discussed in depth.

16k words is the limit without additional setup (the code needs to switch out some ecs rom segments so these areas of rom can be used by your program.

From the assembly file cart.mac:

;;      ROMSETUP lets you pick between two memory maps.  The 16K memory     ;;
;;      map corresponds to the historic Mattel 16K-word ROM memory map.     ;;
;;      Games such as Stonix and Space Patrol adhere to this memory map.    ;;
;;                                                                          ;;
;;      That memory map has three ROM segments:                             ;;
;;                                                                          ;;
;;      SEGMENT     RANGE                                                   ;;
;;         0        $5000 - $6FFF                                           ;;
;;         1        $D000 - $DFFF                                           ;;
;;         2        $F000 - $FFFF                                           ;;
;;                                                                          ;;
;;      You can switch between segments using the ROMSEG macro.  This       ;;
;;      makes it easy to put portions of code in each of the three ROM      ;;
;;      segments and make the most use of the available ROM space.          ;;
;;                                                                          ;;
;;      The 42K mapping has six ROM segments:                               ;;
;;                                                                          ;;
;;      SEGMENT     RANGE                                                   ;;
;;         0        $5000 - $6FFF                                           ;;
;;         1        $A000 - $C020                                           ;;
;;         2        $C022 - $FFFF                                           ;;
;;         3        $2000 - $2FFF                                           ;;
;;         4        $7100 - $7FFF                                           ;;
;;         5        $4800 - $4FFF                                           ;;
;;                                                                          ;;
;;      It also contains an additional RAM segment from $8040 - $9EFF.      ;;
;;      This memory map is available on the CC3, the Intellicart, and       ;;
;;      the JLP home brew production cart.                                  ;;
;;                                                                          ;;
;;      Both memory maps insert a ROM header that configures the basics,    ;;
;;      bypasses the EXEC, configures a stack and then jumps to the user    ;;
;;      code.  The 42K map also includes a small stub at $4800 that goes    ;;
;;      and switches out the ECS ROMs at $2xxx, $7xxx and $Exxx, so they    ;;
;;      do not interfere with the user's program. 

Cart.mac functionality isn't currently integrated into Intybasic, so you are limited to the 16k word map unless Nanochess or someone adds this functionality into the prologue.

 

I would recommend putting as many data tables (for title screens, gram definitions, music files, etc) at the "end" of your program, and then use the org statements to move them to the $d000 or $f000 sections. Then you can keep your code in the first section, and hopefully not be constantly running up against memory limits...

[+nanochess]

 

I definitely hit the basic ROM limit tonight. Kinda bizarre to watch the game not load at all, after literally one extra line. Just so I understand this:

 

With the mapping above, you get 8K words at $5000, 4K words at $D000, and 4K words at $F000, yeah? For a total of 16K words, or 32KB as measured in 8-bit bytes? And it's just a matter of inserting the appropriate ASM ORG directive at a reasonable spot in the code (ie: not in the middle of a proc)? Is 16K words a limit, or are there other memory areas I can load into without page flipping etc? I'm thinking limits in terms of absolute limits for the hardware/emulators, but also in the commonly available cartridges people are publishing on these days.

 

I can see this being a bit of a juggling act unless one is VERY strict in where they add new routines etc. Easy to fully allocate the first 8K words, work in the next chunk, then go back and add a line or 2 to the first block. BAM! Need to modify the memory map.

 

Let me know if I've completely misunderstood how this works. I can't find the thread where this was recently discussed in depth.

 

You've understood right

 

Just put code at start and data at the end so you can easily separate into segments, this way you don't need to check everytime.

[+Tarzilla]

 

You've understood right

 

Just put code at start and data at the end so you can easily separate into segments, this way you don't need to check everytime.

What I have been doing is just assuming that I am using all of the 16K or 42K memory map since I don't have some penny-pinching manager telling me I can only have a 4K chip for the cart.

 

 

All my DATA statements are ASM ORG'ed into $5000, $D000 etc.

Currently one of my games is utilizing the 48K map to keep graphics out of the first bank (lots of define statements for different screens) and it is working in JZINTV. Based on the memory map, the game would fail on an ECS equipped system because I haven't added in the ECS bypass code, or I just tell people to unplug the ECS .

 

I really need a Hive and an LTO Flash! As a programmer not being able to test on real hardware is driving me crazy. Plus I'd love to use the extra RAM

SEGMENT RANGE ;;
;; 0 $5000 - $6FFF ;;
;; 1 $D000 - $DFFF ;;
;; 2 $F000 - $FFFF 

[freewheel]

Thanks guys. Pushing data into the higher regions is only the first step. The code itself is rapidly approaching limits (or will soon enough)

 

Discovered that PRINT statements can use 2-300 bytes each, depending on string length. I can almost draw an entire screen with that much! So there's a lot of optimization available to me here.

[intvnut]

 

 

Don't worry, keep checking the generated CFG file (it lists the addresses range used) and just insert ASM ORG $D000 and/or ASM ORG $F000 in some strategical points of your IntyBASIC source code.

 

It should read something like:

[mapping]
$0000 - $1EFF = $5000

When the $1EFF exceeds $1FFF then you should insert the ASM ORG directives, a typical "full" game would look like:

[mapping]
$0000 - $1FFF = $5000
$2000 - $2FFF - $D000
$3000 - $3FFF - $F000

 

You don't even need to stick to that memory map. Mainly, you just need to avoid code at $7000, as that location is special to the EXEC. (It's where the Keyboard Component ROM lives. Later, the ECS took that slot.)

 

If you're really super lazy, just drop an ASM ORG $C100 statement in there instead. If you only need 32K bytes, you can add it just about anywhere, even at the beginning. Anything before that statement will end up at $5000 onward, and everything after that will end up at $C100 onward. From $C100 to $FFFF is 16K words (32K bytes), and $5000 - $6FFF is 8K words (16K bytes). So, you have 24K words (48K bytes) easily available to you with a single statement. If you make it the first line of your program, you still have 16K words (32K bytes) for your program in one big, contiguous chunk.

 

Why $C100 and not $C000 or $C040? ... well, we saw some weird things in that address range. There's a STIC write-only alias at $C000 - $C03F (with a read-sensitive location at $C021), and we saw some odd shenanigans on real hardware with code running near $C040. See here: http://atariage.com/forums/topic/224875-weirdest-intellivision-bug-ive-ever-seen/

[freewheel]

Thank you sir! I was JUST reading your comments on the Tic-Tac-Toe thread and about to ask why the heck I'd be using such a restrictive memory map.

 

Heeeey.. here's a suggestion for the code that writes the cfg files: Right now I get this:

 

[mapping]
$0000 - $1DFF = $5000
$1E00 - $28FF = $C100

 

And I know those of you that are ASM in your sleep instantly know how close to the boundaries my use is. Some of you can add $C100 and ($28FF -$1E00) in your sleep. Well, some of us can't It would be kinda neat to see the memory map actually show the map - ie: $C100-$CBFF. That way I can see how close I'm getting to $FFFF. That, or spit out a reminder of the "safe" sizes for each memory space? Not sure how you'd code THAT in there though, as people could be ORG'ing all over the place.

 

Not sure what else uses the .cfg files, therefore what this would break.

Edited November 2, 2014 by freeweed

[freewheel]

Weekend Update:

 

The game now progresses through each stage as you get to a certain score (for right now it's just 1000 pts). Right now it just says the name of the season - eventually there will be "something" here - animated intermissions, splash screens, not quite sure yet. Once you beat winter, you'll see the ending. Yup, I wrote an ending without the beginning or middle of the story - that comes later. Curious to see if anyone recognizes THIS song; it's the only other goat song in human history apparently. For now you must reset to play again, obviously that will change in the future. Fire buttons replay the ending for testing purposes. Stage select screen left in, again for testing purposes. So you can skip to winter if you wanna see the ending (plus there's an easter egg way of skipping right to the ending).

 

Try getting killed, there's a "game over" screen as well.

 

In terms of gameplay, at this point I'm trying to distinguish the various seasons. Right now, you will lose points if you get hit by the black objects in summer/fall/winter. And in winter, you lose points for not kicking the black object. So eventually it will be a pretty difficult stage to complete (obviously with 1000 pts it's easy, but my thinking is to have the stages cycle around 15-20,000 pts, at which point objects are flying past you and missing the black objects starts to really hurt your score). Oh, and I've mucked about with the graphics/sound for when you successfully kick a black object.

 

It's a bit slap-dash in the way it jumps around; obviously I'm testing (and showing off) the various add-ons. The real game will take more than 3 minutes to complete, I hope. Now at 11K words and counting... very cool how much "stuff" you can cram into these games.

goat.bin

Edited November 2, 2014 by freeweed

[catsfolly]

This version just crashes when I try to run it.

 

I think if you have a nonstandard config you need to give us the config file - or make a .rom file.