6 ms·

Azul3D – A 3D game engine written in Go

80 points by cnbuff410 12y ago

damian2000 12y ago
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?
- adrusi 12y ago
  It's not normal, but package versioning in go is broken, so people invent their own workarounds
  - mseepgood 12y ago
    There is no versioning, so it can't be broken.
- AYBABTME 12y ago
  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 12y ago
    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.
- slimsag 12y ago
  Hi, author here. I wanted to let you know that I agree .v0 is strange. I see that now and it was an oversight. We're changing it from v0 to dev now instead: import "azul3d.org/audio.dev" No worries though, v0 will continue to work for backwards compatibility. Track the issue: https://github.com/azul3d/issues/issues/10 https://github.com/azul3d/issues/issues/10
Pxtl 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        This is not neccessarily true, e. g. in Rust you have code without GC, but the compiler makes sure that everything is freed.
        dualogy 12y ago
        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..
BinaryHole 12y ago
Good job~ And the next version's Go will support developing games on android
- Artemis2 12y ago
  No. That's just an idea, there's really nothing planned yet, especially for Go 1.4.
- zak_mc_kracken 12y ago
  Not sure where you got this from but it's completely incorrect. There are zero plans from the Android team to support Go today.
xkarga00 12y ago
go get azul3d.org/examples.v1/... is enough, you don't need go get azul3d.org/examples.v1
president 12y ago
No screenshots of the game at all?
- angersock 12y ago
  It's a framework, not a game. This is a rabbithole many devs fall into--and I've been there myself.
  - albertzeyer 12y ago
    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 12y ago
      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.
cwyers 12y ago
"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.
- girvo 12y ago
  > That's not for programmers, that's for people who hate themselves. I laughed. In my experience, building games have meant building tools to fit exactly what your game needs, on top of the engine. There are sets of engines + middleware that handle all of that, but it doesn't seem that this projects is aiming for that (which is normal, see Irrlicht3D, OGRE, etc.)
- adrusi 12y ago
  Not all games need level editors. Doesn't make much sense for procedurally generated games. Level editors provided with game editors often aren't appropriate for a lot of games and they need custom editors anyway. A team making a run of the mill fps is probably going to go with something more established, like unity, unreal, source or cryengine.
- exDM69 12y ago
  > 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 12y ago
    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.
- slimsag 12y ago
nyxtom 12y ago
Is anyone else having issues getting it to compile in OSX?
- nyxtom 12y ago
  Nvm, looks like it's an open issue https://github.com/azul3d/issues/issues/5 https://github.com/azul3d/issues/issues/5
karka91 12y ago
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 12y ago
  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 12y ago
    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.
tinco 12y ago
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.
- atomical 12y ago
  Check out vu. It has some great 3d demos.
- deleted 12y ago
  [deleted]
- slimsag 12y ago
  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.
lobster_johnson 12y ago
It would be great if you could release the various native bindings (OpenGL etc.) as generic packages. They look very useful outside of Azul3D.

80 points by cnbuff410 12y ago

damian2000 12y ago

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?

adrusi 12y ago
It's not normal, but package versioning in go is broken, so people invent their own workarounds
- mseepgood 12y ago
  There is no versioning, so it can't be broken.
AYBABTME 12y ago
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 12y ago
  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.
slimsag 12y ago
Hi, author here. I wanted to let you know that I agree .v0 is strange. I see that now and it was an oversight. We're changing it from v0 to dev now instead: import "azul3d.org/audio.dev" No worries though, v0 will continue to work for backwards compatibility. Track the issue: https://github.com/azul3d/issues/issues/10 https://github.com/azul3d/issues/issues/10

Pxtl 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      This is not neccessarily true, e. g. in Rust you have code without GC, but the compiler makes sure that everything is freed.
      - dualogy 12y ago
        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..

BinaryHole 12y ago

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

Artemis2 12y ago
No. That's just an idea, there's really nothing planned yet, especially for Go 1.4.
zak_mc_kracken 12y ago
Not sure where you got this from but it's completely incorrect. There are zero plans from the Android team to support Go today.

xkarga00 12y ago

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

president 12y ago

No screenshots of the game at all?

angersock 12y ago
It's a framework, not a game. This is a rabbithole many devs fall into--and I've been there myself.
- albertzeyer 12y ago
  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 12y ago
    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.

cwyers 12y ago

"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.

girvo 12y ago
> That's not for programmers, that's for people who hate themselves. I laughed. In my experience, building games have meant building tools to fit exactly what your game needs, on top of the engine. There are sets of engines + middleware that handle all of that, but it doesn't seem that this projects is aiming for that (which is normal, see Irrlicht3D, OGRE, etc.)
adrusi 12y ago
Not all games need level editors. Doesn't make much sense for procedurally generated games. Level editors provided with game editors often aren't appropriate for a lot of games and they need custom editors anyway. A team making a run of the mill fps is probably going to go with something more established, like unity, unreal, source or cryengine.
exDM69 12y ago
> 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 12y ago
  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.
slimsag 12y ago

nyxtom 12y ago

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

nyxtom 12y ago
Nvm, looks like it's an open issue https://github.com/azul3d/issues/issues/5 https://github.com/azul3d/issues/issues/5

karka91 12y ago

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 12y ago
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 12y ago
  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.

tinco 12y ago

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.

atomical 12y ago
Check out vu. It has some great 3d demos.
deleted 12y ago
[deleted]
slimsag 12y ago
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.

lobster_johnson 12y ago

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