I don't really know who else in the community would have the talent or motivation to do it though. I'm all for a Godot Cave Story recreation for the sake of having a more open ended engine to work with (bonus points if we could even make it work with tsc) but I can't be the one to make it because I'm not skilled enough. That's another thing: someone's gotta have the motivation to even do something like this and I don't know who really cares enough to step up to the plate
I think public advocacy is at the very least helpful in motivating people.
Well, it depends. There's a lot of people who work with CSE2 now and D-RS isn't too far removed from it, just with slightly different conventions in spots. So anything from one codebase would at least be identifiable in another. That could be a good reference tool to use.
I'm pretty certain Godot could run C# or something too. So cross-referencing the java port might be useful as well as from what I've been told it's literally just MS's bootleg Java.
I think Arnozi and some others in the community have been practicing Godot but I don't know if they want to do that.
But I think the Godot community would be hyped as hell to see a game ported to it. So I think we could atleast push it in the public Godot servers once it's in a viewable state.
But I think pointing at people is not helpful given this is shit I unfortunately, know how to set up.
So here's how I'd go about it.
- You can make literally anything a scene. Because SCENES are what Godot loads. Well that and nodes / sprites. You could actually just place a png in a room and Godot would be like "sure ok" and just place a flat pane in the room. NPCs, GUI stuff, Enemies, etc. That will all have to be a scene. In game maker the equivalent would be objects, rooms, etc. but those are mostly able to all be the same thing in Godot.
- Godot is always a 3D engine. 2D stuff is just 3D stuff pretty much.
- None of pixel's formats would need to be read but TSC. Even that could be put into Godot's filesystem directly. That said I think TSC could be very easily outdone but I think people would want to transition into a new scripting language more gradually so keeping the format the same would help at least. Script parser would function basically the same as far as I can tell.
- To make stuff like GUI code or any other asynchronous code that'll run independent of the game's tick rate it's best to nest the actual game scene inside the "GUI scene" this way you don't have to load in more than necessary when transferring between levels and can do the particle swipe transition / message boxes.
- Character "sprite states" will need to be handled using Godot's built in animation system. Idk how to translate CS's animation speeds to Godot's but Godot operates on FPS (I set it to 100fps then use very specific speeds that way I basically just have MS timings. It's more accurate.)
- Entity IDs could be thrown out for the most part. NPC.TBL would be able to be replaced with an "entity index" and if you want to go further wtih the TSC replacement you could just skip the "use an index as a middleman" and let people just throw new entities in maps without needing to do all the setup. It'd be a much faster process.
- Collision may have to be handled from scratch if you want accuracy. I personally feel that CS's default collision system is a bit jank and Godot would be a huge upgrade but I know that slope elevators have been a thing. You can still have things have unique interactions with specific tile types though, but Godot has its own format for this that's more robust than the one CS uses.
- Text rendering will have to be redone like it was in other engines. Godot's text renderer is powerful enough already that you could very easily recreate the visual appearance of CS's text accurately.
- Try to replace the "npc.tbl" using Godot's built in stuff to let you configure instantiated scenes. You can set each NPC to have custom spawn parameters just like how they would in CS itself. This would potentially mean if you wanted accurate NPC spawning you'd want generic enemy spawner objects that are configured just like the original one. The main "drawback" is that placing enemies in the correct spots would be hell unless someone makes software to automate the map porting process (which is doable)
- You can directly link collision and tiles in the tilemap. The tilemap can hold collision, spawn objects, etc. It's more than enough on its own to be a better substitute for cs's.
- Animations should be reimplimented using Godot's built-in animation system because CS's animation system is very questionable.
- Don't use canvas layers unless 100% necessary they suck and make me want to kill myself. They make rendering the viewport unnecessarily complicated for no reason.
And the one that stumped me for the longest time:
HITSCANS, SOUND EMITTERS, AND OTHER THINGS LIKE THAT ALL HAVE TO BE ADDED TO A SCENE AND TRIGGERED, NOT "SPAWNED"
Your typical setup for let's say, the player, would resemble something like this (This is what we need to do for ours. This is still heavily wip but you can see what things will be here pretty easily.
This will be dragged into another scene, and bam. There's your entity.
Combined with a good TRES file you can set up parameters that integrate into the code easily. This way there's no magic numbers anywhere!
Our setup for physics is a bit more complicated than CS's right now so porting the player physics parameters directly into this would literally just be a matter of copy and pasting numbers, etc.
Iirc we just have our player script load this when the room loads and right now we're trying to make it faster by having the player be a persistent object that exists between the "GUI" scene and the "Room" scene, that way we can implement loading zones and also not have to lag the game by loading all the player shit all at once. I wouldn't be surprised if this is why the NIS port needed loading screens, because of something similar regarding the filesystem of the game. Their games still suffer from loading issues too... dood.
The filesystem being ported into Godot's filesystem would mean you'd just be dragging scenes into other scenes at that point to recreate the room.
Make sure you enable and configure 'Use Grid Snap', it's extremely important for making a tile-based game like Cave Story in Godot.
Character sprites would need to be separated out into individual, transparent pngs so they could be animated using the built in animation system. This means EVERY single sprite in the game would need to be made unique EXCEPT for tilesets. It sounds like a hassle but it actually makes editing the game's sprites directly with aseprite becomes INFINITELY easier.
Alula's made pxtone support for Godot already so that could be useful (You could also just load wav and ogg files if necessary), yeah this means pixel's proprietary sound effect format won't work by default but Orgmaker would though I'm not sure if it should be an ACCURATE orgmaker port given how buggy it can be.
Edit :
Also Godot doesn't have built in tiled background rendering so you need to literally code it to spawn a bunch of sprites to make things tile, it's really annoying but they also did add batching to the renderer recently so it's not TOO bad.
