Non-AGS game: ShadowBrew

[WHAM]

So I was roped into participating in a 2 week Game Jam. I've just spent 4 days in a row working 15 hours a day to write up the 40 page design document, crunch the project to a finish, all while pestering my teammates to death, but finally it is done!

Felt like sharing, and I hope it's not too badly frowned upon to share a non-AGS game here in the rumpus room:

https://wham.itch.io/shadowbrew

My main takeaway from the project: goodness I love AGS compared to Godot engine! AGS has so many convenient features that I came to miss greatly now that they were gone, and while Godot has its own neat features, most of them feel like they're geared up for making pretty lights and sparkles happen, rather than help you create an interesting game.

[cat]

Looks fun, but I guess I'm too dumb for this, I didn't even manage to get water for my mushrooms.

[Babar]

I bumbled through some of the game, but didn't get very far either 

My main takeaway from the project: goodness I love AGS compared to Godot engine! AGS has so many convenient features that I came to miss greatly now that they were gone, and while Godot has its own neat features, most of them feel like they're geared up for making pretty lights and sparkles happen, rather than help you create an interesting game.

As another AGSer who has downloaded and mucked about in Godot a bit now, I'm interested, could you share more?

[WHAM]

Looks fun, but I guess I'm too dumb for this, I didn't even manage to get water for my mushrooms.

The game page has a small section on how to get started if you scroll down a little. To get going you'll need a glass bottle from the dispenser and then will need to use the nearby water pump to get flowing water, to which you need to drag and drop the empty bottle to turn it into a full one.

The game really needed a better tutorial system to teach people how to play than the text dump at the start, but we simply ran out of time with the 2 week deadline.

I bumbled through some of the game, but didn't get very far either 
As another AGSer who has downloaded and mucked about in Godot a bit now, I'm interested, could you share more?

In AGS I've gotten accustomed to some minor conveniences, like a simple Wait() command, or the ability to natively bind sound files to animation sprites in the animation editor. Blocking animations and scripts in AGS also make it really easy to build small cutscenes and events, making it super easy for a novice programmer such as myself to get going. In Godot the command for pausing a script is relatively long and looks far more arcane and the tutorial I found for binding sounds to frames in an animated sprite object consisted of creating an array that lists the animation frames and sound effects, having the animation fire off a signal each frame to declare what frame it was on and then using a processing function to listen to those signals, compare them to the array and play the sound.

The biggest time loss in our project, one I did not expect at all after so many years with AGS, turned out to be saving and loading the game. While there are numerous tutorials on how to "easily save your game in Godot", we found that our game hadn't been built in a way that any of those worked with properly. Objects and data would get lost, objects would load as duplicates of themselves (loading the game would create new copy of the sun each time, for example). In the end my developer buddy spent two full working days implementing a mostly complete save/load function into the game and even then some things aren't saved, since we have to manually add every single bit of data to the save function to ensure it is not lost. Contrast this to the utter simplicity of the AGS SaveGameSlot() function and someone as simple as myself will find AGS easier to work with every single time. I also developed an intense love for the AGS manual during our project, since compared to Godots equivalent the AGS manual has a ton of useful examples that make it far easier to grasp the syntax of how functions can be used.

What Godot shines in is its easy to use tools for things like creating quick particle effects, complex animations that can be easily visualized, tested and edited in a video editor style timeline tool, built in collision detection and physics for objects, customizable controls for mouse, keyboard and gamepads. It's generally a far more malleable tool that can definitely achieve a lot of things that an AGS developer would struggle with, but achieving those things also requires a LOT more study than I feel AGS ever did to get going.

I also absolutely hate the fact that indenting of code lines is not just a visual thing in Godot, but a functional part of the code, and if your line of code is indented too far right or left the code simply won't compile.

[Crimson Wizard]

I also absolutely hate the fact that indenting of code lines is not just a visual thing in Godot, but a functional part of the code, and if your line of code is indented too far right or left the code simply won't compile.

That's Python rules, Godot Script is made as an expansion / variant of Python.

[WHAM]

That's Python rules, Godot Script is made as an expansion / variant of Python.

That is my understanding as well, and it's driving me nuts!
I learned Turbo Pascal at school, then PHP and Java and a bit of C in my later education and finally AGS, so of course Godot feels weird, being the newest addition to the list.

[Crimson Wizard]

This is interesting to read the opinion on save system. It looks like other game engines do not provide an "out of the box" save system, but that's natural, as engine cannot know what the game's save should include, or which part has to be recreated upon restoring a save.

AGS has a opposite problem, it often saves too much, including things that do not belong to the game progression, or temporary resources that would rather be recreated on game load, in order to not increase the save file size.
(Perhaps not in small games, but in bigger AGS games save files may reach many tens of MBs each, or more, especially if game author does not clean temporary allocated objects when they are no longer needed).

Another problem is upgrading saves (loading saves from the older version of the game), but this is a universal problem, not specific to AGS. In AGS this is coupled with ready save system, which might cause wrong assumptions, and lead to nasty surprises much time later.

I suppose that the principal problem is dividing data into the part that is relevant to the game progress, and the part which is not relevant to that. The easiest example is game interface: main menu, icon bars, and so forth. Normally one would not save the states of these, but AGS cannot distinguish these, and saves altogether. This leads to strange problems: if you save the game by pressing a button in a menu, restoring that save will have that menu open, as its state is saved along. That is why in our templates we have save menu closed prior to running SaveGameSlot command. Alternatively, a game developer has to override "game restored" event and fixup all the opened menus, and such. Which is like reverting a part of the save system's work; which means that it was doing excess work in the first place.