
Azul3D – A 3D game engine written in Go - cnbuff410
http://azul3d.org/
======
tinco
The web site looks cool, but it sets off a whole bunch of red flags for me.

First of all it doesn't seem to be a game engine. Instead it's a 3d engine and
some other libraries suitable for games packaged together. A game engine
drives game logic, that's not what this does.

Second, there's no demos of games at all, if I dive into their github account
I find some super trivial 3d scene demo's, no games.

Third, no asset loading libraries. Loading assets is one of the most important
things, once you've got your game designed and implemented you are going to
need assets, and loading assets is not a trivial thing. I personally abandoned
a game we wrote almost entirely from scratch (only the physics engine was
third party) just because we came at the point of needing assets, and it was
clear that it would be simpler to just port our game to UE4 which has just
come out.

Fourth, the go programming language is not very suitable for games at all. One
of their main arguments is concurrency being a part of the language,
concurrency is one of the _least_ important aspects of making a game. In fact
if you're a hobbyist just avoid it altogether, it's just not useful for
anything. And even when you need it, setting up a simple message channel is
simple in nearly _every_ language out there. They brush off garbage
collection, but the truth is Go won't perform any better than proper battle-
tested game programming languages like C#, Lua, Java or even Javascript. And
if you truly need a performant graphics engine, it's going to be either C++, C
or Rust anyway.

~~~
slimsag
Full disclosure: I am the creator of the project.

Wikipedia at least, defines a game engine to be "a software framework designed
for the creation and development of video games" and goes on to say "The core
functionality typically provided by a game engine includes a rendering engine
(“renderer”) for 2D or 3D graphics, a physics engine or collision detection
(and collision response), sound, scripting, animation, artificial
intelligence, networking, streaming, memory management, threading,
localization support, and a scene graph.".

Azul3D has a rendering engine, and a soon-to-be-released 3D audio engine. Go
provides networking, streaming, memory management, threading, and a few Go
packages provide localization support. Azul3D also provides 2D physics
(through Chipmunk 2D), with 3D physics (provided by Bullet) coming soon.
Arguably scripting is not needed, Go has very "scripting-language" like
syntax. But you could use the various Go bindings for scripting languages out
there today (Lua, Python, etc). Azul3D doesn't have any support for animation
yet -- but in the near future it will receive a Blender model loader with
support for 3D animated models. AI and scene graph libraries will surely be
developed over time. I agree that the engine isn't ready for serious 3D games
yet, more work still needs to be done for that to happen as I've already
stated. Perhaps right now it just looks like a graphics engine -- but in the
future it will get better I promise.

Yes, there aren't any game demos yet. These things take time. Do note that
Go's image package allows decoding png/jpeg/gif images (and probably others,
as well). Loading 3D models is coming soon.

Concurrency could be incredibly useful in games -- I'm a bit shocked that
you'd say otherwise. Imagine having a single goroutine perform decisive
actions for an in-game NPC etc. With Go you can literally have thousands of
goroutines running at the same time (like coroutines -- only better).

I enjoy the criticism nonetheless, it lets me know where I am and where I need
to be. Thank you.

~~~
tinco
Hi! Sorry if I came across a bit harshly, it wasn't meant as a criticism of
the project itself. Your project is obviously awesome and very complete
already.

I meant it more as a warning to new developers who are looking for a
framework/engine to build a game with. If all you see is positive things about
this engine, you might not realize that there's proper game engines out there
like Unity/UE4 and a whole bunch of open source ones that allow you to work in
nice high level scripting languages and introduce you to serious game
development as well.

I've no doubt that if you keep up the good work on this project, and perhaps
pick up some nice contributors along the way you'll have a perfect game engine
for go enthousiasts. Especially if you already have a game you're using it for
right now.

About the concurrency: Yes it can be nice, especially if it's nice and
abstracted (no messing about with mutexes and such), but there's very often no
real reason to do it. Imagine having a single method that iterates over your
NPC's and calls their calculateDecision function. If it's a simple decision
you could have hundreds of them doing it every few frames, and never worries
about context switching costs or the cost of communicating immutable versions
of your gamestate and all that jazz. A regular modern computer has only two to
4 cores, you can have one thread running the physics for the next frame, and
another doing state calculations, where's the need for having thousands of
goroutines?

Of course, when computers actually start having tens of cores, and/or your
game state really is divisible in a multitude of uncorrelated calculations,
then yes at some point nice concurrency can be cool.

Anyway, good luck and I'm really looking forward to seeing the first game that
comes out of your engine/framework :)

~~~
eikenberry
Remember that concurrency is not parallelism. Concurrency is an abstraction
and organization mechanism that works great irregardless of the number of
cores.

I personally am a big fan of CSP and love developing programs as a collection
of collaborating services. I do mostly systems programming so can not say how
good a fit it would be for most game programming, but it is a good general
pattern that seems like it would work.

------
cwyers
"No, and it likely never will. Azul3D is for programmers and doesn't provide
GUI-editors."

So, you write your levels using a text editor? That's not for programmers,
that's for people who hate themselves.

~~~
exDM69
> So, you write your levels using a text editor? That's not for programmers,
> that's for people who hate themselves.

Or you would use an external editor like Blender or 3DS Max and do an
importer/exporter script. Writing a GUI level editor is a whole lot of work
and there are other things in a 3d graphics/game engine that might be a better
investment for time.

~~~
bhouston
This is how things were in the bad old days. But there is a lot of "impedance"
mismatch between editors like Blender/3DS Max and game engines that this
really isn't done much any more. The only exception is for modeling/animating
characters and objects -- the levels themselves are almost always assembled
and configured in tool (game engine) now.

------
president
No screenshots of the game at all?

~~~
angersock
It's a framework, not a game.

This is a rabbithole many devs fall into--and I've been there myself.

~~~
albertzeyer
But there must be examples. I doubt they are just developing a framework
without having any example demo apps where they test and use the framework.
And hopefully, there is also at least one serious game using this framework,
otherwise it's doubt-able whether this framework is useful in practice.

~~~
slimsag
There are examples here:

[https://github.com/azul3d/examples](https://github.com/azul3d/examples)

But there aren't any screenshots. I know of at least two others (than myself)
writing serious games with Azul3D, but none have released any screenshots or
demos yet.

------
damian2000
What's with the package versioning?
[http://azul3d.org/doc/versioning.html#development-
versions](http://azul3d.org/doc/versioning.html#development-versions)

v1 (latest version)

import "azul3d.org/audio.v1"

v0 (in development)

import "azul3d.org/audio.v0"

Is this normal for go packages?

~~~
AYBABTME
That's one way of doing it. Another is to just use their github path and use
vendoring tools like godep.

I prefer vendoring since it doesn't rely on a 3rd party being online or
existing in a year. Also it's simpler when you want to have repeatable builds,
since the vendored code is usually in your repo. It's also convenient for
CI/CD things, since your repo ships as a unique component.

Also using versioned path like that means that a version bump means editing
all your files. Across a large project, it becomes harder to manage.

However, versioned path aren't incompatible with vendoring tools. So one
doesn't prevent the other.

FWIW, I think versioned path is also not very popular in the pseudo-contest of
vendoring code/versioning path.

~~~
slimsag
Ew, don't do it by hand. You can use tools like govers to rewrite the import
paths to newer versions. It's not hard to manage at all IMHO.

------
karka91
this caught my eye a few months ago when I decided to learn some
opengl/gamedev. Started working with it but abandoned it when I realized that
opengl 2 is decade old. Other then that it seemed a rather nice set of tools
for my inexperienced eye

~~~
flohofwoe
OpenGL 2.x as base feature level is still a decent choice if you want to be
truly multi-platform (e.g. also cover mobile devices). You can still get
modern GL features with OpenGL 2.x selectively by using extensions if present.
The only things that newer GL versions offer over extensions is a guaranteed
support for certain feature sets (similar to Direct3D versions).

~~~
slimsag
This. (BTW, I'm the author, sorry.)

Although the renderer is GL 2.X based -- it supports OpenGL 3+ features using
extensions. It was written against OpenGL 2.X so that the _lowest_ OpenGL 3
hardware could be targeted.

------
Pxtl
Garbage collector FAQ isn't necessarily reassuring, since it seems to say "go
through the same hoops other GC gaming platforms push you through". Obligatory
Rust gaming comment goes here.

~~~
Guthur
I never read it like that at all.

To me it says be mindful when allocating memory. This is no more effort than
having to manually allocate and free memory, but also has the convenience and
safety of a GC to fall back on.

~~~
Pxtl
If I'm going to have to be mindful of the GC I'd rather just avoid a GC
language altogether. An abstraction you have to be obsessively mindful of is
worse than no abstraction at all.

~~~
enneff
Nobody said anything about obsessing.

When you write code you need to care about your allocations, whether you have
a GC or not.

When you write code without a GC you need to be mindful of freeing memory.
With a GC you do not.

So the GC relieves part of the burden of memory management, and that part is
often the hardest part (particularly in concurrent systems).

~~~
heinrich5991
This is not neccessarily true, e. g. in Rust you have code without GC, but the
compiler makes sure that everything is freed.

~~~
dualogy
If that is true, what's the trade-off? There are no silver-bullets so if their
approach didn't involve some potential "deal-breakers" Go team (or the
ecosystem) would probably have offered a Go clone of it. Would be curious what
they're doing there in Rustland..

~~~
dead10ck
I've only just started learning Rust, but from what I understand, the trade-
off is that the type system in Rust is much more complicated, and thus harder
to learn. Pointers have a concept of "ownership" and "borrowing", which can be
more difficult to reason about, whereas in Go, you don't have to think about
it as much--pointers are just pointers. It also makes the Rust compiler more
complicated, which mean slow compile times. One of the main design goals in Go
was blazing fast compile times.

~~~
pcwalton
Rust compile times are not due to the borrow checker. They are primarily due
to optimization.

------
lobster_johnson
It would be great if you could release the various native bindings (OpenGL
etc.) as generic packages. They look very useful outside of Azul3D.

------
BinaryHole
Good job~ And the next version's Go will support developing games on android

~~~
zak_mc_kracken
Not sure where you got this from but it's completely incorrect.

There are zero plans from the Android team to support Go today.

------
nyxtom
Is anyone else having issues getting it to compile in OSX?

~~~
nyxtom
Nvm, looks like it's an open issue
[https://github.com/azul3d/issues/issues/5](https://github.com/azul3d/issues/issues/5)

------
xkarga00
go get azul3d.org/examples.v1/... is enough, you don't need go get
azul3d.org/examples.v1

