itch.io

Brilliant!

Thanks for the vote.

Awesome!  I hope to get back to this game's todo list this weekend... but don't hold your breath on that.  Things are busy right now.

Thanks for the vote.  Every vote makes a difference on how I feel about this.  There are days when I wake up with an urge to work on this or my 2600 game... but I've learned to moderate myself and obey the todo list (mostly), else I tend to finish nothing.  With Atari's own renewed interest in their old systems, this is probably a bit higher on the todo list than it was.

Hello.  Thanks for checking my game out.  Mostly, it is made from scratch.  I do, however, always steal bits from tutorials here and there.  It's just the smart way to work.  I've been programming for so long now, I often use tutorials for one engine and just make it work in another engine.  The principals are usually the same.

Anyhow, for this game, unfortunately, I can't point you to much.  To learn Godot (after learning a few other game engines first), I just used the standard "Dodge the Creeps" tutorial here: https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html

I did spend some time looking at the Lua code in this "Succer" game: https://www.lexaloffle.com/bbs/?tid=2614 .  (Pico-8 games have their Lua code embedded in the "cartridge" PNG files.)  It helped a bit, but I can't say my code or game structure looks anything like that.  Pico-8 is a very different animal to write for -- it's more about keeping it minimal rather than writing smart.

Mostly, however, Sendit Soccer is about developing new browser-based multiplayer tech, and that is all me.  I've used some tutorials to help that along as well... but that's getting way beyond just learning Godot.  Anyway, I hope to get back to this game in a few months to make it much more interesting (but gots to earn some cash first).  It appears to be my most popular game yet and deserves more attention from me (not to mention what else I might build with this web tech once I make it more robust).

Awesome!  Thanks for chiming in.  That's one.  49...ish to go.  (Oh, and I think I still need to fix the escort mode first to make it winnable.)

I believe I do.

Thanks!  And, thank you for pointing that out.  I had the language correct in releases 1-3; then, it looks like I got lazy with cut/paste (with English and German) when I changed the text in R4.  I just now fixed it for R5... if there ever is an R5.  Or, maybe I'll package and ship R4 again if I find the time.

Yup.  Considered it.  There are some reasons why I didn't jump at that with this release.  Perhaps not very good reasons.  But reasons.

Hah, "rant" is indeed the correct word.  I hope, at least, that when I rant, I rant constructively (or fun).  To counter my own criticism of Phaser docs a bit, when I was deep in it, I found a startup doc project that was pretty helpful: https://rexrainbow.github.io/phaser3-rex-notes/docs/site/.  It did a much better job of sorting out all the config-object/setter-methods/helper-methods/properties confusion and showing only what you need to know to get something done.  On the other hand, it was also (understandably) focused on so many next-version features it was often misleading.  It could use some version tagging and/or filtering as it evolves.  Thus, I spent a lot of time flipping between it, the official docs, and the examples site.

The one thing I liked about Phaser was its arcade "physics" and how it helped get arcadie movement and collisions up and running quickly(ish).  On the other hand, it just might have been the inconsistent ordering of arguments in the physics function calls that broke the camel's back here (but was probably the inconsistent use of `update()` across objects).

So, yes, "despite the trouble, Godot is the new goto."  My note of caution here is keep in mind that open source may never catch up to some of the commercial products.  Some things in Godot will likely never be as easy to rig up as in Unity and the others (and we both know Unity ain't exactly wonderful to use either).  Particularly in the 3D realm, I hear.  Although, 3.4 made significant improvements there, I also hear.  Simply put, you have to be willing to do more lifting in Godot.  You have to want it more.  A weird statement considering many find it easier than Unity to get started in.  Godot gets naughty quickly when you start reaching for the stars.

As to engineering, I found it more similar to Unity than dissimilar.  Yes, the lingo is weird/unhelpful and throws you off but, really, a "game object" in Unity is loosely a "node" in Godot (game objects and components cross over with scenes and nodes), a "prefab" in Unity is a "scene" in Godot, and a "scene" in Unity is the abstract "owner" scene in Godot (I guess).  Godot appears to be heavily hierarchy oriented, but I found it to be no more or less so than Unity when it comes down to it.  In short, I found the component system to be similar to Unity and found myself making many of the same kinds of decisions as to whether to build something up in the GUI editor or in code.  I lean heavily towards the code side but still split it here and there.  Some tools are very odd and need to be looked up to get.  I found the animation tool onerous for busy sprite sheets and redid those in code instead (with no help from the docs when it comes to exemplifying code workarounds).  Stuff like that pops up here and there.  Also, there is something very wrong with how scenes/nodes and node classes are wired to each other.  I'm not enough of a language engineer to describe what it is, it just doesn't quite grok with me.  It feels wrong, for example, that instancing a scene does not run the _init() constructor in attached classes -- that only a new copy of a class made from code will init it.  I get the data differences, but the diff feels not tangible enough and, thus, unnecessarily confusing.

And, just to throw another wrench into the conversation, Unity would still be the right choice for my other game, GRITS Racing.  The 2D physics in Godot is too simple compared to Box2D, and Godot's package library (while pretty okay) can't yet compete with the pro quality of some Unity packages.  There are some Box2D plugins to Godot but, like I said before, you've got to want them more to use them (I say to someone who writes his own physics regardless).  Some of the other packages I use in GRITS Racing have no replacement in Godot.  But... I'm ready to leave much of that behind in many of my planned projects.

I'm not sure if you're calling River Raid the possible greatest Atari game ever... or River Raid Squadron.  If it is Squadron, I thank you and I'm flattered; I'm pretty happy with it.  If not, well, yeah, that's why I tinkered with it hoping some greatness might rub off on me.  Either way, most of the credit goes to Carol Shaw.  Personally, I might vote for a few others ahead of River Raid, but this is up there.  I think a proper port of Gauntlet I and II to the Lynx could have been a major hit.  If I had time, I would do that myself.

Aside from getting the 32-bit architecture working (which is built into flavors like Mint), I believe you shouldn't have trouble running this on Ubuntu 20.04 on the VCS.  Let me know.  You'll need to find an older controller though, or use a tool to fake it (or, if you are really ambitious, hack the Atari controller SDL2 info into the RRS binary -- something I might do myself).

As far as the VCS OS goes (if we ever get there), I'm guessing that 32-bit arch on it will not be attainable (unless I can maybe include the whole 32-bit env in the distro).  I've been thinking about how to get this onto the VCS since I ported it, but haven't decided on a path yet.  Don't want to buy GM:S 2 just for the 64-bit library.  Might port it to yet another engine.  Might finish the 7800 work (not looking likely) and wait for a VCS 7800 emu.

Yeah, I can't say I'm impressed with the VCS...... yet.  I consider it to still be in early-access so I'm giving it a bit more time.  Dual booting is fine, but I'm pretty disappointed we all can't sideload anything yet.  Not just devs, everybody.  I think everybody should be able to sideload a copy of River Raid Squadron if I build it for the VCS.  I thought sideloading was a stated goal up front.  We'll see.

The new controls are in.

Awesome!  I hope you still like it if I change up the bending controls a bit.

I discord once in a while.

Wow, that is really weird.  You should only see that message if two players used the same player nickname "Fjubiekl54juw3akrfm".  That is not likely.

The room features are very new and basic.  They will get better over time.  I see some things to fix, but they are different problems.

Some older browsers can play the game and do WebRTC, but cannot connect without Trickle ICE.  I need to fix this too.

I'll keep looking for the problem to fix it.

That's great, Sipper, I hadn't thought of it like that.  I can't wait to add more features and animations, and see if you and your friends like it.

Sendit Soccer

Intended for online soccer pickup games with friends while you are stuck in your house.

This a free, browser-based, peer-to-peer, association football game influenced by Sensible Soccer -- but for multi-play!

Currently, this is version 0.1.0, so you won't find a whole lot of features or polish yet.  Releasing early to test multiplayer networking and mechanics.  Go and bang on it a bit... and then send it to a friend.  Looking for feedback to help me tune it, and any other support or encouragement I can get.

It's also here on itch: https://yellowafterlife.itch.io/spelunky-sd

The Linux version works great!  This awesome mod still runs fine with the right libraries included.  The easiest way to get those lib files is to download River Raid Squadron.  Then, replace the RRS game files with those from this game, and edit and rename the rrs script to launch this game instead.  RRS and more details here: https://juanitogan.itch.io/river-raid-squadron/devlog/175520/linux-32-bit-game-o...

Judging by the absolute silence here, there is clearly virtually no interest in seeing this game run on the Atari 7800.  There was some minor interest on the AtariAge board before one of their rampant village idiots showed up and killed the conversation.  Apparently, he didn't like the idea of me prototyping the art and gameplay on PCs instead of on an Atari.  Not surprising from that community really.  I stay away from AtariAge as much as possible even though I'm a big Atari fan.  There are some excellent people there, but they also have a pretty high percentage of trolls and jerks (and maybe I'm one of those jerks).  If they don't want me making games for Ataris, I can live with that.  It doesn't mean I won't -- it's just far less likely I will if there's no audience for it.

Anyhow, I'm bumping the Atari 7800 work down to a low priority on my todo list until 50 or so people tell me otherwise.  I will probably revisit this prototype work on occasion to test various ideas and/or spinoffs, but I will be spending most of my time on games with higher levels of interest.

Interesting and well done.

1. This a remote jam, so figure out your file-sharing strategy beforehand, if you can.  Whether it be Discord drops or some sort of SCM like git.  And test it, test it, test it!
2. Like #1, if you have a pretty good idea of what tools you are going to use, install them and test.  Run through some demos.  Gather some skeleton code.  You don't want to burn several hours (or the whole jam) doing this at the start of the jam.
3. Get some assets built and/or code written before going home on the first night.  I see some teams hit the ground running, but I see others only do planning on the first night.  Planning is great... but, personally, I'd rather start the second day feeling I'm already in the middle of a project instead of trying to find our start-up momentum.

Please leave a short (or long) comment if you want to see me port this to the 7800.

The art assets are ready.  I have the core from the 2600 that I know really well by now.  It is now a matter of deciding of whether or not it is worth putting it all together after I finish prototyping on PCs.  If you like that idea, tell me.

See my reply to the parent post for running this.

The "official" solution would be to install everything listed here: https://help.yoyogames.com/hc/en-us/articles/216754458-Setup-Ubuntu-And-GameMake...

But, that's overkill and could install some lib versions that don't work either.

The easiest solution is to download the game where I just solved all of these issues (libcrypto is just the tip), River Raid Squadron.  Copy it's lib folder and launch script (rrs), and edit that script to start this game instead.  I just tested that process with Xenia and it works.

https://juanitogan.itch.io/river-raid-squadron

If you are missing some common 32-bit libs, you will also need to read this:

https://juanitogan.itch.io/river-raid-squadron/devlog/175520/linux-32-bit-game-o...

If you want the full gory story of how I solved this and how to make your own lib folder, I blogged it here:

https://namethattech.wordpress.com/2020/09/04/from-gamemaker-to-ubuntu-14-16-18-...

I might like an option to choose how many seconds to loop.

Nice work.  No coyote time on the jumps... but, considering the jet pack, maybe it doesn't need any.  Should be a good game after more level tuning.  Level 1 is a bit long and dull and maybe level 2 as well.

Why can't I just set the music to none?

A bit difficult to understand at first. I didn't know there were more instruction cards to scroll through before pressing A to start. Need arrows to show this, not just 1/8 etc. "Tutorial" indicates instructions during play, otherwise call it "Instructions." Cannot turn off help if opening it in game. Move instruction slide 2 to 8, 3 to 7 (or delete it). All this will help noobs into the game.

Does this play correctly on the emulators?  I'm not finding a game here.  Just empty levels to jump around in.

6 seconds is a brutally hard ramp to get past. I liked the concept but found I didn't have the patience to adapt to the controls to get anywhere with it.

Fair answer to the question.  I'm amused you answered it.  Thanks for looking.

You raise a fair point that I should list the relevant controls.  Done.  (PageUp/Q and PageDn/W are listed as prev and next page -- and can only guess that is in case a menu or dialog runs over to the point that arrows keys aren't enough -- which doesn't happen in Dig.)  Yeah, I'm more interested in writing the game then peaking under the hood of the game engine.  (And, as you know, the last time I did that I ended up rewrite the engine [now, Pogo Game Engine]... so, probably best not to go there again... especially during a game jam.)  But, I was wondering why the Mac build was twice the size of Windows.  Windows doesn't use NW.js but has a nw.dll instead.  Looks like a cop out on the Mac.

RMMV does have a build option to not include unused assets, but it's not very good at it.  Probably because the default rigging references a lot of assets and I would need extra time to go clean all that out (or just whack the asset files I don't recognize).  Not a high priority in a game jam.

I am amused by the meta situation that because Dig wasn't deep enough for you yet, you found another way to dig deeper.

Yeah, Donald is fun and an easy personality to write for (plenty of source material there).  And, yes, Danny is the main character you interact with, and the one that moves the story along.  He sends you off on small errands or tasks to do.  The current content ends just before the first of those.

Anyhow, this was a test of working with long-form and branching dialog in RMMV -- neither of which it does very well.  I spent the first 16 hours testing map sizes, trying to figure out how to make large holes in the terrain (not easy -- the rocks around the oasis is a side effect of that), playing with the character generator, loading plugins for richer text and whatnot, and stress testing the dialog system, etc.  Thus, that left only about an hour of content writing with a difficult dialog tool.

But... as mentioned before, it did inspire me to then write my own dialog parser in JS where I can write an entire branching conversation into a single string with very simple markup for branching and avatar expression.  I even wrote a syntax hiliter for it.  Thus, I should be able to get much further much quicker next time.

The macos version has been fixed.  The difficulty of cranking out dialog in RPG Maker in this test inspired me to later write my own dialog tool for RPG Maker.  I use it in another game I have yet to release.  But, should I bother, it should make finishing this story much easier.

Thank you for the report.  As I recall, the macos build was just a hail-mary test of RPG Maker MV's mac export.  Given the obvious +x problem, I surely didn't test it during the game jam and never found time to come back to it.  I'll see if I can build from my second-hand mac mini and see where that goes.  Or, maybe just go for HTML5.  Don't recall why I didn't.

For all the people who aren't reading this, a Linux build was just published.  You can find the devlog on this here:

https://muddydesert.itch.io/gritsracing/devlog/110316/linux-build-released

I can't say I knew it for sure either... but it's been in the back of my head for a long time.  Then the AI agents forced the issue and, voila, we have banked turns of various stepped degrees!

Oh, yes, the demo was released on Steam last Thursday, Jan 31.

https://store.steampowered.com/app/907190/GRITS_Racing/

Is anyone interested in a Linux build of this game?  While we intend to eventually publish a Linux build of this game, it's not very high on our priority list at the moment.  We currently don't have a Linux test platform but, yes, it wouldn't be terribly hard to create one either.

Regardless, I wanted to put this question out there in case there is enough interest to persuade us to move this up to a higher priority.

Yup, it was this month... on itch.io anyway.  Still working on the Steam release.

Well, obviously it wasn't that month.  Maybe this month.