How to Begin **but** More Importantly, How Do You Begin?

Help
1

Godot Version

v4.4.1.stable.arch_linux

Question

I’m making this thread to ask for a conversation. GDScript constantly reminds me of Python and I can’t help but to think “There should be one and preferably only one obvious way to do it.”. I love that idea but I’m not stupid. I’m not saying “there is only one way” (that’s a definition of impossible) but, I’m asking for an agreed consensus on “best practice” to the following problem.

So, How Do You Begin?

Let’s say, you’ve completed hundreds of games (thousands if you’re humble). If you were to compare the source of each completed game and analyze “what do they all have in common?”, what are the general details each game has that all games have? What are the little details you do on autopilot (the stuff you don’t think twice about)? If you were to lay it out in bullet point, what does that look like?

There are no wrong answers. I’m asking more for a conversation than black and white answers.

What does each of your games (of all of your games) have in common and most importantly, interpret it into “There should be one and preferably only one obvious way to do it.”

  • Plan New Project (What questions are you asking?)
    • What is the visible size of it?
    • Fullscreen? Windowed?
    • What are the playable mechanics?

The above interprets into the following…

  • Start New Project (How are you answering those questions?)
    • Project > Project Settings
      • General > Display > Window
        • Set Viewport Width
        • Set Viewport Height
        • Set Mode (fullscreen, windowed)
      • Input Map
        • Set all Actions up once…

What approach does all of your games have in common?

Thank you <3

2

This is never correct as you have said, but even so you could prescribe to coding style and best practices Godot docs has laid out and be done with it. Also c# style guide

You could just call this the Game Design Document (GDD) but hard architectural decisions are usually bad practice with creative endeavors, a framework is appreciated but emergent gameplay could happen at any time.

A minor thing like windowing an resolution are more of a style choice and that style could still change going forward.

Same for input maps. This could usually be done when developing the player concept and not necessarily the first thing.

Anyway

I just start with an idea in my head, think about potential game play and the overall nature of the game. Maybe start drawing, on paper, aspects of the tech/tools required, story and art style. Write down all the pieces during a brainstorm session, and cherry picking the best ideas balancing the estimated time it might take to make. Also thinking about how it could happen in the engine (also asking can the engine even handle it? Do i need a different engine?)

Its less about setting up the physical project and more about the what this project is, as the engine is just a tool to get there.

Finer detail of art/style and game play can be solidified later, i usually start with a basic concepts in mind and decide in grander terms the genre and visual format and the things the player can do.

Once i have a good idea of what i want, i start implementing things starting with the most interesting or most important. And when things are not gelling i go back to the drawing board and figure out how to overcome the obstacles. Potentially pivoting, throwing out ideas or introducing new ones. When this happens it could mean refactors to different areas, so that is something to balance too and as you progress this will become harder, and less appetizing, to do anyway. ( I actually pivoted from 2d to 3d for a project and im still glad i did and i did it early enough to stomach the work)

The objective is creating a vertical slice of a prototype. Where you can experience most of the games ideas. Once you have that all balanced you could start with the broader aspects of world building, levels, story lines etc. maybe you discover its not that interesting and can abandon the project. You can also use this to pitch to a publisher to fund the project.

Basically things can change as you go, so leave room for it if it happens.

3 Likes
3

the only thing I do consistently the same way is defining variables with Camel Case and functions with Snake Case

1 Like
4

I appreciate the feedback (@pennyloafers, I sincerely appreciate the insight). But, I believe I wasn’t clear and I’m sorry for that :frowning:

I’m hoping to gather Questions and their Answers from the community. What are the questions every one of your games have in common? (regardless of all the possible answers).

As an example, does every single game require your attention to Aspect Ratio?

  • Question
    • What is the aspect ratio of the game?

If so, How do you answer that question when setting up a new project in Godot?

  • Answer
    • Project > Project Settings > General > Display > Size
      • Viewport Width
      • Viewport Height

You can combine your question and answer together if it’s easier.

  • What is the aspect ratio?
    • Project > Project Settings > General > Display > Size
      • Viewport Width
      • Viewport Height

Although there could potentially be a million possible answers, the only answer necessary is how to answer it (in Godot). If you’re not asking this question, say nothing about it. Speak only on what it is you do do (haha I said it).

You can help with the most important matter to you (the thing you always do) or you can list out several of the things you always do but, please don’t worry about any specifics. The question above is “What is the aspect ratio?” and the answer is “Project > Project Settings > General > Display > Size …”.

Is that a question you always ask? Do you always do this without thinking about it?

Take a small break and try only to Q&A what it is you do with every game. What questions do you ask on every new project and how do you go about solving it in Godot?

5

I think my answer still stands. i provided my process, which is ultimately what i think you are asking, even still.

Godot is just a tool, there are no rules or formulas that need to be followed in art.

1 Like
6

There certainly are people on this board who have completed and published multiple games. Maybe I’m wrong, but I suspect the majority of people here are either exploring the engine without any particular goal in mind, or are working on their first game. The list of people who can answer your question is very short, and I’m not on it.

Take every Godot game ever made, and the trivial answer as to what they all have in common is that they share the same engine. The engine handles all of the ‘general details’, some of which you will think about once, most of them you will never think about or even know they exist. That’s what an engine is – a platform to build on that does all the tedious stuff for you.

In my day job, I work as an embedded software engineer in a heavily regulated industry (medical devices.) In that industry, it makes sense not to write a single line of code before you have - at the very least - a complete and reviewed detailed design that the software team fully supports. (ed: our Quality department would probably demand I add that a detailed design is far from the very least thing you need.)

A detailed design is a document that proves you stopped for a bit to ask important questions about each and every way your device could horribly kill, maim, or injure a patient. Also, that you came up with suitable solutions to prevent those horrible things from ever happening. Naturally, I tried making a detailed design for part of a game I’m working on in my spare time.

The design was for a menu system, and it was a massive waste of time that I had to discard almost immediately because how I thought Godot’s UI system works differed quite a bit from how it actually works. Would a design have been useful? Maybe, if I worked on this game as part of a team, and clear communication was a strong need. But I’m just one person, and to me this is a hobby, not a job. The outcome (a playable game) is less important to me than the process.

That’s not to say I never ask questions. At the end of every month I open a text document and tell myself what I have been working on for the past month, what difficulties I faced - if any - and what I intend to work on next. If I don’t have a clear idea on how I can achieve that next goal, I open the Godot documentation or open an example project for inspiration. I also have a short document that describes the basic gameplay in plain English. It contains not even the barest hint on how to implement anything it describes.

To me, making a design up front that covers thousands of tiny details is both pointless and a waste of time.

2 Likes
7

That’s me. I’m trying to learn and take Godot serious.

I understand fully how the creative process is between the developer and their muse. I understand the difference between an oak seed and a finished oak table. What I was trying to ask is, to avoid the endless possibilities and think about what these vastly different objects have in common?

What does an oak seed and a finished oak table have in common? The seed. Ok, let’s examine the seed. How do you begin? There are hundreds of different soils but lets focus on the soil that is Godot.

Imagine, a new Godot project is created and the IDE blanks to new… How do you begin?

What does every project you create have in common?

  • Do you set-up the file system first?
    • e.g.,
      • src
      • art
      • doc
      • etc
  • Do you go straight into Project Settings?
    • Fix up the aspect ratio?
    • Lay out all of the mechanics?
    • Setup the localization?
  • Do you create and assign a Main Scene?
    • Do you immediately attach a script (empty is fine)?
  • Do you just start coding?
    • Do you immediately import a library (everyone should be using)?

How do you begin? What do you do all the time, every time, in a new Godot project?

8

Hi!

I haven’t been working on a lot of Godot projects, but on many Unity ones, so I haven’t completed “hundreds of games”, but a few dozens, so I’ll still try to give a useful answer.

Nothing, apart from creating the project itself and a git repository.
Because as it has been said, every project is different, will change, and most importantly I’m learning new things everyday on how to do this and that, even things that could be re-used from older projects (like localization, to use one of your examples).

Even things that you seem to think are set in stone, are actually not. A few examples:

  • File system: I’m just creating my files and folders as the game is being developed. File system and folders organization is very important topic and it can change a lot during the development process, so I’m not thinking too much about that early on.
  • Localization: localizing a game very early is pointless; every game starts existing in english only (or, sometimes I guess, developers’ native language), and then you implement localization. You could use Godot’s tools, but also make you own one if you have one or if Godot’s tools do not fit your needs, etc.
  • Create and assign a Main Scene: you could do that, but again, that would probably change based on the game design, the save loading, the levels management, etc. so at first, it’s way easier to just work with a “game” scene used to prototype the core gameplay, and later on, refactor the scenes and maybe use a main one.
  • Do you immediately import a library (everyone should be using)?: importing a library is a very quick task, so I’m not doing it until the library is useful. Even my own utility library that I use on every project (I have a Unity’s one and already a Godot’s one) is not imported directly if I don’t need it for the first phases of prototyping. I just don’t want to waste time on setting up a git submodule if I’m not using it right away.

What I’m trying to say is that, not setting up as much things as possible and as early as possible is the way to go. Game developments can often take years, so why bother working on tiny details, when you just cannot anticipate everything?

As a conclusion, allow me to quote @TokyoFunkScene

and confirm that this is absolutely true with no debate.
So you should not worry too much about all of that, just work on your project and setup things that need to be set up, step by step.

1 Like
9

Personally, I’m a fairly experienced game dev; I’ve shipped stuff on game consoles, PC, mobile… I’ve only been using Godot for half a year or so, but I’ve been doing gamedev professionally since the mid 1990s; I cut my teeth professionally on Saturn and PlayStation 1, and before that did Sega Genesis and Commodore 64 stuff as an amateur.

I concur with @TokyoFunkScene and @sixrobin – it’s all too easy when building a game (or any other complex software, really) to lose yourself in process, tools, and generally overengineering things. You need a handful of things to start working on a game:

  • a suitable computer
  • a git (or other revision control system of your choice) repo
  • a reasonably fleshed-out idea (that is: hopefully more than “Vampire Survivors but with Smurfs” or some other “x meets y” thing; try for a couple of paragraphs that are mostly nouns and verbs)
  • a game engine like Godot, Unreal, GMS, Unity…

The git repo isn’t strictly necessary, but it’s strongly advised, for a variety of reasons.

The game engine generally provides all the baseline stuff that every project needs. Your “library you always include” is the game engine; it has all the essentials.

There may be some special library you always wind up going to if your games have similar requirements; maybe you’ve always got talking heads RPG dialog and so always want the library that does that. But game engines mostly have you covered for the basics.

If you don’t have a firm idea what your game is (like, say, if your whole idea boils down to “StarCraft 2 but better” or somesuch… you’d be amazed how many people want to make a game that’s just some game they like with one minor irritation fixed…) then the first order of business is to get that sorted out. It is very easy to think you have a game design when what you actually have is a fuzzy picture of “wouldn’t it be cool if…” stuff and a very short, vague description.

You don’t have to plan down to the minutiae, and you should be prepared for your design to be a very live document that evolves rapidly. What you should have, though, is a reasonable idea of the core of what you want to make, and what makes it different/special. A couple of paragraphs of stripped down text (that is, no adjectives, stick to nouns and verbs) should do. You can get that together in 15 minutes, and if you can’t it means you don’t really have a coherent idea yet.

Once you have a coherent idea, it’s probably best to work on that directly. Don’t worry about menus or UI or whatever, start working on the core idea of the game. You may well find that once you start coding you discover you need to make (or want to make) drastic changes. You might find that what you thought was the fun part is kind of tedious, but there’s another part that’s actually great.

Sim City, for example, was famously the level design tool for Raid Over Bungling Bay; the people working with it noticed it was a lot of fun to just design the levels, so they turned it into its own game. Only a few of us remember ROBB any more, though it was a great game (the C64 had some amazing games…), but most people have heard of Sim City.

Don’t get hung up on ceremony and ritual; the actual game is the important part, the bit that has to be fun and you want people to enjoy. Jump on that, make something people want to play, and then add polish and the surrounding scaffolding. You aren’t trying to ship a file system layout or a set of project settings, you’re trying to ship a game.