Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Open Source Software Games Linux

Godot Game Engine Released Under MIT License 73

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

Comments Filter:
  • by UnknownSoldier ( 67820 ) on Monday February 10, 2014 @09: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]

  • by mark-t ( 151149 ) <markt AT nerdflat DOT com> on Tuesday February 11, 2014 @01:44AM (#46215467) Journal

    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.

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Working...