Hi,

I am new to Godot, just recently found out about it :) Have some Unity/Unreal knowledge and several 2D Libraries for C++, especially SFML2.

I am not quite sure about the scene approach Godot takes. So I would like to get a short "quickstart" suggestion from you on how to best structure a simple Pac-Man clone.

I would create scenes for these objects: Pac-Man Ghost A Ghost B Ghost C Ghost D SmallPill * BigPill

An then I would also create a "Playground" scene that loads a map file (json/xml) that displays the walls and pills etc... should I create a scene for each wall sprite?! I am thinking about using a tileset for the walls. For 2D Pac-Man even a single tileset should be enough for all the graphics.

13 days later

For a Pac-man clone, you could very easily do it with scenes for the pills, for the ghosts (which could be one scene, since the only real difference is their texture and their behavior, not anything functionally substantial), for Pac-man, for the tileset, and finally for the level itself to put it all together.

And yes, you shouldn't need a scene for each wall - you could easily do it by following the tileset tutorial to generate a tileset for all needed wall tiles.

Rather than loading map data from an XML or JSON file, you should be fine to just construct the level in Godot directly. You'd create a Tileset node in the level scene that uses the tileset you saved to actually construct the level. When you construct the level using the tileset, it'll use the nodes with the configuration you exported in the tileset (so the walls will have collision if you set it up, for example).

6 days later

Godot scenes are similar in nature to Unity's gameobject/prefab system and Unreal's actor/blueprints system. Unlike Unity and Unreal, there is no concept of a Unity scene, or Unreal map, those are just Godot scenes as well.

For a simple game like this you can probably just use a single master scene or singleton (if you wanna run mazes via the "play scene" functionality and get easy intellisense access in code) to handle top-level game logic and state (loading/unloading mazes, lives left, points, fruits consumed, etc.) From there you create your instantiables, like a pellet, a power-pellet which could be inherited from the basic pellet's functionality, ghosts (which as mentioned, can be just one base ghost which gets a makeover depending on which ghost it ought to be once instantiated), sentient pellet-consuming pizza fellow, and the various mazes. The mazes would be constructed with a tilemap, perhaps one for the maze itself, another for painting pellets and power-pellets. Each tile can contain data for how the player character can pass through it, assuming you're not using the built-in physics engine (which would be weird for a paclike but that's up to you.) Player control logic can be kept in the player avatar, pellets remaining and logic to play a jingle and hold the action while it's playing can be kept in each maze's root node, or you can keep that in the master scene if you prefer your logic be there.

It's a very object-oriented design flow, frankly. You also don't need to turn everything into a scene in order to get functionality (especially if that functionality appears once, like it will with the player avatar, excepting the possibility of multi-pac action.) You can just keep the player-related and ghost-related nodes under the master scene's root, if you prefer, and remove/add them to the hierarchy to pull them in and out of the game, and that action can be simplified if you put them all under a single node that's intended to persist between mazes. But that's up to you. If you will include cutscenes like in the original pacman games, it might be a good idea to split up your normal gameplay and your cutscene stuff into separate node hierarchies, so you can fully disable one functionality easily when switching between the two.

https://godot.readthedocs.io/en/stable/tutorials/2d/using_tilemaps.html https://godot.readthedocs.io/en/stable/getting_started/step_by_step/singletons_autoload.html