Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

rancidbacon

21
Posts
6
Topics
3
Followers
A member registered Nov 21, 2018 · View creator page →

Creator of

Recent community posts

Neat, just had a quick look, looks like you're making some good progress!

The pseudo-3D "tilt" of the ship is a cool addition.
In https://intrepidhero.itch.io/space-jam/devlog/290870/custom-drawing you mention an weirdness with PolyLine line width, you might want to check out the related known issues, of which there seem to be a couple: https://github.com/godotengine/godot/search?q=polyline&type=issues (e.g. https://github.com/godotengine/godot/issues/16466)

(9 edits)

In my experience Godot's UI system can be both extremely powerful but at times also extremely frustrating--especially when starting out. The primary reasons for the frustrating part are:

  • The system relies on multiple concepts working together & it's not always obvious (conceptually) how they impact each other.
  • The UI doesn't always provide an intuitive way to configure the various aspects. (e.g. flags that are mutually exclusive in effect but can still be enabled at the same time in the UI.)
  • Some UI controls (especially less commonly used ones) can be quite buggy.

Suggested starting UI Node layout

My recommendation for a starting point is to create your UI with the following node setup:

  • `MarginContainer` (Use the "Layout" button on the toolbar below the scene tabs to select "Full Rect". Set the margin sizes with the properties under the "Custom Constants" section *not* the, err, "Margin" section. Leave the "Size Flags" for both "Horizontal" & "Vertical" on "Fill".)
    • `VBoxContainer` (Leave the "Size Flags" for both "Horizontal" & "Vertical" on "Fill".)
      • `VBoxContainer` (Leave the "Size Flags" for both "Horizontal" & "Vertical" on "Fill". Have one of these per "vertical sub-section" (i.e. a subsection that spans the entire width of the screen) of UI, so you might want to have a "header" & "footer", so you'll want two `VBoxContainer` nodes at this level.)
        • `HBoxContainer` is probably what you want at this level which allows you to place controls next to each other horizontally.
          • Your `Button`s, `Label`s, `LineEdit`s etc controls go at this level.
        • (Maybe) `HBoxContainer` etc.
      • `VBoxContainer` (This would be for the "footer" part of the UI.)
        • `HBoxContainer` etc etc
      • (etc)

Let's say you then wanted the "footer" section to really stretch all the way from the "natural height" (my term) of the components, all the way to the bottom of the window, in this case you would change the "Size Flags" as follows:

  • "Size Flag" > "Vertical"
    • (Keep enabled) "Fill"
    • (Newly enable) "Expand" (this "theoretically" stretches the area of the "footer" `VBoxContainer` to the bottom of the screen *but* this is only visible if "Fill" flag is *also* enabled. But read on...)

But what you *probably*/may want is for the UI controls in the footer to *also* be at the bottom of the screen--not just the enclosing container. In which case, you want:

  • "Size Flag" > "Vertical"
    • (Newly disabled) "Fill"
    • (Newly enable) "Expand"
    • (Newly enable) "Shrink End" (Or "Shrink Center" if you want it vertically centered.)

So, essentially, "Fill" on its own sort of means "Shrink Beginning".

But, it's essential to realise that "Expand" can only expand if its parent container (in this case the `VBoxContainer` immediate under the `MarginContainer`) has extra space for the child to expand into--so that means e.g. "Fill" is also set on it and its parent also has space to expand into (which the `MarginContainer` does because we forced its anchors to be at the four extreme corners of the screen.

Yeah, it gets confusing and text isn't the greatest way to communicate these nuances. :) (And I may not have this 100%. :D )

My recommendation for getting an understanding of this would be to start with just the `MarginContainer` and its child `VBoxContainer` and play with the "Size Flags" one at a time to try to understand what effect each one has.

Other UI Control aspects to consider

The "Stretch Ratio" enables you to have split an area into a different ratio for e.g. two controls. By default when "Expand" is enabled two controls will split the area available in two (i.e. half each a.k.a 50% each a.k.a. a ratio of 1:1) and three controls will split into thirds etc. But if you want one control to be "greedy" then set its "Stretch Ratio" to say, 3 or 4 or 10 to force the other control(s) to take up less room.

Most Containers manage their size in such a way that you don't have to think about it too much. But in certain situations, with certain Containers, you might find that a particular Container gets "squashed" and its child controls become invisible. In this case you may need to provide a value for "Min Size" in the "Rect" section.

Grid-like Containers

In my experience, if you want a "grid" of UI controls, at first it is best to:

  • Avoid the `GridContainer` control.
  • Avoid the `ItemList` control.
  • Avoid the `Tree` control.
  • And, if you must, try something like a `VBoxContainer` containing `HBoxContainer`s.

Yeah, it's not very satisfactory... :/

So, if you must, still skip `GridContainer` & `ItemList` and go directly to `Tree` control but if you want to use keyboard for movement, be aware it is very very very broken! (Which brings with it major accessibility issues.)

Thus I recommend looking at the code in this related Godot Tree control issue comment and consider adapting the workaround for your own code and/or read the overview of issues discussed in the issue.

Conclusion

Despite the frustration I've experienced with Godot's UI controls/containers along the way, I do think Godot's UI system is powerful vs (theoretical) effort required and has the potential to be a very compelling part of Godot--but one which currently has a lot of unnecessary confusion occurring while learning it due to UI/UX, bug & documentation issues.

I recommend you stick with `MarginContainer`, `VBoxContainer` & `HBoxContainer`, the standard UI controls like `Button` & `Label` and take a bit of time to understand the effect of the different "Size Flags" (and you generally want to set them for the parent container first & work down the node tree) and you'll hopefully get it working enough for your purpose of a 2-day jam game. :)

Hope this helps you on your journey!

A couple of hopefully helpful tips based on my relatively limited Godot 3D (& non-3D modeller) experience:

  • CSG ("Constructive Solid Geometry") nodes (which enable you to create complex shapes by combining simple shapes together with boolean operations) can be a great way to start prototyping 3D games/levels but be aware that there are some trade-offs involved in terms of the "quality" of the resulting mesh. This is primarily a factor when you want to start applying textures & you may encounter issues with UV coordinates/normals etc.
    There's a CSG intro tutorial here: https://docs.godotengine.org/en/3.3/tutorials/3d/csg_tools.html
    You may wish to read-up on some of the potential issues (e.g. here: https://github.com/godotengine/godot/search?q=csg+uv&type=issues) before committing to CSG in case your plans might be impacted...
  • In part I started prototyping with CSG because I wasn't aware that there was another option for easily creating simple a.k.a. "primitive" (e.g. cube-based) level geometry in Godot (an option which also has the benefit of seemingly having fewer issues with mesh quality/UVs etc).
    The prototyping option I now turn to first, is to add a MeshInstance node to the 3D scene and then click on the `Mesh` property which enables you to choose to instance one of a number of simple/primitive meshes, e.g. cube, capsule, cylinder, etc.

Hopefully that helps some people avoid running into the same issues I did. :)

Bonus tip: If you're looking for some basic prototype textures to apply to your prototype geometry the famous "Kenney" has some freely downloadable CC0 (public domain) textures available here: https://kenney.nl/assets/prototype-textures. (And also directly through the Godot Asset Library on the web or in the editor: https://godotengine.org/asset-library/asset/781.) (And, someone who, just quietly ;) has also recently started using Godot for some of his projects. :D )

Hopefully you saw @willnationdev's helpful comment below about the specific considerations around the combo of networking+HTML5 you've mentioned: https://itch.io/post/4455023

Read your zine online--the photograph with the zine on the cutting mat with the hand drew me in.

The "painterly" effect you got from your initial VHS experiments is indeed cool.

Thanks for sharing.

Your YouTube videos are *great*--really watchable, engaging & authentic.

I found your channel via channel list on  PlayWithFurcifer's channel.

Do you have an account on Twitter? (You already got a mention from a Godot dev team member: https://twitter.com/Akien/status/1372498829115801602)

Now with a Windows download available!

(2 edits)

Have added a Windows download--no code changes, just exported it after some sleep. :)

(Oh, and, the multiplayer is cross-platform. FWIW. :D )

See comment here for additional details: https://itch.io/jam/7drl-challenge-2021/rate/948283?before=2#post-2832916

Very much incomplete. :)

Might've been 1 minute over deadline?

Only uploaded Linux version before deadline, aim to upload Mac/Windows builds later.


You can play locally offline if the environment variable `TDDWU_LOCAL_PLAY` is set to `1`.


Otherwise, click the "Be Very Online" button to go online--the name/description of the dungeon is based on the dungeon/lobby ID assigned by Epic Online Services.

You can move around and attack a monster with a stick but...well, good luck with that. :)


Up to four players can be in the same dungeon but alas they can't see or interact with each other--and the monsters exist in separate space-time continuum so in this version you can't team up against them.

But, hey, a week ago this didn't exist and now it does, so that's something.


All the Roguelike-specific code was developed this week, the majority of the Epic Online Services plugin/addon for Godot code was developed previously.

That's pretty great. :D

It's an impressive game when it can be that graphically "broken" and still result in a positive player experience!

FYI if you wanted the web export to be playable on the itch.io page there's a couple of itch.io game page settings that can be configured to enable it. (The HTML file in the `.zip` also needs to be named `index.html`.)

(Our Kiwijam entry was also made in & exported from Godot. :) )

The right choice at the time. :) Thanks for the reply.

Thanks to all those taking the time to leave your feedback--for some reason I didn't get notification emails so only noticed the more recent comments when I logged to submit some ratings!

As a fan of donuts I really wanted to "save the future of donuts!" but alas without a web/non-Windows build...I guess I better get used to eating celery instead. :)

While this is an impressive submission the fact that the web version is a post-jam release and the advisory about this fact isn't visible above the game (and thus easy to miss until after playing) makes it difficult to know how to fairly rate the game.

I'd encourage you to consider making post-jam releases more obvious in future. (Ideally itch.io would make it easier to handle this kind of situation since I imagine it's quite common & knowing that the original is "locked in" would probably encourage people to update their games after jams more often.)

In terms of game play I think the game would definitely benefit from more guidance (one suggestion was to add one "module" to the machine at a time) at the beginning. From reading the comments/blog posts it seems there was a lot of additional machine "functionality" available than was obvious--and even when "successfully" completing a task (e.g. creating a word) it wasn't entirely clear if that was all that was required (or, more so, how all the individual elements of the game related to each other).

Definitely a very distinctive aesthetic and an entry which clearly has had a lot of effort put into it.

It just occurred to me that the graph-based interface from your Volcano Game could be a cool way to navigate "rooms" that were made up of source code files/sections to be "fallen through" as monster battles. So, you could work your way through a code base, retreating where necessary. :) (Maybe, as an educational possibility, even following program control flow? Getting flashbacks to 90s Cyber/Hacker movie VR now! :D )

Like many others, I really like this concept and the execution was somewhere between "challenging" and "slow down it's too difficult too soon!". :D

My anonymous co-reviewer said: "really cool concept, difficulty/speed/progression could use some work".

The combination of repetition and ability to supply custom levels makes me curious if there's potential educational applications here (e.g. via "spaced repetition") and what other text-based media might work well for levels (e.g. Tweets? The "classic code" mentioned below? News articles? Classic poetry/literature? Text books? This comment?!)

Definitely a cool entry.

You have created some really nice, distinct & personable characters (particularly the very sympathetic lead character) from a very restricted graphic/audio palette. Nice work.

The animation/sound design of the "chomper" is particularly visceral! *shudder* :)

In terms of game play it was quite engaging, particularly initially. I feel like there were places later in the game where "what to do next" could have been a little more obvious--sometimes the guidance was a little *too* minimal. Eventually I found the re-tracing of steps a bit too repetitive for my tastes--particularly when it wasn't always clear if I could pick up the "shiny thing" with my current skills or had to wait until later.

One major bug encountered while playing was that after gaining the "jump/jetpack" skill the character somehow got "stuck under the ground" where it could move but couldn't return to the proper play area. It wasn't obvious at first that this was a bug which made it even more confusing! Had to restart the game to proceed.

Overall, you did really well at communicating with minimal use of text--I particularly like the "next level/power-up" indicator on the rocket ship.

Clearly you put a lot of time & effort into getting the game into a well executed package--and doing the programming, graphics & music yourself makes it even more impressive.

P.S. Nice to see people using LMMS. :)

You & me both wish there was more to it. :)

This was my first jam so my primary goal was to get *something* submitted even if it wasn't quite as extensive as the vision. :D

Thanks for taking the time to try out the game & for your positive feedback.

What is the current wall you've hit? And is it related to collision detection? :D

More seriously, have you tried posting on one of the Godot-related forums/boards listed on https://godotengine.org/community?

Learning new things/engines can definitely be frustrating--so that feeling is completely normal. :)

Alternatively, could you work on a different part of the game and return to the current roadblock later? Maybe focus on something different related to one of the five specific judging criteria to get re-invigorated?

Good luck!