Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Open Source Software Games Linux

Godot Game Engine Released Under MIT License 73

Posted by Unknown Lamer from the shiny-new-toys dept.
goruka writes with news that a new game engine has been made available to Free Software developers under the permissive MIT license "Godot is a fully featured, open source, MIT licensed, game engine. It focuses on having great tools, and a visual oriented workflow that can deploy to PC, Mobile and Web platforms with no hassle. The editor, language and APIs are feature rich, yet simple to learn. Godot was born as an in-house engine, and was used to publish several work-for-hire commercial titles. With more than half a million lines of code, Godot is one of the most complex Open Source game engines at the moment, and one of the largest commitments to open source software in recent years. It allows developers to make games under Linux (and other unix variants), Windows and OSX." The source is available via Github, and, according to Phoronix, it's about as featureful as the Unity engine.
This discussion has been archived. No new comments can be posted.

Godot Game Engine Released Under MIT License More

Godot Game Engine Released Under MIT License

Comments Filter:

  • Been waiting for this for a long time (Score:5, Funny)

    by Chuck Chunder ( 21021 ) on Monday February 10, 2014 @07:02PM (#46213819) Journal
    (Sorry)

  • Is this like CrystalSpace? (Score:1)

    by Anonymous Coward
    Lots of features early on, some screenshots of pretty, but most of the bloat is in generated, generally useless docuomentation?

    I've yet to play a Crystal Space game worth playing.... or Love and Irrlicht for that matter.

    • Re:Is this like CrystalSpace? (Score:4, Interesting)

      by UnknownSoldier ( 67820 ) on Monday February 10, 2014 @08:22PM (#46214281)

      The AC actually brings up a good point ! Whatever happened to CrystalSpace, Orge3D and other 3D game engines?

      The only one I hear about these days is the FPS "Cube" and "Cube 2: Sauerbraten"

      * http://cubeengine.com/ [cubeengine.com]
      * http://sauerbraten.org/ [sauerbraten.org]

      • Re: (Score:2)

        by goruka ( 1721094 )
        None of those are nearly as complex or featured as Godot. Also, they were designed for hardware architectures not relevant any more today.
        Godot tries to avoid the same mistake by abstracting the graphics part as higher level, so changes in hardware trends don't affect the rest of the engine as much.

        • > Also, they were designed for hardware architectures not relevant any more today.

          Actually, that hardware is completely and still dominantly relevant in the gaming scene. Perhaps you missed the billion-dollar releases?

        • Re: (Score:3)

          by DeSigna ( 522207 )

          None of those are nearly as complex or featured as Godot.

          After having a look over the doco for Godot, I'd say that CrystalSpace isn't as far behind as you'd think (especially if you include CEL). However, Godot seems to have more nice features if you're actually developing a game (nice UI, publishing integration).

          CS suffers from being more of a programmer's playground than a practical game engine and having quite a steep learning curve, but I've been toying with it for more than a decade.

          Also, they were designed for hardware architectures not relevant any more today.

          This hits closer to the mark - CS was started a long time ago, but it's ende

      • Re:Is this like CrystalSpace? (Score:4, Insightful)

        by exomondo ( 1725132 ) on Monday February 10, 2014 @10:23PM (#46214847)

        They still exist, but are often used for student projects and tech demos. Building the game engine and the associated tech demos to show it off is the (relatively) easy part. Creating a decent game with proper art assets, animation, music, voice actors, level design and a good storyline with well-developed characters is the hard part. It requires a lot more effort than collaboratively building application middleware and many studios prefer to use proven commercial engines like UE, iD tech, CryEngine, Source, etc... that are artifacts of actually building a commercial game rather than building just an engine.

        I'm not saying these things are essential for all games but often for notable ones and in the case of simple games it is often not worth the effort to learn/use an engine that has so many features you aren't going to need.

        • You've never played Star Wars: The Old Republic, have you. The majority of the problems they've had with development has been wrangling their 3rd party game engine to fit their game concept.

          The art & the story are hard to do, but picking the right game engine can make or break your game as well.

          • You've never played Star Wars: The Old Republic, have you.

            I have actually, what information exactly should I have gleaned from playing it that you believe I haven't?

            The majority of the problems they've had with development has been wrangling their 3rd party game engine to fit their game concept.

            I suppose they made a bad choice then.

      • Re: (Score:3)

        by mark-t ( 151149 )
        Thos are 3d engines, not full fame engines.

      • Torchlight [ogre3d.org] was made with Ogre3d.

  • General rule of thumb is when a library defines their own types like string, vector, hash map, list, etc, ... run, don't walk away from it.

    Seriously, WTF is wrong with just plain old STL???

    Lets implement our own string class so we can be completely incompatible with everything else.

    It seems like every first year CS student writes their own string and list classes (I know I did when I started).

    • Re:Lets define our own string, vector, list classe (Score:4, Insightful)

      by goruka ( 1721094 ) on Monday February 10, 2014 @09:47PM (#46214667)
      This is an easy answer, STL is good but often not as good, specially for projects this size and requirements because:

      1- It generates huge debugging symbols.
      2- It generates a lot of code because most compilers inline it by default.
      3- It's so complex that compile time increases by a few times.
      4- Errors are huge and uncomprehensible.
      5- Support for custom allocators is limited to alloc/dealloc functions.
      6- Support across compilers is not as good (specially console compilers).
      7- Lack of support for COW with atomic ops for thread safety

      Some of these probably improved significantly since the time work on the engine started, but I'm sure most issues still stand.

      As for why not std::string or std::wstring, have you actually used those? They suck, the amount of operations you can do is really little, check core/ustring.h in Godot to std::string and you'll easily see why everyone rewrites the string class.

      • The first thing I noticed is that the string class wasn't well thought out at all.

        In particular, while it is already generally considered among experienced C++ programmers to be unsafe to derive a class from another that does not have a virtual destructor (a rule that the godot author(s) seem to have violated by inheriting their custom string class from their vector class), when the base class does not contain any virtual members at all, and the base class is still intended to be a general utility class, then inheritance is almost always the wrong tool for the job. The proper tool, in this case, would probably have been to use containment, and not inheritance... or if inheritance was really to have been the way to go, then it should have been derived from a base class that was common to both itself and Vector, where the necessary base class is never directly used by anyone other than those classes, (with all of its constructors declared protected, including the copy constructor, so that it is not possible to use the class unsafely outside of those controlled contexts).

        I can think of absolutely no good reason to ever inherit from a class that has absolutely no virtual functions when the base class is one of general utility, and may be utilized by callers.

        • Re: (Score:2)

          by goruka ( 1721094 )
          Thanks for the preaching, but I don't know what an "experienced C++ programmer" is. There are several different ways people programs C++, including different styles and different purposes.

          Clean code is useless when it doesn't perform as expected, and performant code is useless when it's more difficult to write. C++ is meant to mix both things, so by definition it will never be entirely clean or performant. It's a language that strikes the right balance for this specific purpose.

          In other words, the reaso

          • Re: (Score:2)

            by mark-t ( 151149 )
            There's no problem with not having a virtual destructor. Of course one may often wish to avoid virtual functions for performance reasons, The problem is inheriting fom such a class when the base class is also a general utility class. It is incredibly unsafe, and almost always logically wrong. It is usually n indication of overeagerness on the part of the programmer to utilize inheritance as a code reuse measure. Ther is no problem code reuse by itself, but how this implement or chose to accomplish. It i

          • Re: (Score:2)

            by mark-t ( 151149 )

            By the way, if containment were used, the necessary public functions and operators would just be implemented as single line inline (or even forced intline) functions that delegated their responsibility to the contained class... this would incur no performance or memory overhead above inheritance,, and in particular, you make both the general purrpose vector class and string class completely safe to use in all contexts...where otherwise there is the distinct chance of errors cropping up when a reference to

      • Well that ruins it. I wanted my game to have a totally awesome secret cow level.

      • Re: (Score:2)

        by gl4ss ( 559668 )

        and .stl doesn't have (at least widely accepted) texture support anyways and even the color support is dodgy.

    • What's wrong with plain old STL? It's not compatible with the current revision of the C++ standard library.

      (You do know that the STL is the name for a specific library that predates ISO C++, right?)

    • Haha, totally agree. Now, if only GCC used the SSO like clang and MSVC.

  • Mac support (Score:1)

    by Anonymous Coward

    I like how the Mac version crashes immediately. I'll be using this a lot!

  • According to..? (Score:5, Insightful)

    by Bogtha ( 906264 ) on Tuesday February 11, 2014 @02:23AM (#46215727)

    according to Phoronix, it's about as featureful as the Unity engine

    From the article:

    The tech has now proven to be quite mature and is now very complete and according to its developer to be on-par with Unity, or arguably superior to Unity when it comes to the area of 2D and animation support.

    Phoronix was just repeating the developer's claim. Would anybody who isn't the engine's developer care to comment on its feature parity with Unity?

  • Honestly, i wish Godot the best of luck with their engine.
    But comparing anything to Unity is just telling me it may be "easy" to use, but the performance will never exist.

    I'am yet to play any Unity game that doesn't make my PC feel like its 10 years old. It annoys me when i see a Unity logo on any game, as i know what to expect.
    If Developers spent a little more time using a pure IDE based engine, the current indie games market would promote excellence, rather than cheap physx titles running on some hashed j

    • Re: (Score:2)

      by ctid ( 449118 )

      What on earth is a "pure IDE based engine"? And what do you mean by "hashed job Java code"? Unity has Unityscript (which is like Javascript) and Boo (which is a little like Python), but I'd guess that most games are written in C#. And what does the language matter anyway?

      • Oh dear oh dear lol

        What on earth is a "pure IDE based engine"?

        http://en.wikibooks.org/wiki/V... [wikibooks.org]
        eg: a engine which uses a IDE, either by .dll linkage, or, included .h .cpp files.

        And what do you mean by "hashed job Java code"?

        Shit code made in a shit language which runs like shit = Java.
        Thats not to say all Java programmers are bad, but, the same code in C++ would run at least 10x faster.

        Unity has Unityscript (which is like Javascript) and Boo (which is a little like Python),

        Last time i checked, it supported Java or C#.

        but I'd guess that most games are written in C#. And what does the language matter anyway?

        No, most games are written in C++. For the performance (hence why the language matters).

Slashdot Top Deals

Marvelous! The super-user's going to boot me! What a finely tuned response to the situation!

Close