RetroFiends

I'm not finding an edit button for my posts, But this is my design document. What I've laid here seems pretty doable. Please excuse my terrible handwriting. The colors are off here, my scanner is old and probably dying. But hopefully you can see where I'm going.

Is two weeks too much? Laughs aside, you've clearly never witnessed a game jam before if two weeks has you disturbed. A few notes: 1. I have other projects and indeed a life as well. 2. The OP clearly states he is not expecting a AAA dev effort by the 15th of may. I feel in those two weeks I can deliver at or beyond his previous experiences, as detailed in the OP. Additionally, theres no reason why it cannot be developed further after the fact. Two weeks will be spent for Godzilla specifically, it will become a fulltime job. 3. I've already PM'd the OP to confirm exactly when he needs it by and I plan to meet that deadline by a week. Sorry if my transparency bothers you. If you would like to, and have the time to, spend more than two weeks for a game done for fun and by request, then I will gladly yield to your own effort. I'm doing this because I like godzilla, nothing more, nothing less. I wouldn't want to get in the way of someone who likes godzilla more than myself.

It's not been worked on yet (at least, not anything worth showing), I have it scheduled for dev last week of april-first week of may. Giving some time to my other (non-atari) projects. I've decided to go with a Rampage style game, because I feel at the core of any godzilla game some buildings should be destroyed...

A jet ski godzilla game would be rad but I'm not so sure I'd want to make that

.tk domains are so scrutinized by google that by using one it's more likely than not you'll have to contact them to remove you from the blacklist just because of the TLD itself. As for anyone who is actually thinking this could be a virus, I won't say it isn't but, as a person with an interest in security I guarantee you the last place I'd want to place a trojan would be a low traffic subforum for developers of 1970/80's software. If it was a trojan, then OP would be the worst skiddie on earth. in the future, OP, to avoid false positives: -Seriously reconsider .tk TLD. -Never upload bare .exe's. You'll notice most people share .MSI files instead for this sort of thing. -If your own website isn't trusted by google for whatever reason (cough, free host or .tk) consider uploading the file to any number of free online services, and if you're black listed, head over to https://www.google.com/webmasters/tools/ and request to be lifted. Other search engines have similar processes. Additionally, If the installer file is so big that it exceeds the original file sizes of the currently available visualbB zip packgages, then chances are your compression is incompetent or otherwise non-existent. Current limit here is what, 10mb? An installer should never exceed the size of the unzipped application held within, as a general rule. Otherwise, you might as well just share a folder. Hey, cut the kid some slack. He's like 12 or something.

I'm not sure if this a joke or not because of the recent flappo bird fiasco, but even if it is... It looks really nice.

Yeah, Right now that second bank in this rom is literally just the title screen (and the statusbar lives mini kernel out of necessity of being in the last bank.) Without the titlescreen, the game fits in 4k effortlessly.

Not so much an issue of "If" but rather "when" I get to the point where I want to translate the project to the supercharger. At the moment I'm at no risk of running out, really. It is merely the massive amount of space the Title Screen takes at this point, and I can easily make one that takes up less space even if it were hi-res (sacrificing name credit comes to mind, a little bit of "squeezing" as well.) Due to the double sided nature of cassette tapes, multiple game modes can be split between side A and B with little inconvenience. I do, however, have one sequence that is horribly inefficient that I might have you look at.

I'm taking it to the streets of Tumblr. God have mercy on my soul.

New Build today. -Removed Vertical and diagonal drift --This has the added benefit of freeing a ton of space, I kept horizontal drift (that never completely stops) because of many shark species tendencies to never stop swimming. Vertical and diagonal drift didn't add much to the game. Along with a small speed boost to the shark the movement feels more 'unique'. -Treasure Spawns now last twice as long. -As a result of a ton of removed code saved for movement, the game is, as far as I'm aware, 100% stable in scan line count. Next Build will likely include the following: -Boat spawning on either end of the screen depending on your location. -Boat's first missile spawning where it's supposed. -Perhaps another Bonus Item similar to the treasure chest but to replenish a larger amount of health. Newest Build is now in first post along with this one for convenience. hungershark.0.2.4.bas.bin Updates to this title will from this point on be more sparse to allocate time spent on other projects due to lack of feedback.

Hello everyone, new build: 0.2.0 Not too many changes in terms of core gameplay. I'm considering that pretty much done, not counting further difficulty and pace balancing, which I'm still all ears for suggestions in that department. Most of the changes here are in terms of bugs, and attempting to keep a stable scanline count (which, this version is almost 100% stable, but occasionally does go a single scanline over. at the very least, there shouldn't be any dramatic screen roll upon certain events like the last one.) Changes: -removed shark flashing as well. A single frame doesn't really add anything. -Moved certain pieces of game logic to only update in certain intervals. At the moment there is a small delay between things like background changes due to level progression or ink, but nothing major. -As far as I'm aware, fixed bugs that could goof up the title screen if the player mashes the fire button immediately after death. There is a small delay between bootup where your input to start the game is allowed via fire button. -Almost stable scanline -removed the boat's ability to shoot down. This is future proofing for when I allow the boat to spawn from the other side of the screen. -Sound related bugs are fixed AFAIK -Game has been downsized to an 8k ROM. Questions for people who play this new build: 1. Is the starting speed of swimmers fine, or does it need to be decreased/increased? 2. Currently, the mine has a chance to spawn at 7 points throughout the level. Is this too much? 3. Should there be more or less delay between when the mine first appears on screen and when it begins to rise? 4. Should the Mine's rising speed be faster? 5. Would you prefer the hunger bar deplete while the mine is rising, or pause like is the case when the boat is on screen? hungershark.0.2.0.bas.bin

Thanks! Not particularly, I just want to make sure when I release my game, that there's not any score bugs. Although I somehow doubt people will get to roll over the score, should they somehow be good enough to do so I don't want to slap them in the face for doing so

Hello everyone. I know this is easily testable, but for the sake of archival and not creating a new project to test, does batari Basic automatically flip the score back to zero upon going over 999999? If not, since you can't compare score values directly, how would you suggest to implement this?

Wow, I'm late to the party but these cartridges are beautiful. I've never seen these kinds of carts before.

Yes, assuming you're willing to actually talk (gross, I know) to small business owners that deal with retro gaming, getting your cartridges available for sale outside the internet isn't exactly difficult, even if it's on a consignment basis. And in that sense, getting the 5 dollar "profit" margin to defray development costs isn't entirely unfeasible if you're patient. I've actually been approached by a couple of shops in my community (and one outside of it) to do this, but getting cartridges made is kind of expensive to consider that right now. Maybe if I had my own eprom burner.

And this is the ultimate nail in the coffin regarding this debate, putting aside all ethics and philosophy. Advertisements in homebrew or really any extremely limited form of media have an entirely negligeable Return On Investment (ROI.) Additionally, the context in which the advertisement sits is also extremely important. This is why successful internet advertising campaigns rely on contextual ads (such as Google Adwords/Adsense.) You can't put an advertizement for Dial Soap or even a Mom and Pop restaurant into an Atari Cartridge and expect even a single person to see and visit that establishment even if your homebrew had a release on the order of 10k sales. If you advertized WITHIN the homebrew community, such as (just an example) an advert saying "Developed with Batari Basic and a Harmony Cart", your effectiveness increases, but this ad isn't something I'd see people paying real money for, but rather a scratching each others backs or a genuine appreciation for a product and not quite an ad in the traditional sense. To be quite frank, traditional Advertizing is THE weakest form of marketing and branding, and the only reason it works with the bigger guys is purely because of the reach of the product or media it's contained in. (Millions of seen ads when going into branding territory, 100s of thousands to push for sales for ROI) It's power in numbers, and the homebrew community does not have those numbers.

I noticed that your directory "C:\Dev\HW\Hello World\bin" has a space in it. Try changing the name of your program and it's directory to helloworld. I don't know why, and it's not consistent, but spaces in sub-directories will cause strange things to happen with compiles.

The way I did it was store the location of levels in a variable. if your x or y hits the boundary, then the variable that holds your current "location" is either +-10 or +-1 depending on where you exit from. Your player's position is then pushed to the opposite side of the screen. Storing the actual rooms themselves is up to you, but you can then use an "on... goto..." statement to use that level variable to tell the program which area needs to be loaded. This of course, assumes that your game "world" is connected. If you have a situation like Legend of Zelda's forest maze puzzle, you'll need to write exceptions into your program.

I don't know if this has been addressed in the newest release (I searched throughout google but found nothing), but when using the titlescreen kernel in conjunction with the statusbar you MUST dim titlescreencolor and set it in the titlescreen loop, otherwise the statusbar will seemingly hijack it before the titlescreen can get to it. At least, is in the case of a bank switched multisprite kernel game.

Yes, I sent a PM, we'll see if I got in before everyone else

That was one of my considerations I was also thinking of something Top down where you destroy buildings and junk, and a 2-p game where you and a friend fight each other with the monsters. The latter most one appealing the most off hand because I've been spoiled with Godzilla: Destroy All Monsters Melee on GameCube.

Just like a month ago I was seriously considering what a godzilla game on 2600 might be like...

Hello AtariBrian, thanks for posting. I removed the total screen flash. I replaced it with a single frame of the shark turning red, and because the effect is so minimal I'm probably just going to remove it outright in the next build. The Score at the title menu does scroll through colors (rainbow effect, think the Atari 7800 boot up logo); if you're epileptic I'm not sure if that could set it off but if such is the case, please be warned. I would be happy to make a seperate build at some point that removes that as well if that can pose an issue.

New Build, first post has been edited with the download (version 0.1.0) and a couple new screenshots have been entered to replace the obsolete ones. Progress has been slower than expected due to having an existential crisis. What's New: -Hunger Bar Darkens as you get hungrier -The people start off faster, and smooth difficulty scaling is now in effect; each level makes them swim just a tad faster (sub pixel movement) -Mines: mines have a random chance to spawn at regular intervals. Touching their centers will kill you. -Removed Background Flash -Your hunger bar depletes faster and (iirc) eating grants less refill. -Boat is now more aggressive and shoots diagonally as well. In a future build I'll try having the boat spawn on the side most opposite of you so you can't just hug the sides of the screen and must actually wade through it. There is still an embarrassing amount of kinks that need to be worked out, and I'm still trying to find a happy balance regarding difficulty. (I am kind of terrible at video games and the easyness of the first build shows.) Please let me know if certain aspects need to be more or less difficult than they are.

I already have some ideas... Are the boards required already available? And on the topic of EPROM Burners, what would you recommend?