I am striving to make one!
Though we analysed already that it has a really small impact on popularity actually, but I canāt deny it could be an ignition some day. It is surely nothing we can do ad hoc.
I am striving to make one!
Though we analysed already that it has a really small impact on popularity actually, but I canāt deny it could be an ignition some day. It is surely nothing we can do ad hoc.
I often wish that there was a TypeScript-style variant of Lua which offered optional type declarations to help catch errors.
Actually, there is a typed variant of Lua in active development:
Also, thereās a TypeScript to Lua transpiler:
https://typescripttolua.github.io/
And we have several language definition files ready to rumbleā¦including those for Defold:
I canāt personally speak for Defold ones, but I recently tried a VSCode + TypeScriptToLua + LĆVE setup and it worked like a charm. You can have the transpiler running in background and doing the work automatically too.
Last but not least, if you like to keep working with plain Lua, you can try this plugin for IntelliJ that leverages EmmyLua comments to do both intellisense and type checks:
One thing Iāve never really been clear on is who exactly is the audience for Defold?
The easy answer would be āanybody who wants to make a gameā, but the unfortunate reality is that anybody who wants to make a game has a multitude of great game engines from which to choose, with a only few of those choices taking up the vast majority of user/industry mindshare.
Defold could be the engine for professional studios targeting web and mobile games? Possibly, but chances are there are political, economic, technical, and resource/talent acquisition issues that prevent many of these studios from switching from their preferred development tools/platforms regardless that Defold might actually be a better fit for their games and studio.
For me Unity is the IBM of game engines. Just as (in the past) ānobody ever got fired for choosing IBMā, so too does Unity enjoy such a position within the industry. They are without a doubt the default choice for creating games and interactive experiences. And if you want a job in the games industry, you need to learn Unity.
Unreal is for folks who for whatever reason are not comfortable with Unity (as a tool/platform or an organization) and simply prefer Unreal. I know there are some other technical issues why some folks prefer Unreal to Unity, but IMHO the two are fairly evenly matched, with the biggest difference being in their underlying technology, principles and philosophies.
GameMaker is for folks focused primarily on 2D games, and provides a nice set of visual tools for folks who arenāt comfortable working in code. With a number of high profile games under its belt GameMaker remains a popular choice for budding 2D game devs, although Godot does seem to be eating into its market in recent years.
Godot is the open, feel good, underdog option. Itās not really competing with Unity or Unreal as itās users arenāt AFAIK large studios, and a large contingent of its audience appears to by hobbyists who feel the free offerings from both Unity or Unreal donāt suit them for various reasons.
After the big four we come to Lƶve (2D desktop), Solar2D (2D mobile), Phaser/Construct (HTML5 games), Renpy (Visual Novels), etc. (incl. Defold) and a whole host of others tools/engines where the value propositions to developers isnāt nearly as clear as it is with the BIG 4.
So coming back to my original question: who exactly is the audience for Defold?
From a technical POV I donāt think Defold is a better option than the others, except where binary size (web/mobile) is a consideration. Most studios also tune their pipelines for Unity and Unreal, so again Iām not sure Defold can offer any advantages there. Also, most larger studios have moved to typed languages which could be a massive blocker to the adoption of any tools using Lua.
Defold is open, but with Godot also being open and providing more features/tools itās largely of little direct benefit in comparison. Solar2D is also open, as is Lƶve and I donāt believe that being open has had much impact on their audience growth.
Defold also requires you to work with lower level primitives, which for indie devs and smaller studios might be perceived to have a significant impact on resources and timelines. For hobbyists this translates to more time spent plumbing and less time spent working on the fun bitsāand where I expect Godot really shines for this audience.
So, beyond smaller binaries and near zero config builds, what does Defold bring that sets it apart from the competition?
For me zero iteration time
Iāll tell you my opinion. I started with Defold almost as a complete beginner. I knew the programming logic thanks to the visual scripting tool Scratch, but that was all. I tried to penetrate various game engines, mostly I had a problem with clutter and a more complex programming language. Then I came across Defold and I was thrilled by David Chadwickās instructions. It was a fight, it was a difficult journey, but at the age of 15 I can say that I became a good programmer, I did procedural island generation using Perlin noise, path finding, I implemented trigonometric functions and learned a lot of things. And not because of simple tutorials, but because of the people here on the forum and shared projects. I learned to learn, to understand code, without anyone explaining it to me completely. And itās very important to me. If I told it to an beginner now, he probably wouldnāt choose Defold, maybe one of ten. Defold is simply different, it is not for everyone, but that is also its strength.
^^^^^ This. Except at the age of probably 33 at the time.
Extremely good performance, especially on mobile.
Memory is preallocated, so you donāt have GC pauses. I fought that a lot with LibGDX.
A very clear and IMO brilliant programming model with the message passing system. I absolutely love it.
I think these are very important points, but they arenāt going to attract people who just want to dip their toes into games development to see if they like it. Thatās most games devs to be honest. They try out an engine for the first little while. From there they decide to stick with it, so project number two is either done from the same engine they tested out or from an engine which shows off the one feature they are excited to try out. Defold doesnāt fit either of these situations. Personally when people tell me they would like to get into games development I recommend Pico-8 to them. I think itās a great engine which truly teaches you a lot about the core of game development. Itās also an easy step from Pico-8 to Defold based on Lua and the way they treat the user.
Was also thinking perhaps some more Defold-focused game jams would be helpful? The two Iāve been here for were pretty neat and there was definitely a lot of enthusiasm for them.
Yes, I pointed it out up here too I will be organising another jam for sure and I would really appreciate any aid here
The product page (now named Features in the top menu) has a new look:
Weāre going to iterate on it a bit more, but itās better than the long feature list.
Looks great!
It just occurred to me that itād be great to have separate features lists/product overview for different people or use cases, enterprise and hobbyists, mobile/html5 and desktop. E.g. a couple of dropdowns at the top āWho are youā and āWhat is your target platformā. And based on that features would be sorted and rephrased to be most helpful.
For enterprise - small builds, fast iteration, easy 3rd party SDK integration, open source, great backward compatibility and stability.
For hobbyists - easy to learn Lua, full features IDE, easy export to Steam and HTML5.
Something like that.
@sergey.lerg what kind of problems are there with Haxe?
There was a discussion on Games From Scratch Discord server about Defold, after they presented recent collaboration with Rive as something interesting to check out and people noted there that they might revisit Defold, but what is holding them is Lua and were talking about Haxe inter alia.
Someone also noted that would like some kind of Visual Scripting.
Donāt treat it like statistic - it just 2-3 opinions after all
This will not happen.
Iām curious to learn this as well. Perhaps there are things we can do to make using Haxe easier?
I have to honest here: I donāt understand what is the problem about Lua. [ But the index starting at 1 ]
Also, I think I like Haxe, but, come on, a lot of people is attracted by Haxe / Heaps because of the success of Dead Cells. As if it were enough to use haxe to produce a successful game.
Of course, only my point of view and I apologize for speaking directly.
Honestly, I think a lot of the problem is people not learning about error handling properly. My background is in C (a typed language) but I can still learn to handle type errors without too much trouble. I think people get used to C# with itās strongly-typed (optional) traits and think thatās the only way to do programming.
Obviously itās pretty subjective, but many people do level the complaint of Lua not being typed and I have never seen it as an issue.
My background is also C and several times I had to fight to find an error due to a misspelled variable name. But, at least for the game Iām working on now, Defold has ALMOST never required me to write (complicated) algorithms. Itās always about reacting to some event by throwing some other event, enabling a go, starting an animationā¦ For these things a typed language is just a syntactic burden from my perspective. As you said, totally subjective.
I totally agree with you on it not being a problem. Iāve worked on large Lua code bases and we very rarely had any type problems. It was not an issue.
BUT at the same time Iām not oblivious to the fact that itās nice to have that extra bit of help from the editor and compiler and I can see how someone becomes extremely relaxed and comfortable and sure that any type errors they make will be caught early on.
Iāve done my fair share of Haxe and while it is a nice language, it is at the end of the day a transpiler that adds friction in your day to day workflow.