So, I just wanted to put this idea out there, and see what other people make of it.

I have this game engine (https://github.com/TurkeyMan/fuji), it's
lived for about 12 years now (first commit in 2004, and it existed
prior before source control). I called it 'Fuji' (a modest, yet
pleasing and attractive mountain). It supports (or has supported)
shit-loads of platforms; I'm a game-engine dev for life, and I have a
fetish for portability, and niche platform support.
Needless to say, it has had a LOT of time and energy put into it, and
I would say it's infrastructurally better than most proprietary
commercial game-engines I've worked with (although there are some
missing features, I just implement what I need), mainly in that I have
the luxury to aggressively refactor when design decisions turned out
to be mistakes, and no deadlines to meet.
It is a very good example of what we use in real-world AAA gamedev.

It's written in C, obviously. It has comprehensive bindings for D, which I'm pretty sure I'm the only one that's ever used, and I use it in all my modern D projects.

Anyway. I'm spending less time on hobby game-dev these days, obviously I'm not going to make the worlds next big game engine... Hobbyists will just use Unity. I'm not quite sure what to do with it.

I have been thinking about full-scale porting to D, and it would serve there is a massive-scale long-term codebase, with portability as it's primary objective, and I don't know of another project quite like this in the D ecosystem? Also, perhaps D gamedevs might be interested in an all-D game engine they can use and hack on.

So, when I think on that, I consider what would be lost... and the answer is; almost all platforms. But this is something that can be addressed.

If people find this to be an interesting project, and I do take some
time to do this port, what I'd really love is to work together with
some of the niche platform support guys and use it to stress test
toolchains for various platforms. I'd also like help from guys like
Johannes to make regularly released builds of some console
cross-compilers available so that it can keep on building.
The CI of this project for those platforms would more-or-less verify
that the toolchains and druntime+friends are working.

It seems like a pretty big project, but I can't think of a better use for this codebase right now.

Does this generally interest anyone? The thought of it makes me
nervous, but I also think this might be the most valuable thing I can
do with this code today.
Alternative would be to port to Rust ;)

On 01/11/15 2:33 PM, Manu via Digitalmars-d wrote:
> So, I just wanted to put this idea out there, and see what other
> people make of it.
>
> I have this game engine (https://github.com/TurkeyMan/fuji), it's
> lived for about 12 years now (first commit in 2004, and it existed
> prior before source control). I called it 'Fuji' (a modest, yet
> pleasing and attractive mountain). It supports (or has supported)
> shit-loads of platforms; I'm a game-engine dev for life, and I have a
> fetish for portability, and niche platform support.
> Needless to say, it has had a LOT of time and energy put into it, and
> I would say it's infrastructurally better than most proprietary
> commercial game-engines I've worked with (although there are some
> missing features, I just implement what I need), mainly in that I have
> the luxury to aggressively refactor when design decisions turned out
> to be mistakes, and no deadlines to meet.
> It is a very good example of what we use in real-world AAA gamedev.
>
> It's written in C, obviously. It has comprehensive bindings for D,
> which I'm pretty sure I'm the only one that's ever used, and I use it
> in all my modern D projects.
>
> Anyway. I'm spending less time on hobby game-dev these days, obviously
> I'm not going to make the worlds next big game engine... Hobbyists
> will just use Unity. I'm not quite sure what to do with it.
>
> I have been thinking about full-scale porting to D, and it would serve
> there is a massive-scale long-term codebase, with portability as it's
> primary objective, and I don't know of another project quite like this
> in the D ecosystem? Also, perhaps D gamedevs might be interested in an
> all-D game engine they can use and hack on.
>
> So, when I think on that, I consider what would be lost... and the
> answer is; almost all platforms. But this is something that can be
> addressed.
>
> If people find this to be an interesting project, and I do take some
> time to do this port, what I'd really love is to work together with
> some of the niche platform support guys and use it to stress test
> toolchains for various platforms. I'd also like help from guys like
> Johannes to make regularly released builds of some console
> cross-compilers available so that it can keep on building.
> The CI of this project for those platforms would more-or-less verify
> that the toolchains and druntime+friends are working.
>
> It seems like a pretty big project, but I can't think of a better use
> for this codebase right now.
>
> Does this generally interest anyone? The thought of it makes me
> nervous, but I also think this might be the most valuable thing I can
> do with this code today.
> Alternative would be to port to Rust ;)

After completing std.experimental.color, would you mind doing the same sort of thing for audio?
As you know I'm slowing building up code for game dev: https://github.com/rikkimax/alphaPhobos

You have a lot of good code there, it would be nice to rebuild most abstractions that are commonly used out. Ok, I have another agenda then what you want, but still :p

O_o .. what's your agenda?

I think what I'm talking about here is something slightly different. Also I think the goals of my engine are fairly specific too; run fast, on anything (ie, heavily resource limited hardware), no non-operating-system dependencies, small code. I think this is a different angle than most modern games type projects. Obviously, the point however is to make over a decade of development available for people to use. There's a lot in there.

On 1 November 2015 at 11:43, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 01/11/15 2:33 PM, Manu via Digitalmars-d wrote:
>>
>> So, I just wanted to put this idea out there, and see what other people make of it.
>>
>> I have this game engine (https://github.com/TurkeyMan/fuji), it's
>> lived for about 12 years now (first commit in 2004, and it existed
>> prior before source control). I called it 'Fuji' (a modest, yet
>> pleasing and attractive mountain). It supports (or has supported)
>> shit-loads of platforms; I'm a game-engine dev for life, and I have a
>> fetish for portability, and niche platform support.
>> Needless to say, it has had a LOT of time and energy put into it, and
>> I would say it's infrastructurally better than most proprietary
>> commercial game-engines I've worked with (although there are some
>> missing features, I just implement what I need), mainly in that I have
>> the luxury to aggressively refactor when design decisions turned out
>> to be mistakes, and no deadlines to meet.
>> It is a very good example of what we use in real-world AAA gamedev.
>>
>> It's written in C, obviously. It has comprehensive bindings for D, which I'm pretty sure I'm the only one that's ever used, and I use it in all my modern D projects.
>>
>> Anyway. I'm spending less time on hobby game-dev these days, obviously I'm not going to make the worlds next big game engine... Hobbyists will just use Unity. I'm not quite sure what to do with it.
>>
>> I have been thinking about full-scale porting to D, and it would serve there is a massive-scale long-term codebase, with portability as it's primary objective, and I don't know of another project quite like this in the D ecosystem? Also, perhaps D gamedevs might be interested in an all-D game engine they can use and hack on.
>>
>> So, when I think on that, I consider what would be lost... and the answer is; almost all platforms. But this is something that can be addressed.
>>
>> If people find this to be an interesting project, and I do take some
>> time to do this port, what I'd really love is to work together with
>> some of the niche platform support guys and use it to stress test
>> toolchains for various platforms. I'd also like help from guys like
>> Johannes to make regularly released builds of some console
>> cross-compilers available so that it can keep on building.
>> The CI of this project for those platforms would more-or-less verify
>> that the toolchains and druntime+friends are working.
>>
>> It seems like a pretty big project, but I can't think of a better use for this codebase right now.
>>
>> Does this generally interest anyone? The thought of it makes me
>> nervous, but I also think this might be the most valuable thing I can
>> do with this code today.
>> Alternative would be to port to Rust ;)
>
>
> After completing std.experimental.color, would you mind doing the same sort
> of thing for audio?
> As you know I'm slowing building up code for game dev:
> https://github.com/rikkimax/alphaPhobos
>
> You have a lot of good code there, it would be nice to rebuild most abstractions that are commonly used out. Ok, I have another agenda then what you want, but still :p

On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote:
> I have this game engine (https://github.com/TurkeyMan/fuji), it's
> lived for about 12 years now (first commit in 2004, and it existed
> prior before source control). I called it 'Fuji' (a modest, yet
> pleasing and attractive mountain). It supports (or has supported)
> shit-loads of platforms; I'm a game-engine dev for life, and I have a
> fetish for portability, and niche platform support.
> Needless to say, it has had a LOT of time and energy put into it, and
> I would say it's infrastructurally better than most proprietary
> commercial game-engines I've worked with (although there are some
> missing features, I just implement what I need), mainly in that I have
> the luxury to aggressively refactor when design decisions turned out
> to be mistakes, and no deadlines to meet.
> It is a very good example of what we use in real-world AAA gamedev.

I would be very, very interested in this. I've been yearning for something in D that supports some lighter 3D with texturing, animated sprites, and lighting on both. Something flexible and light that can also have modules pulled independently for drawing and sound if possible. Unfortunately, DGame really only supports 2D, and Dash has all its weight behind being a full-featured 3D engine a la Unity/Unreal.

Would Fuji fit the bill?

On 01/11/15 2:56 PM, Manu via Digitalmars-d wrote:
> O_o .. what's your agenda?

My agenda is simple. To make D have the best usability/libraries when it comes to GUI/game development.

> I think what I'm talking about here is something slightly different.
> Also I think the goals of my engine are fairly specific too; run fast,
> on anything (ie, heavily resource limited hardware), no
> non-operating-system dependencies, small code. I think this is a
> different angle than most modern games type projects. Obviously, the
> point however is to make over a decade of development available for
> people to use. There's a lot in there.

Of course. What I'm thinking is port + refactor + make more complete/generic.

There is no reason it can't be fast and usable on limited hardware.
Your desire is to port it as is. Mine would be to port some in context of a greater library, refactor and make it more complete. Then repeat until complete.
When a new platform is ready, add the platformy specific aspects to existing parts.

It's a much slower process. But it will create a much more idiomatic D environment to work with.

On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote:
> ...

speaking of portability, I ran across this game written in D on github that claims to work on Android via NDK bindings, I thought it might interest you.
https://github.com/mathstuf/abagames-gunroar

Bye.

On 1 November 2015 at 12:10, Nerve via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote:
>>
>> I have this game engine (https://github.com/TurkeyMan/fuji), it's
>> lived for about 12 years now (first commit in 2004, and it existed
>> prior before source control). I called it 'Fuji' (a modest, yet
>> pleasing and attractive mountain). It supports (or has supported)
>> shit-loads of platforms; I'm a game-engine dev for life, and I have a
>> fetish for portability, and niche platform support.
>> Needless to say, it has had a LOT of time and energy put into it, and
>> I would say it's infrastructurally better than most proprietary
>> commercial game-engines I've worked with (although there are some
>> missing features, I just implement what I need), mainly in that I have
>> the luxury to aggressively refactor when design decisions turned out
>> to be mistakes, and no deadlines to meet.
>> It is a very good example of what we use in real-world AAA gamedev.
>
>
> I would be very, very interested in this. I've been yearning for something in D that supports some lighter 3D with texturing, animated sprites, and lighting on both. Something flexible and light that can also have modules pulled independently for drawing and sound if possible. Unfortunately, DGame really only supports 2D, and Dash has all its weight behind being a full-featured 3D engine a la Unity/Unreal.
>
> Would Fuji fit the bill?

In terms of what I've used commercially, Fuji is the platform abstraction and core concept implementation that lives below the layer that the high-level interacts with. Editors and tooling (I feel this is what you're talking about when you start using words like 'Unity' or 'Unreal') typically impose particular design decisions wrt scene-graph, physics implementations, etc. The goal of Fuji is not to be Unity, it's intended to be the platform which you could build Unity above, and all commercial engines I've had contact with do have such a layer.

I'm not sure if that answers your question.
For what it's intended to be, Fuji is quite comprehensive. As a
full-game-engine a-la Unity/Unreal, it needs all the high-level stuff
built on top. The reason I didn't touch that, is because that layer is
extremely subjective, and there are no right/wrong answers there. I
also change my mind on that stuff every year or 2. Whereas the lower
level is a lot less subjective, and it's been more-or-less constant
since I started Fuji in 2003. I still wouldn't do it differently
today, although I have a lot more experience and console generations
to draw wisdom from.

On 1 November 2015 at 12:20, rsw0x via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote:
>>
>> ...
>
>
> speaking of portability, I ran across this game written in D on github that claims to work on Android via NDK bindings, I thought it might interest you. https://github.com/mathstuf/abagames-gunroar
>
> Bye.

Does it support Dreamcast? :P

On Sunday, 1 November 2015 at 02:36:16 UTC, Manu wrote:
> On 1 November 2015 at 12:20, rsw0x via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote:
>>>
>>> ...
>>
>>
>> speaking of portability, I ran across this game written in D on github that claims to work on Android via NDK bindings, I thought it might interest you. https://github.com/mathstuf/abagames-gunroar
>>
>> Bye.
>
> Does it support Dreamcast? :P

Not even Sega supported the Dreamcast.

On 1 November 2015 at 12:45, rsw0x via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 1 November 2015 at 02:36:16 UTC, Manu wrote:
>>
>> On 1 November 2015 at 12:20, rsw0x via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Sunday, 1 November 2015 at 01:33:29 UTC, Manu wrote:
>>>>
>>>>
>>>> ...
>>>
>>>
>>>
>>> speaking of portability, I ran across this game written in D on github
>>> that claims to work on Android via NDK bindings, I thought it might interest
>>> you. https://github.com/mathstuf/abagames-gunroar
>>>
>>> Bye.
>>
>>
>> Does it support Dreamcast? :P
>
>
> Not even Sega supported the Dreamcast.

Ow, burn! :P