Structuring your project: yay or nay?

Hi everyone,

I’m new here and I’m really excited to be part of this community. I just started a project with a friend to develop a small indie game. It’s meant to be story-driven, (probably) pixel art, and with some mini games here and there. We put together a game design doc just so we could make some preemptive decisions about some core points, but we don’t mean to really stick to it and just go with the flow.

Right now we’re at the stage where it’s time to make a little prototype to test the game dynamics. We thought of a scene (not a Godot scene :smiley: ) that takes place in 2 rooms where the main character interacts with a couple of NPCs and must, as main goal, answer correctly to some questions.

I work as a fullstack software engineer in enterprise systems; i’m a junior but I have a decent grasp of working with OOP and such topics. In general, that means I have an idea of how to structure and develop a backend or frontend application for instance and how to test if things work. But I never made a game before, and here there’s a lot more that comes into play besides the objects from a programming perspective: do I start designing the character and writing its scripts? Or rather the environment first? Do I put down the sprites first, then the scripts, then the animations?

You get the gist: in a way it’s the classic “starting a new project paralysis”. When starting something completely anew, do you have an idea of the path you’re going to take? Are there some kind of conventions for this, or does it come down to personal preference?

Thank you all!

1 Like

I would start at all the ends at the same time and try to meet in the middle as fast as possible. Get the minimal viable product (MVP) out – as they say.

The reason I see for this approach is that game development has so many aspects of interesting arts: programming, story telling, 2D art, 3D art, menu design, player psychology, the list goes on and on. It is common to encounter new aspects if one does not quite know what the result is, therefore it is much better to explore from the beginning and explore these different aspects right away.

2 Likes

Yes, absolutely. Sometimes you start a test project just to investigate a particular aspect of the engine or a concept you want to explore. But if you are starting a prototype yes, you have an idea about how you are going to approach it.

It’s personal preference. I have started with the player character before, for my current project I started with the environment. For my previous project I started with the buildings (as I had never done destructible physics based buildings before). In the idea you sketched out, probably best to start with the player and the buildings. However, visuals come second, so initially you should use placeholders and not bog yourself down in animations.

Finally, if you have never done anything with Godot before, it is worth taking some time to learn how to do things. Put your idea to one side for a moment and follow some tutorials. Then do some simple scenes for yourself. There is a lot to learn! Oh and good luck, the journey you are starting on is great fun and very rewarding!

1 Like

Start by making a game mechanics prototype using placeholder graphics/sound/text.

3 Likes

I’m fairly new here, and have precious little OOP experience (I only know Basic, Pascal, and now GDScript). Another (much more experienced) friend of mine and I are writing games at the same time. He is a former professional, and we met three decades ago at college (we both studied computer science).

However, whereas he went into the workplace, as a coder, I went off as a musician (my old man’s a famous jazz musician). Years later, I [re]discovered education and attended university. At university (I hold two degrees, both in ancient languages/archaeology) we were heavily encouraged to meticulously plan every project from beginning to end. I hated doing that, but did it, and it works!

Sure, it’s hassle, and some don’t have the discipline to stick with it, but it’s definitely worth it.

For example, I was sat watching my friend code the other day, and asked him about this or that point on his project, and his answer is always, “I’ll get around to that later.” He doesn’t even know what he’s going to do, let alone how he’s going to do it. (It’s a 1980s style text adventure, no graphics, in Delphi).

Compare that to my own project (which has been meticulously planned from start to finish): I know exactly what I’m going to do, and precisely how I’m going to achieve it, from the very start to the final end.

The difference between those university trained and educated, and those that didn’t bother, is vast. It’s certainly worth planning. Plan. Plan. Plan.

(Back in the day it used to be called top down step-wise refinement, the software development cycle [as part of programming principles and concepts]. Structure charts. Pseudo-code. etc.).

Hermes [Trismegistus].

1 Like

You don’t say anything about your knowledge of Godot and gameart and the division of labor with your friend.

I would start by watching some short video tutorials introducing how Godot 4 works focusing on the 2D Scene and Node design system as well as scripting. It’s better if you have dual screens one to watch and the other one to do. Try another tutorial . Just start with that to feel comfortable. Next find a short tutorial on 2D top down game making. Make sure it’s using Godot 4.

This will give you an idea on next steps. But usually for programmers the toughest part is the art. For that you should use premade. Check out Assets · Kenney or https://opengameart.org/

1 Like

Thank you for your input! And given that my music background is in jazz, now I can’t help but ask who your father is!

I followed the GDQuest 2D and 3D tutorials and read through all the introductory chapters of the Godot documentation. That’s about it!

He’s in a vaudeville band called The Temperance Seven. (They were big in the '60s). They put on like a high-brow musical comedy show and have gags like.

“This next song is written by Cole Porter.”

[The audience all look surprised, as does the rest of the band.]

“Not the Cole Porter, but a coal porter.”

2 Likes