Godot Engine open sourced
godotengine.org
godotengine.org
What I've seen so far:
A custom scripting language(GDScript) which is roughly Python-esque. The wiki explains that after trying the other common choices(Lua, Squirrel, Angelscript) over a period of years, they rolled their own solution that could be more closely integrated to the engine.
An in-editor help, it has some API docs.
Classes for GUI controls, including layout containers.
A fairly rich audio API, including positional audio, streamed audio, common sample playback controls(pan, volume, pitch, looping), and some effects(reverb, chorus, frequency filter).
Some networking functionality, including HTTP, TCP, and UDP(unclear?) mechanisms.
Keyboard, joystick, mouse, and touchscreen input classes.
And of course lots of rendering and physics-related stuff, including various shapes, cameras, meshes, sprites, animation, tilemaps, texture atlasing, internationalized fonts, particle systems, and multiple viewports.
>I'm more interested in how those layers could be used with my own engine than theirs itself.
You and me both. Also looking at Proton [1] and Allegro [2] for similar reasons. And just came across a Blackberry-backed engine [3] which looks interesting (and also Lua-driven).
I actually have my OWN game engine (based on LuaJIT, thank you ;) that already targets Windows, Android, and iOS, but I'd like to rip out the platform layer and replace it with something that someone else is maintaining. I mean, it works now, but leveraging open source and other developers' efforts would be much better.
I've considered just using SDL 2.0 and calling it good, but I'm tempted to pick up some of the higher-level functionality some of these other engines offer.
None offer all the features I want, unfortunately. One of the big features they mostly miss is really good script/C++ cross-functionality. Aside from that, there are typically one or two other things that make me want to avoid them.
[1] http://www.rtsoft.com/wiki/doku.php?id=proton
I actually have my OWN game engine (based on LuaJIT, thank you ;)
This comment would be better if it wasn't snubbing everyone who dared try to shake up the status quo of programming languages. People two hundred years from now won't be using LuaJIT. Therefore why wait two hundred years to invent the future? We could have it within our lifetime, if we remain supportive.
But LuaJIT is the future of scripting. It's truly a stunning achievement.
That being said, the "better" things I'm thinking about could be added to LuaJIT just as well as they could be to other scripting languages. For example, the LuaJIT compiler could try its best to auto-vectorize (really really hard) or could leverage the developer with SIMD-like vector operations that would adapt to whatever SSE/NEON/...-like instructions the target platform has. GCC/Clang already dod this to some extent with their vector extensions. Although for many instructions you still need to use specific intrinsics which are not cross-architecture compatible of course. The ones that are:
- add/subtract - mul/divide - shuffle
Which are already pretty important. One could argue over implementing some "generic" intrinsics and possibly emulating them on platforms that don't have it. But then one could be left scratching one's head when suddenly everything gets slow.... So I can understand the gcc/clang devs.
Nimrod is pretty amazing — it's expressive and flexible (eg., type inference lets you omit types in most places, to the point that much of your code ends up looking like Python), and it's just amazingly fast, but not at the expense of ease of use.
What makes Nimrod particularly suited to game development is that it's designed to integrate well with C. Nimrod compiles to C, and the generated C code provides the necessary bindings so that you can easily call Nimrod functions from C without an intermediate translation layer.
In almost every way, Nimrod is the "speed of C/C++, ease of Ruby" replacement that we have been looking for. Go's performance has been too disappointing, while Rust is a wee bit too complex. Nimrod feels just right.
http://lua-users.org/lists/lua-l/2012-02/msg00207.html
I think he's looking for a sponsorship to accelerate this feature[1], so if you know of someone who might be in a position to sponsor the feature, it's a very worthy project!
1. http://wiki.luajit.org/Open-Sponsorships#Vector/SIMD-Data-Ty...
But there are a lot of people doing that right now. I didn't get a vibe from this one that it could do anything interesting that you can't already do in either LuaJIT or Julia. Other innovative languages I've been tracking include Go, D, Nimrod and Dart.
The world is improved by innovations; it's not improved by script language proliferation, or "me too!" projects. Lua in particular is a very well documented language, and is the de facto standard in video game development. I think the bar has to be pretty high to justify creating a new language.
Yes it would be more fun than figuring out how to get 3d matrices to work and be fast in LuaJIT, if you don't already know how the FFI works. But there's a LOT of value in using LuaJIT, and unless you're bringing something else of value to the table, no, I don't think it's worthwhile backing Yet Another Language.
I know of at least a half dozen other engine-specific scripting languages, and I would wager NONE of them are as robust as Lua, as well known as Lua, as well defined as Lua, or even as well designed as Lua. The value of having a shared language does outweigh every new programmer's desire to write their own language.
I use AngelScript, because the C++ interop is about as good as it gets. Chaiscript isn't bad, but its lack of coherent community scared me off.
I'm using Dub for my C++/Lua bindings, which provides exceptional C++ interop. Dub also is easily modified, and with my modifications I can have C++ objects referenced by smart pointers that are wrapped in Lua objects, and those objects can have additional Lua "tags" added to them that persist for the lifespan of the C++ object (even if all Lua instances of the object are collected).
You just can't beat LuaJIT for speed; speed isn't that important for scripting on desktops, but can be relevant on mobile. And it's hard to beat Lua syntax to enable non-programmer scripting options.
Have you seen the LuaJIT FFI by the way? Very similar to what AngelScript offers. But it's also JIT-compiled by the best dynamic JIT compiler in existence. :)
I'm actually rather disappointed almost nobody is using it. I hope it doesn't get canned.
http://www.infoq.com/news/2013/05/lua-vm-javascript
https://github.com/kripken/emscripten/issues/457
https://github.com/kripken/emscripten/wiki/Roadmap
Is your engine open source? I anticipate a JS backend to LuaJIT in the not-too-far future.
My engine had a chance to rot for a while; I'll be upgrading to GLES2 as soon as I'm developing on it again. (Pesky clients paying me to do other work has been slowing down development on my game and engine.)
That is one of my hesitations about Proton; they're still on GLES1.
>This would enable your engine to target HTML5 robustly with Emscripten via lua and sdl.
Not a bad thought. Hmm. Not a bad thought at all. In fact, part of the game I've been trying to work on involves an HTML component, and I've been planning to do it in JavaScript, but if I could do it in my own engine...wow. Thanks for rebooting my brain there. :)
>Is your engine open source?
Not yet. There are a (very few) parts that I don't want to publish, for reasons from "they're broken and I want to fix them first" to "this class prevents pirates from copying games in a novel way, and publishing it would just make it easier for them to pirate my games."
>If only because they just have to find its code and nop it out.
If they changed a single byte in the executable, then none of the encrypted data files (i.e., the actual game) would load. I used a cryptographic key generated from the signature of the binary.
More than one byte would need to be changed. :)
I know I just raised the bar, but due to that feature and the additional obfuscation and misdirection I added, no one ever cracked it. I'm sure that the bar has been raised higher on commercial PC apps (self modifying anti-debugger code comes to mind), but what I did was at least novel on Android.
My technique was dead in the water on iOS, unfortunately; Apple mucks with the binary (encrypts it?) in the production version. But no one pirates on iOS anyway, right? ;)
[1] Successfully, I should say. Pirates thought they'd hacked the game and uploaded it all over the various pirate web sites multiple times. Thing is that the game always detected that it had been pirated, and as a result it downgraded to the "free demo" behavior, so people downloaded the same app they could have gotten for free from the store.
I am sure you could take the signature of the executable in memory and create a key from that for iOS? You just can't _write_ to executable memory but you can read it.
http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...
https://code.google.com/p/gles2-bc/
http://www.gamasutra.com/view/news/177233/Indepth_Bringing_R...
Depending on how difficult it is. Might be an interesting way to bring codebases that target OpenGL ES 1 onto WebGL
My current code is pretty trivial; dropping in a pair of standard shaders and tweaking the code would probably be sufficient.
WebGL is interesting, but it only just got support in IE11 [1]. My only current project with a web requirement would need to support older browsers, including older mobile browsers, and Safari and Android browsers also lack support.
But it doesn't hurt to prepare for the future. :)
> One-Click deploy to several platforms, such as Windows, Linux, Mac, Android, iOS, BB10 and HTML5.
http://en.wikipedia.org/wiki/Waiting_for_Godot
(P.S. not what, but who.)
Seriously, most people would say "Who does this belong to?" We can argue whether it is good style or not, but descriptively it is standard grammar.
You are not right.
"Four times as less" -> "four times fewer" or "one-fourth" ??
Those are words used as they are, verbatem, in a specific context. They are thus ossified and preserved in a much more conservative state than the rest of the language.
It is not unreasonable to suppose that even as our language changes, that phrase will continue to remain intact in root and morphology even if the morphology disappears elsewhere.
Also, nobody suggests doing so would be correct. In "who did that", "who" is the subject of "did" and takes the nominative case.
Anyway, we should not forget that Beckett wrote Godot in French, so the correct form is:
"Godot! Exactement celui que j'attendais!"
Most of these games, the programming itself is trivial. If you can't hack it together in Java without a game engine, then you're not going to be able to hack it together in the game engine.
If you want to make casual indie games that look great, you need to be focusing on your artwork, and how to make artwork that works well in games.
And for the love of god, do not neglect sound until the last minute. Good sound in a game can be as complex to create and program as graphics. You absolutely must develop it in tandem with the rest of your program. We are so focused on visuals, but bad sound will ruin a game more certainly than bad visuals, just as bad sound will ruin a movie more certainly than bad camera work. Bad visuals could be a stylistic choice, but bad sound never is.
2D: study cartooning. Buy a Wacom tablet. Suck it up and buy Photoshop and Illustrator.
Adobe Creative Cloud membership is $50/mo, which is basically the price of Photoshop alone in a year, but gets you access to everything.
Audio: I started using Audition because of the CC membership, and it's been great (I've also put together a few, simple videos with Premiere because of CC). I find Audition is actually kind of fun to use.
Get yourself a drum machine of some kind. I have one of the older Korg Kaossilators, a handheld device that runs on batteries. The new ones are even better. I plug the headphone jack into the microphone jack of my computer and I record directly into Audition. Making serviceable music for games is quite easy with it. Just remember that less is more when it comes to music, and don't be afraid to do non-traditional stuff, off beat, dissonant. It's easy to make and creates much more atmosphere.
Neither I was able to figure out on my own, but they were all quite easy to use after reading a few tutorials on them.
Just remember, treat it like programming. You're not going to get it overnight.
What would the framework of choice be for a browser-based multiplayer game?
The guy who coded it wrote the language I first learned to programme on (Blitz Basic, back on the Amiga in 1992 or so).
Has support for most things you'll want (3D, input, sound etc).
Right now you can prepare your scenes and do some basic interaction, but to make a full game you'd export the scenes and code javascript directly against our goo engine.
It's still in private beta, but if you PM I might be able to speed things up.
We've got the game-building stuff covered, with Javascript engine and designer tools.
And a few of our users are pushing the multiplayer part of it e.g.
Said friend went back to the homegrown engine and is much happier.
edit: just realised you were talking about one of the branches, attention to detail fail
Sorry to go off on a tangent. I've only been into (indie) game development for the last year or so.
It looks to me like game development has lagged behind web development by decade or so in terms of the democratization of tools. Free (as in beer) and open source game development software have grown by leaps and bounds over the last few years. Unity, GameMaker, Unreal/UDK, Anarchy, many many others have become both viable and available.
In the 90's and early naughts, did web developers regularly write their own servers, templating engines, databases, and all else that goes into web development? Didn't game developers more-or-less have to write the whole thing from scratch or license an expensive engine?
These are not rhetorical questions. I'd love to hear the perspective of someone more knowledgeable than me.
Game development has consistently been the opposite: in a race to better graphics, better physics, bigger and better everything, game complexity has only gone up. Companies are working with tech that is not open to access by "mere mortals" because they are often proprietary hardware from Microsoft/Sony/AMD/nVidia. As a result of the technological arms race, there is a LOT of platform fragmentation in the graphics world.
So the problem is that game development is consistently a "big team" task, and industry expertise is monopolized by companies. Tech trickles down very slowly to hobbyists, so while there are engines for the rest of us to use, they don't benefit from the kind of industry battle-testing that web technologies get.
Game engines like Unity and Godot seem to be changing this a little bit by simplifying game development - standardizing complexity by abstracting away low level optimization concerns that you'd really only care about when you need to push technological boundaries. But in general the concept of "convention over configuration" and its related ideas hasn't really caught on, so there isn't even a standard way of thinking about game engines.
The last thing to consider is how much more complex games are than web. Web is mostly a mixture of 2-D graphics and user input handling code. Games are often 3-D graphics (3-D is just much harder than 2-D), often have more algorithmically complex input problems, require audio, and sometimes require real-time networking for multiplayer (web can tolerate latency better). There's just a lot more in there.
Another problem: because of performance requirements, the vast majority of the core libraries for physics, graphics, etc. are written in C++. C++ is not easy to pick up.
EDIT: Sorry if this sounded sarcastic. I was genuinely curious. Always happy to see a new engine out in the open!
- you are not stuck with .NET 3.5
- you can use Linux as your development environment
- you have the full package, instead of the various SKUs
On the other hand, if you have Unity experience, it is a plus in the industry.
Freedom.
For my industry (gambling) Unity costs $200K/title. Price gouging IMO but it's their business to charge what they like.
https://github.com/okamstudio/godot/blob/master/core/error_l...
https://github.com/okamstudio/godot/blob/0b806ee0fc9097fa7bd...
This looks amazing!
Very impressive project. I looked at the code in core folder and it looks very clean and there are is a lot of good stuff in there.
> Unity Free is free for any individual to use
Feature comparison: http://unity3d.com/unity/licenses
Congrats
Also, if someone knows where I can find some free assets I can use. I thought of ripping game sprites from old ROM games but stopped at the thought of hypothetical lawyers rising from the dead.
I've not yet tried Godot but I jumped into useful results with Unity following a basic tutorial. I'm impressed by what Unity gives you right out of the box.
Though many in the Unity development community (and even
in the Unity corporation) refer to UnityScript and
JavaScript as if they were equivalent or interchangeable,
the two are very different languages. Though they
resemble each other syntactically, they have very
different semantics.