Help making my first "scene diagram"

Vandalk

Hello! My name is Daniel and I'm a brazillian graphic designer!

I've heard about Godot's for the first time last week through this video and since then I've been learning python while I wait for new videos on that series. Yesterday, after feeling like I have a pretty basic understanding of pyhton's syntax, I started to read Godot's documentation! I'm finding the documentation to be a very good and pleasant read, and the explanation about it's design language really got me interested!

So here's my problem! I'm trying to make my first diagram for a simple beat'em up for the "Two Buttons" game jam. I'm having trouble to decide what should be in the diagram, and what should be out of it.

Here's an album with three diagrams: https://goo.gl/photos/P9g2VCcB1JFPUdaa7

The first image is my first attempt, It has only three itens, player, enemy and stage. On beat'em ups you usually have a life bar, and enemies life bar appears once you start hitting them, so the second diagram added one HUD connected by o dotted line to the player and another one for the enemy.

Now after that I though "I need some kind of visual fx for when a punch hits", "I need an idle animation, a walking animation, a punhcing animation, etc.." and started to grow the diagram and get confused, hence image 3.

Should things like animations be in the diagram? Or should they all be considered part of the "player" block?

What level of detail should be in the diagram?

Do full line arrows necessarily mean that one node will be a child of another?

Am I overthinking this too much? Please, help!

By the way, I couldn't find any tags for "Game Design" or "Planning"! And I also don't know if the best place for this discussion is the General Chat or the "programing" chat. Submitting it to the General Chat for the broader scope.

Ross

Yeah, don't overthink it. You'll learn faster by actually making things.

Your animations will all be in one scene, and probably part of the player. You'll have an AnimationPlayer node, which can have as many animations as you want, and plays one at a time. Unless you get really complicated with skeletal animation and blending and procedural stuff there's no reason to separate it from your player scene.

Yes, in those diagrams the solid arrows mean it's a child.

Basically, start of with each object as a scene. If you realize you want to reuse part of it for other objects, save that part of it off as a separate scene and use instances of it. Or if one object gets way too complicated, find some sensible way to break it up that won't have too many weird connections and dependencies.

Parenting should be pretty obvious: weapons go on people, people go in the world, etc. Basically all it does is make the child move around when the parent does, so if you want A to be attached to B, make A a child of B. Also, communication tends to go down the tree from large to small. In other words, a parent knows what it's children are doing and can talk to them, but its harder to talk to siblings or great grandparents, etc.

So, your first diagram is pretty accurate. Player, Enemy, Level, and you are done.

Vandalk

Thanks a lot Ross!

I guess it's the first diagram for a start then! I'll try to make the game work with these first before thinking on the HUD!

Knowing for sure that each line represents a parent/child relationship makes it a bit clearer in my mind! And your example about parent/Child communication was also really good!

Ross

If you have HUD stuff that should stay in the same spot on the screen at all times, make it a child of the camera. Or, if you have, for example, a health bar above each enemy, make that a child of the enemy.

Vandalk

It sounds so obvious now that you've said it! Thanks a lot!