Global Game Jam using Defold - Thoughts so far

#1

Hi!
I tried out Defold for the competition and during the Global Game Jam just recently, and really liked it! I also got acquainted with Sven, Mattias & Ragnar. The former two participated in the game jam as well, and suggested I make a post summing up my experiences so far. There’s more text on the “Downsides”-part, but the things on the “Upside” weigh heavier by far :]

The game me and my team made during the game jam can be found here:
Play in browser: http://csc.kth.se/~jenor/games/totem-defense
Game Jam site: http://globalgamejam.org/2016/games/totem-defense-0

Upsides:

  • Really easy to get into. Even without a lot of prior Lua experience, the language and tool is so simple that if you know some basic game design then you can jump right in.

  • Hits the sweet-spot between control and simplicity, I think it really has a lot of potential!

  • Powerful cross-platform functionality, I haven’t tried iPhone, but it works perfectly on android, mac and windows. Html works pretty well too after the first couple of seconds post-loading.

  • A lot of built-in functionalities and architecture, which makes it easy to do things right and harder to mess up.

  • Where there are tutorials, the tutorials are great.

  • Versioning is simplified, which made our graphic designer happy. The rest of us just used Git as usual.

  • A great forum where the Defold devs themselves are providing help and tutorials for using the engine!

  • Build times are incredible!

Downsides:

  • HTML-build is quite laggy unfortunately, especially at startup. This is true even for the unedited tutorial games.

  • Coming from IntelliJ, I’m suffering something like an IDE withdrawal syndrome using Defold. IntelliJ is rather amazing at helping you navigate through your files and methods, while Defold only provides a little in terms of auto-completion. The fact that misspelling a variable doesn’t give you a compile error has been my downfall more than once. Being able to drag and drop would be swell as well. The engine is still young however, and hopefully the new editor will blow these issues away.

  • Versioning is simplified, which also made it maybe a little too easy to break the project. During the jam we had two breaking events; The first was when our graphic designer wanted to just pull down the current code, but in doing so also comitted her own image edits which weren’t ready to be commited and as such broke the build. The second was that once the app crashed mid-synchronization, and the result was that folders of data (those with edits presumably) dissappeared from the master branch. That was the story I was told anyway :]

  • Since Defold owns the right to its website and all you store there, combined with that unless you do something funky you will in fact store all your data there, that means that Defold can at any time pull the plug on whatever you’re working on. Now I know you won’t do that, but I’ve seen others express concerns regarding doing commercial things using Defold for this very reason.

  • It seemed to me that some topics aren’t covered by the tutorial or forums yet, and are quite tricky to resolve on your own. Aliasing for example; we could have used some anti-aliasing in our game but were unsuccessful in resolving this during the jam. Another issue we ran into was that we made shaders for some bushes, but these are not appearing in the html-build. If you download the exe-file from the global game jam site you’ll see them though.

Like I said; more text, but the upsides weigh heavier by far.

Thank you for making an awesome engine!! :heart:

5 Likes
#2

Thank you for taking the time to write such a good summary of your experience working with Defold! I’ll give some comments to some of the downsides you’ve mentioned:

HTML builds are laggay
Do you experience this in all browsers? I haven’t really thought of it before. I guess there’s some warmup and caching going on at startup.

IntelliJ withdrawal
The new editor will when ready contain a better code editor, but I can’t say for sure that it would beat Eclipse or IntelliJ when it comes to intelligent code editing. I do agree with you that the current editor lacks some features advanced Lua editors such as LDT (Eclipse based) or Sylvanaar (IntelliJ plugin) has. When I need to write a lot of Lua code I often revert to doing it in Atom even though LDT would be a better choice. Code editing is a very important feature of Defold, but there are so many other aspects of the editor that are equally important.

Simplified versioning
Yes, the versioning system in Defold is simple and it works well for novice users. For more advanced users or teams of users I think it’s better to use an external tool.

#3

This is great stuff, thank you so much for the comments and feedback! And congratulations on creating a great game in such a small period of time. Also, say hi to Philipshield from me :slight_smile:

#4

I do indeed experience the HTML lag in all browsers on all computers I’ve tried it on. If you try opening the game linked above, don’t you get small lag spikes in the beginning that smooth out as you keep playing? I wanted to make a recording to show you exactly what I mean, but having a screen recording on made it very laggy, so I’ll skip that. Yeah, if you refresh the page things run a bit smoother, so maybe some of the warmup and caching could be done during the loading screen?

Thank you for the feedback! :]

#5

Thanks! :slight_smile:
He says hello back!

#6

Plays like butter on Windows 10 in Chrome, congrats!

#7

Is there a way to open local projects with Defold? I tried the web build, but I just got a blank white screen (OS X, Safari and Chrome. The download on the GGJ site looked like windows only, so I want going to just try and build from source.

//edit - well I figured out a clunky way to open the source. I created a new repo in my dashboard, opened it in Defold, then copied over the files to that local folder. Cool game! That music is great.

#8

What I really have a hard time with is the message system. For me this is a ginormeous no-no. I’m far from being an expert at LUA, and this will be a major nut for people like me to crack. That’s why I still stick to Game Maker and ClickTeam Fusion since they handles them much simpler. And probably will do that unfortunately for a very long time forward.

A simple solution would be to have the following categories added:

  • Message
    Structured like bindings with functionalities like

On startup
On load complete
On stopped
On looped
If then
For next
While do

etc etc. Then you can add the resource to affect, then you can select from a list of actions to perform on that resource.

  • Message collections

You can store messages in a collection, you specify in what order they will be performed. This way you can simply invoke them like:

MessageCollection.start

  • Message compiler

Once you’ve done the message collections, then you can load them into a message compiler. This exports the messages in a self contained LUA script that you can export for future projects.

  • Auto messages

These units takes in multiple message collections and executes the messages in it, as soon as it gets the messages.

  • Collections

These have support for all these message classes. You can in the properties specify a main auto message to be executed.

I love the way Defold is structured. I really do, but the way messages is handled now really makes no sense to me in the very best of all cases.

When I send an email to somebody then I don’t have to reinvent the protocols used when I send it away, and reinvent the protocols the receiver needs to use to open it up. They simply being invoked down the road when the email is being sent. This is in reality the only way forward for Defold for me.

Reinventing the wheel over and over again is so 4000 BCE. It causes friction. With friction cohesion is lost. With no cohesion there can be no consensus. With no consensus good ideas being lost.

For instance:

You want to play a some music when a level start.

AutoMessage: Level1

On Startup
Load collection “Level1”

On loaded
Play music “ID”

This way you don’t have to manually connect each resource to another with a script. This will speed up things in the long run for everybody.

Currently I’m using Defold like 3% of the time, and I use it just to create particle effects. I would rather use it 100% of the time with these functions in place.

#9

Welcome to the forum!

I’m not sure I understand what you mean when you say you have to reinvent the wheel. The idea with messages is to be able to do what I think you describe, for instance:

In your level, you set up a game object with a script that fades up the screen, shows the player character and starts the music. You do that in the on_message() of the game object as a reaction to the message id “start_level”, for instance.

Now, you can send one message (“start_level”) to perform all those actions. And you can even set it up so that the game object that does all the work is reusable and can be placed in all levels.

And if you decide to use different music in each level, you have a couple of options. One is to add data to the “start_level” message containing info on what music to play. That causes some trouble because you will also need to change the code everywhere the message is sent. The name of the music to play also has to be stored at the sender side, which doesn’t seem right.

A better solution is to have a unique "music_player"
game object (or similar) in each level that has a sound component pointing to the level specific music. Send “play_sound” to it as part of the “start_level” logic and the right music is played. All the level specific info is kept in the level collection.