3 ms·

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

by 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.
- dualogy 12y ago
  > With Go you can literally have thousands of goroutines running at the same time (like coroutines -- only better) I've been coding Go for some 2 years and I can tell you it does not magically provide your machine with thousands of extra cores so "at the SAME time" is precisely speaking exactly inaccurate. I love coroutines but they're still multi-plexed onto OS threads and they don't all run as massively parallel as you suggested.
  - orionhenry 12y ago
    but your code written as if they were all executing at the same time
- tinco 12y ago
  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 :)

by tinco 12y ago

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.

dualogy 12y ago
> With Go you can literally have thousands of goroutines running at the same time (like coroutines -- only better) I've been coding Go for some 2 years and I can tell you it does not magically provide your machine with thousands of extra cores so "at the SAME time" is precisely speaking exactly inaccurate. I love coroutines but they're still multi-plexed onto OS threads and they don't all run as massively parallel as you suggested.
- orionhenry 12y ago
  but your code written as if they were all executing at the same time
tinco 12y ago
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 :)