Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Azul3D – A 3D game engine written in Go

azul3d.org

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Azul3D – A 3D game engine written in Go

#41

Post by tinco »

slimsag wrote: post #35
tinco wrote: post #23

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…

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, arti…

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 :)

Re: Azul3D – A 3D game engine written in Go

#42

Post by orionhenry »

dualogy wrote: post #40
slimsag wrote: post #35

Earlier quoted context omitted.

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, arti…

> 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…

but your code written as if they were all executing at the same time

Re: Azul3D – A 3D game engine written in Go

#43

Post by slimsag »

damian2000 wrote: post #2

What's with the package versioning? 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?

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

Re: Azul3D – A 3D game engine written in Go

#44

Post by pcwalton »

dead10ck wrote: post #34
dualogy wrote: post #32

Earlier quoted context omitted.

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

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 comp…

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

Re: Azul3D – A 3D game engine written in Go

#45

Post by eikenberry »

tinco wrote: post #41
slimsag wrote: post #35

Earlier quoted context omitted.

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, arti…

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 o…

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.

Post reply on HN