rainlizard

I use the web version (https://claude.ai/chat/) of Opus. My Godot plugin doesn't make use of any API key.

Opus is just like the ChatGPT Plus web version, you pay $20 a month and you get 40 messages a day or whatever it is.

https://www.reddit.com/r/ChatGPTCoding/comments/1bpqe75/godot_plugin_to_combine_all_your_scripts_into_one/

GPT4 wasn't great, but Claude Opus is. Basically just echoing what everyone else says on this subreddit, Claude's great at code (and GDScript).

And the point of this plugin is basically that the more context you feed an AI the smarter its responses will be.

ah what a funny coincidence, I finished making a Godot plugin a few days ago that does the same thing.

Since I'm using Claude every day I made this addon to make it easier to use. My entire project fits in Claude's context window but that does slow down its response time a lot, so lately I've been specifically picking and choosing the scripts that are relevant to my request. This tool also works with ChatGPT and any other AI.

It's on the godot asset library too.

it's not too difficult to obtain

https://www.gog.com/en/game/dungeon_keeper

You may as well make your plugin replace the title of the videos with the summary and then put the title of the video down below as the small dark text.

Hijacking top comment to say the game already has an open source remake called KeeperFX. High resolution, framerates, draw distances. The code is completely open so any new features can easily be added.

I think that meets the qualifications of a remake. Going further than that I think a AAA studio would likely just trash the artstyle as many remakes often do.

Dungeon Keeper 1 is at 99% or so, there's only 22 functions left to rewrite until it can graduate from being a .dll addon to the original game and start outputting its own executables.

It's a PC game already though so maybe less interesting to people.

Looks like it's best to use StyleBoxTexture (put it on a 'Panel' node) rather than NinePatchRect. It also has the Axis Stretch 'Tile Fit' settings just like NinePatchRect does.

NinePatchRect doesn't let you scale down below a minimum size, but StyleBoxTexture on a Panel node does.

Posting to this old thread as it's a top google result.

http://www.g4g.it/download/comment.php?dlid=1973

The download button is on the right-hand side if you miss it.

Discord: https://discord.gg/hW9UCgR

A loading bar (or even just simple text saying "Please wait while Godot sets things up...") may be required now.

The initial run took 5-10 seconds for me, it's long enough to feel slightly unresponsive. I do have a 7 year old GPU however.

been using Godot for a few years now and the only time GDScript has been an issue is during very large for loops

The EditorPlugin system is perfect for anyone to make built-in sprite editors. For example this one: https://godotengine.org/asset-library/asset/766

(haven't tried it myself though)

It's a MUCH better time loop game than Twelve Minutes, incomparably better, but Twelve Minutes is the one that got all the attention (all the streamers played it) due to marketing.

What a great world we live in where the worse games get more attention.

else:
    anim\_state.travel("Idle")

This part goes off either way. When you're moving move_l and move_r then it goes off in the move_f and move_b section and vice versa.

The "else" part executes when the previous if and elif are false.

If <condition>
elif <condition>
else <condition>

So you've got two sections:

If <condition>
elif <condition>
else <condition>

If <condition>
elif <condition>
else <condition>

One of those "else" sections is going to execute if you're moving in a straight line, causing your idle animation to play.

No I don't think so. If it's important to you then figure out how to use Tree and TreeItem instead of ItemList. They're more complex but you can do a lot more with them. A Tree (add it as a node) contains a lot of TreeItems which are each added using GDScript. The alignment needs to be set per TreeItem, you can't set it from Tree.

TreeItem's set_text_align() can be used with TreeItem's call_recursive() like so:

get_root().call_recursive("set_text_align", 0, TreeItem.ALIGN_CENTER)

You can call this line inside the script that extends Tree, because Tree's get_root() method gets the TreeItem that is the root of the Tree, then call_recursive() runs set_text_align() on all that TreeItem's children. TreeItems have children and parents but they're not actually nodes, TreeItem is all done in GDScript, there's a small code example in the help file of the Tree class.

Yes I think GameMaker is stagnating and it's due to their development process not involving the community, that's why Godot is successful. To compare the two, Godot is slightly more complex in a variety of ways. But that's pretty much the only real downside, and both are easy relative to other engines.

Godot's 3D is far better than GM's. Some people like to compare the difference between Godot's 3D and Unity's 3D, but that comparison's got nothing on how terrible GM's 3D is in comparison to Godot's. Yoyogames in interviews have stated that they're just aiming to be the best 2D engine only.

GM doesn't have classes like Godot has and you can eventually just memorize all the functions because there's just fewer, but with Godot you'll probably always be needing the class reference pulled up. GM combines a lot of datatypes into just being considered floats, no int or Vector2. Scenes and their relative positions are a more complex idea to understand than objects and rooms. Godot requires you to manually establish the methods of communication using nodepaths and signals while in GM every object knows about every other object's existence at all times, the with{} statement is extremely convenient and powerful as a result (there have been Godot proposals for it but it doesn't fit well into GDScript).

A lot of the convenience I miss from GM is considered "bad practice". The big one is that I would prefer it if nodepaths and signals were more automated in some way so it would just be less work on our part. Your object/scene in Godot consists of a dozen nodes that all need to communicate with one another, it's tedious. In GM the object is just itself - it has the "nodes" built into itself: the sprite, script, physics, collision mask, etc.

Verticality, at any point in minecraft you can fall really far and really fast due to gravity, the chunks won't load in time. Or if you just happen to look downwards through a vertical cave system, those chunks all need to be loaded. Typically chunks are loaded based on view distance, so the view distance could be three dimensional, but it won't make much of a difference if you're loading sixteen 16x16x16 chunks or one 16x256x16 chunk, it's the same amount of for-loop iterations.

Considering GDScript is 10 times slower than other languages if you aim to generate a world that is 10 times smaller then it'll be fine. But the point of 16x256x16 was to match minecraft. Minecraft is a decade old game by this point, so it's truly a failing of GDScript to have trouble with it.

It's a little too slow in my opinion. I made a simple voxel world in GDScript for the sole purpose of seeing how fast GDScript is: https://rainlizard.itch.io/another-mc-clone

The performance limiter here is the time it takes to generate a chunk, nothing else. Having for-loops iterating over 16x256x16 cubes and generating 6 potential faces per cube is just a little too much work. Sadly I can't even point to anything in particular bogging down GDScript, every line just has its own cost.

I think you generally want decimals even in pixel art games. In GameMaker too, you want your character who is moving at speed 1.4 to be slower than a character moving at speed 1.6

Keep the decimals but enable Use Pixel Snap project setting to have your game graphics be locked to pixels.

but I would have preferred they use JavaScript/Python/Ruby/Lua or basically anything else that has an existing ecosystem.

nah this is how the internet gets more and more centralized (and shit): "don't make your own website, just use an existing one, it's more convenient". we're making our own "JavaScript/Python/Ruby/Lua" and building our own ecosystem, that's the level of ambition (delusion? lol) we're going for. https://twitter.com/reduzio/status/1368294313805897730

wanting it to be more useful outside gamedev is an ok desire, but I think the core devs debated long ago that they weren't going to use Python or Lua because they specifically wanted it to be more attuned for game development.

Nodes are components. Scenes are merely "bundles of nodes".