digitalmars.D - AWS game engine - lumberyard
Did anybody get Amazon's game-engine to work with D? :) https://aws.amazon.com/lumberyard/details/
Apr 07 2020
On Tuesday, 7 April 2020 at 17:50:02 UTC, Faux Amis wrote:Did anybody get Amazon's game-engine to work with D? :) https://aws.amazon.com/lumberyard/details/(Just my personal opinion, feel free to ignore it, esp. since I don't work in gamedev) I wouldn't recommend using it unless you're a mid to large sized company. It requires great level of expertise and has large codebase which means modifying it will be a torture unless you can't afford $10k workstation. I also assume there will be leftovers from CryEngine 3 here and there which was... um.. sorry, no comments. Back to the point. Technically there shouldn't be anything that stops you to make D plugin to the engine using their "bus" mechanisms. It will require a lot of work though to even just make simple moving object demo (that's why mid+ sized company is a must). If you just look for advice about complexity and possibility to use it with D here is my approx. ratings for major engines (first score - ease of integration, second score - overall usability and engine quality, all scores from 0 to 10): - CryEngine 5 | 6 / 4 (uses regular shared libs, should be relatively easy) - Unity | 7 / 7 - Godot | 7 / 5 (it already has some D integration so the score is that high) - UnrealEngine| 2 / 7 (requires a lot of metadata, and there is no docs about it) - Lumberyard | 5 / 5 (probably you want to stick with ebus, not sure about plain DLL's) Even though some engines such as UE4 is a PITA to integrate with, you can go the other way around and implement your game as DLL and then use the engine to visualize game world state and handle/forward physics/input/events to your game code. Again, this is just my personal experience, and it may or may not reflect real state of affairs. Anyway if you're looking to actually finish a game then just use Unity or Unreal, if you want to make whole game in D no matter the odds - do it, ignore engines, take some ECS framework and add features as you go.
Apr 07 2020
Faux Amis <faux amis.com> On 2020-04-08 04:44, evilrat wrote:On Tuesday, 7 April 2020 at 17:50:02 UTC, Faux Amis wrote:Thanks for your nice overview! With all this time sitting at home I wanted to get into game dev again. I do have experience with UE4 and Unity... but somehow I really was looking forward to coding in D again :) Might be worth looking into Godot.Did anybody get Amazon's game-engine to work with D? :) https://aws.amazon.com/lumberyard/details/(Just my personal opinion, feel free to ignore it, esp. since I don't work in gamedev) I wouldn't recommend using it unless you're a mid to large sized company. It requires great level of expertise and has large codebase which means modifying it will be a torture unless you can't afford $10k workstation. I also assume there will be leftovers from CryEngine 3 here and there which was... um.. sorry, no comments. Back to the point. Technically there shouldn't be anything that stops you to make D plugin to the engine using their "bus" mechanisms. It will require a lot of work though to even just make simple moving object demo (that's why mid+ sized company is a must). If you just look for advice about complexity and possibility to use it with D here is my approx. ratings for major engines (first score - ease of integration, second score - overall usability and engine quality, all scores from 0 to 10): - CryEngine 5 | 6 / 4 (uses regular shared libs, should be relatively easy) - Unity | 7 / 7 - Godot | 7 / 5 (it already has some D integration so the score is that high) - UnrealEngine| 2 / 7 (requires a lot of metadata, and there is no docs about it) - Lumberyard | 5 / 5 (probably you want to stick with ebus, not sure about plain DLL's) Even though some engines such as UE4 is a PITA to integrate with, you can go the other way around and implement your game as DLL and then use the engine to visualize game world state and handle/forward physics/input/events to your game code. Again, this is just my personal experience, and it may or may not reflect real state of affairs. Anyway if you're looking to actually finish a game then just use Unity or Unreal, if you want to make whole game in D no matter the odds - do it, ignore engines, take some ECS framework and add features as you go.
Apr 10 2020
On Wednesday, 8 April 2020 at 02:44:39 UTC, evilrat wrote:I wouldn't recommend using it unless you're a mid to large sized company. It requires great level of expertise and has large codebase which means modifying it will be a torture unless you can't afford $10k workstation. I also assume there will be leftovers from CryEngine 3 here and there which was... um.. sorry, no comments.Leftovers? My understanding is Lumberyard is basically CryEngine 3 renamed.
Apr 10 2020
On Friday, 10 April 2020 at 20:34:24 UTC, JN wrote:Leftovers? My understanding is Lumberyard is basically CryEngine 3 renamed.They rewriting it with each release, so it is already like 70% rewritten. But somehow the editor is still represents that horrible sluggish MFC monstrosity, though they're definitely updating it, the first time they did UI framework change there was double window headers, normal Windows one and their own framework THICC one, like really really THICC! It was so thick that it take nearly 10% vertical space just for the window header. Maybe they've polished that out already, I haven't checked for a year, but it's still "beta" so there is really not much to see yet. I still wonder why did they choose CE3 instead of writing something usable, modern and attractive from start. Like this whole thing was just being a scheme to outsource "Star Citizen" development...
Apr 10 2020