A few questions before starting my first big defold project

Questions
#1

Hello Defold community I am about to start a large Defold project with my team I want to use Defold for its clean message passing system and small mobile bundles. But none of us have worked in a large Defold project yet only small toys I have made. All that being said I have a few questions about project structure and setup I want to run by you pros.

project lay out. I like to run a project structure that localizes concerns so like this.

├── defold_project
│   ├── player
│   │   ├── player.go
│   │   ├── player.script
│   │   ├── player.lua
│   │   ├── player.test.lua
│   │   ├── art
│   │   │   ├── img1.png
│   │   │   ├── img2.png
│   │   │   ├── img3.png
│   │   │   ├── player.atlas
├── input
│   ├── game.input_binding
└── .gitignore

with this my *.script file would be as you expect with an init, update and such. my *.lua would then contain the everything with the player (doing this to make testing easier) and with this structure I will have a lot of small atlas files instead of few large ones.

So my questions.

  1. Is it ok to have so many atlas files? What are the down sides if any?
  2. Is there a better way to structure my code for better testing in Defold?
  3. Is there a problem with most of my code / game logic being in lua modules over script files?
  4. Any nuggets of wisdom you have on how best to setup a Defold project for long term success?
  5. Do you know any large open source Defold games that include things like testing, ci/cd I can look over to take ideas from?
2 Likes
#2

In my opinion, having images and atlas file inside each object folder makes it bulky and hard to reach. I prefer putting all images in assets folder and atlas files in graphics folder just like the built-in folder. Of course you can subdivide it into many files and sub folders

#3

Ok I understand. But no performance hit having so many you just think its a bad idea to colocate with the scripts and game objects.

#4

I hope someone corrects me if I’m wrong, but I think more atlases means more draw calls.

3 Likes
#5

Oh if this is the case then 100% I would want to keep that low… Maybe then you would want all the art used for one “level” in one atlas to have the smallest memory footprint and draw calls.

1 Like
#6

I would say It depends on the implementation as always. Are these atlases all being loaded into memory at once and used on the screen or loaded and unloaded in an optimized fashion? Things to worry about are fill rate and memory load and draw-calls of course is something a developer should think about optimizing specifically considering certain platforms more than others. Then there is video memory , graphic adapter / api speed. it should be faster and more optimal to load and change say a single large texture than a bunch of smaller textures. Of course like everything else it is always a good thing to measure / profile your game.

3 Likes
#7

Yes, in general more atlases means more batches.
Nowadays though, an atlas may be multi page (i.e. a texture array), which allows us to store more stuff into a single atlas, without overshooting the max texture (page) size of the device. So that should also factor in.

4 Likes
#8

Thank you for your reply. I think I understand. It seems the way I was hoping to structure my art at least is not the best idea.

#9

It’s fine to have a few atlases, but consider them from a more global perspective. Take into account performance and memory implication, as explained above. The strategy really depends on the game.

For instance, if your game includes biomes, then using one atlas per biome for the environment + enemies within that biome might be efficient. However, if there are numerous enemies or frame-by-frame flip-book animations for them, it might be worth splitting them into groups or using one atlas per enemy.

The same principle applies to the player character. If the player character has many resources (e.g., items to wear), it might be beneficial to have a special atlas just for the main hero. However, if there is an excessive amount of art for the hero, it might be better to divide it into atlases by clothing layer or logically by clothing availability in the game.

The key is to understand that there is no universally perfect method; your approach should depend on your game and the volume of content you plan to include.

Actually, having logic in Lua modules helps with testing and reusing code, and I would say that this is the recommended way. So, modules are good!

As I said, it heavily depends on the project. Here is an example from one of my projects, which was designed as a game-as-a-service. But please, take into consideration the genre of the game: it’s a mahjong-like free-to-play game. Also, most of the time, I use an architecture where I have only one manager script and a ton of Lua modules. It’s just an approach I like, not necessarily the best or the only possible one. But I think you should understand that when you look at my resource tree.

CleanShot 2024-02-29 at 22.59.58@2x|1654 × 18382, 50%
CleanShot 2024-02-29 at 22.59.58@2x|1654 × 18382, 50%1654×18382 3.82 MB

I have to remind you one more time: this is neither an instruction on how you should do it, nor the best possible way to organize a project. Every project is unique, and every developer has their own habits. It’s more like an opportunity to take a look at how I do it.

9 Likes
#10

Thank you so much this a has been very informative. Other then my art I feel like I am on a good path at least one that wont bite me down the road so much.

Its awesome to see a project structure of a full game and I really appreciate it. I am very happy to hear that modules are good practice I feel like this is going to be a good fit for my project. Again I want to say thank you I can tell you put a lot of time into your response to me it does not go unnoticed you all have been massively welcoming to the defold community.

2 Likes