www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - A New Game Written in D

reply Kenny Shields <mail kennyshields.net> writes:
Hello,

I've been building a game engine in D for the past 2 and a half 
years and have finally reached a point where it's usable in 
day-to-day game development. Earlier this year I decided to make 
a simple shooter game to serve as a tech demo for the engine's 
capabilities, and also just to get a general idea of how well it 
works when used in a real application. I did an initial release 
of the game yesterday on itch.io, you can find more information 
on the product page if you are interested: 
https://kenny-shields.itch.io/untitled-shooter-game

This isn't an open-source project, but I wanted to post this here 
for anyone who might be interested in seeing D used for 
cross-platform game development. Any questions/comments about the 
implementation and design of the game/engine are welcome.

On a side note, I'd like to give special thanks to Walter and all 
of you who who contribute to D to make it what it is today. D is 
a fantastic language and really can't see myself using anything 
else for development at this point. Also, shout-out to the LDC 
developers as well, really great compiler.
May 17 2022
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/17/22 12:36 PM, Kenny Shields wrote:

 Hello,
 
 I've been building a game engine in D for the past 2 and a half years 
 and have finally reached a point where it's usable in day-to-day game 
 development. Earlier this year I decided to make a simple shooter game 
 to serve as a tech demo for the engine's capabilities, and also just to 
 get a general idea of how well it works when used in a real application. 
 I did an initial release of the game yesterday on itch.io, you can find 
 more information on the product page if you are interested: 
 https://kenny-shields.itch.io/untitled-shooter-game
 
 This isn't an open-source project, but I wanted to post this here for 
 anyone who might be interested in seeing D used for cross-platform game 
 development. Any questions/comments about the implementation and design 
 of the game/engine are welcome.
 
 On a side note, I'd like to give special thanks to Walter and all of you 
 who who contribute to D to make it what it is today. D is a fantastic 
 language and really can't see myself using anything else for development 
 at this point. Also, shout-out to the LDC developers as well, really 
 great compiler.


Very cool!

I unfortunately can't try it, as it's not open source, and I have a Mac. 
Are there any videos of gameplay?

Are there any plans to sell/release the engine? Can you give a small 
overview of the engine design? Do you use the GC at all?

-Steve
May 17 2022
parent reply Kenny Shields <mail kennyshields.net> writes:
On Tuesday, 17 May 2022 at 16:59:31 UTC, Steven Schveighoffer 
wrote:


 I unfortunately can't try it, as it's not open source, and I 
 have a Mac. Are there any videos of gameplay?


Hi Steven. Apologies for the lack of a macOS build, I actually 
don't own any Apple hardware so my capabilities for testing on 
that platform are pretty limited at the moment. That said, all 
the dependencies for the engine should work on macOS, so that's 
probably something that I could remedy in the future. As for the 
video, I'll see if I can something up later today that showcases 
the gameplay.


 Are there any plans to sell/release the engine?


No plans for selling/releasing the engine, though I would like to 
be able to use it to make a game that I can actually sell at some 
point.


 Can you give a small overview of the engine design?


The engine takes a pretty standard OOP approach and relies 
heavily on the concept of 'managers'. There is a base 
'Application' class (which can be sub-classed if needed) that 
handles a lot of the heavy lifting (window creation, main loop, 
input polling), and contains instances of all of the facilities 
that actually make it an engine (things like resource/sound/hook 
managers, filesystem abstractions and database connections).

As one would would expect with most modern engines, there is a 
'scene' management system (which are referred to as contexts in 
the engine) that allows for easy implementation of game logic and 
rendering. Simply sub-class the base 'Context' class, and you 
have access to a set of methods that you can override as needed 
(update, draw, keypress, keyrelease, etc...) to implement the 
functionality of the scene. When you instance a context, it is 
automatically added to the engine's internal context manager, and 
can be activated/deactivated at any time. Here is an example of 
what that looks like:

```d
class MyContext : Context
{

     this(Application app)
     {
         name = "MyContext";
         super(app);
     }

     override void activated()
     {
         // Load resources...
     }

     override void deactivated()
     {
         // Unload resources...
     }

     override void update(float delta)
     {
         // Update stuff...
     }

     override void draw(RenderWindow window)
     {
         // Draw stuff...
     }

     override void keyPressed(Event event)
     {
         // Key events...
     }

}
```

And then instancing and actually using the engine looks like this 
(from USG's main.d file):

```d
void main()
{
     // create application
     auto params = LaunchParameters();
     params.windowName = "Untitled Shooter Game";
     params.windowSize = Vector2i(1920, 1080);
     params.statsEnabled = false;
     params.uiAntiAliasing = 0;
     params.uiDefaultSkin = "default:dark";
     params.windowAntiAliasing = 0;
     params.windowStyle = WindowStyle.Titlebar | WindowStyle.Close;
     params.entryContext = "MainMenu";
     // params.entryContext = "Game";
     params.dataPath = "untitled-shooter-game";
     auto app = new Game(params);
     // create contexts
     new MainMenuContext(app);
     new GameContext(app);
     // start application
     app.start();
}
```

Beyond what I just described, the engine contains all kinds of 
components geared toward game development. These include things 
like timers, faders, oscillators, a SQLite-based registry system, 
a basic Lua API, no-gc vectors (really just an abstraction of 
std.container.array), and even a custom UI system (which has 
become almost as complex as the engine itself unfortunately). It 
also has a package of modules dedicated to creating and 
simulating 2D top-down worlds, complete with tile-based geometry 
and threaded pathing.

It's also very important to note that SFML makes most of the 
audio/graphical functionality possible, as the engine relies 
heavily on it's API (through CSFML).


 Do you use the GC at all?


The engine takes a hybrid approach with it's memory management, 
but yes I do use the GC for a lot of it's functionality. Almost 
all of the modules that implement the 2D game world do their 
allocations outside of the GC (with malloc and the relevant 
emplacement functions), which allows for more granular control 
over how the simulation's memory works and reduces the burden on 
the GC heap. With this reduction of GC heap usage, it allows for 
GC-based operations in other parts of the engine without having 
to worry too much about triggering an allocation or collection 
cycle.

I know GCs are a big source of contention, particularly so among 
game developers, but I have to say I've never really experienced 
one of the (theoretical) scenarios where a GC ruins a game's 
performance or something like that, at least not with the D GC. 
It seems to just be a matter of not doing crazy things (like 
running heap-based operations every frame) and pre-allocating 
everything that you can with pools or something similar.
May 17 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
 I know GCs are a big source of contention, particularly so 
 among game developers, but I have to say I've never really 
 experienced one of the (theoretical) scenarios where a GC ruins 
 a game's performance or something like that, at least not with 
 the D GC. It seems to just be a matter of not doing crazy 
 things (like running heap-based operations every frame) and 
 pre-allocating everything that you can with pools or something 
 similar.


The concept of GC is fine, it exist in both Unreal and Unity

The only difference is their implementation

Both Unreal/Unity doesn't have "much" problems because they use 
some sort of incremental GC, usually multithreaded

The problem of D is it's the worst implementation for games, it 
scans your entire heap, while doing so pauses all the threads

The bigger your heap is (wich games usually have), the longer the 
pause will be


It's not a problem for "some" games, but as 144hz monitors are 
becoming mainstream, the need of games running at 120/144fps is 
becoming crucial

For 120fps, your frame budget is only 8ms, no time for any GC 
pause

Even thought GC's story is better on Unreal/Unity, they still 
struggle, constantly, wich GC issues, a simple google request is 
enough to validate the point)

I used to not care about the GC, until it started to get in my 
way, since then, malloc/free/allocators, and nothing else

Designing an engine this way gives you much more control, GC for 
scripting only in isolated thread!

That's why it is dangerous to tell people to not mind the GC and 
"just program", no, you have to be meticulous about your 
allocation strategy to properly make use of the benefits that a 
GC will give you!

GC is an ice thing, when used properly, depending on its 
implementation!
May 18 2022
parent reply Kenny Shields <mail kennyshields.net> writes:
On Wednesday, 18 May 2022 at 14:40:59 UTC, ryuukk_ wrote:


 The concept of GC is fine, it exist in both Unreal and Unity

 The only difference is their implementation

 Both Unreal/Unity doesn't have "much" problems because they use 
 some sort of incremental GC, usually multithreaded

 The problem of D is it's the worst implementation for games, it 
 scans your entire heap, while doing so pauses all the threads

 The bigger your heap is (wich games usually have), the longer 
 the pause will be


 It's not a problem for "some" games, but as 144hz monitors are 
 becoming mainstream, the need of games running at 120/144fps is 
 becoming crucial

 For 120fps, your frame budget is only 8ms, no time for any GC 
 pause

 Even thought GC's story is better on Unreal/Unity, they still 
 struggle, constantly, wich GC issues, a simple google request 
 is enough to validate the point)

 I used to not care about the GC, until it started to get in my 
 way, since then, malloc/free/allocators, and nothing else

 Designing an engine this way gives you much more control, GC 
 for scripting only in isolated thread!

 That's why it is dangerous to tell people to not mind the GC 
 and "just program", no, you have to be meticulous about your 
 allocation strategy to properly make use of the benefits that a 
 GC will give you!

 GC is an ice thing, when used properly, depending on its 
 implementation!


Thanks for the insight here, very informative. I think the hybrid 
approach works fairly well for my engine's use case, though I get 
what you are saying about the heap size and all that, I suppose 
some games may not be able to avoid that issue without taking the 
manual approach.

Also, I know that D has some sort of interface for allowing 
custom GC implementations -- has anyone ever made a functional 
alternative? Something that takes the incremental approach that 
you mentioned as opposed to the pause and scan method?
May 18 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/05/2022 5:51 AM, Kenny Shields wrote:

 Also, I know that D has some sort of interface for allowing custom GC 
 implementations -- has anyone ever made a functional alternative? 
 Something that takes the incremental approach that you mentioned as 
 opposed to the pause and scan method?


Severely doubtful, like pretty much all the advanced GC designs, it 
appears to require write barriers (book barely touches on it however).

https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795
May 18 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 19, 2022 at 06:18:58AM +1200, rikki cattermole via
Digitalmars-d-announce wrote:

 On 19/05/2022 5:51 AM, Kenny Shields wrote:

 Also, I know that D has some sort of interface for allowing custom
 GC implementations -- has anyone ever made a functional alternative?
 Something that takes the incremental approach that you mentioned as
 opposed to the pause and scan method?


 
 Severely doubtful, like pretty much all the advanced GC designs, it
 appears to require write barriers (book barely touches on it however).
 
 https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795


We keep coming back to this impasse: write barriers.  It's high time
somebody implemented this in a dmd fork so that we can actually test out
more advanced GC designs.


T

-- 
Life would be easier if I had the source code. -- YHL
May 18 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/05/2022 7:03 AM, H. S. Teoh wrote:

 We keep coming back to this impasse: write barriers.  It's high time
 somebody implemented this in a dmd fork so that we can actually test out
 more advanced GC designs.


No. Not dmd.

LDC or GDC.

DMD is not suitable for experimentation due to the situation with atomics.

Advanced GC's may need concurrent data structures like lock-free, and 
you cannot implement them with dmd due to the atomic instructions being 
3 function calls deep. You get segfaults. Been there done that, what a 
waste of 7 months.
May 18 2022
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 19, 2022 at 07:07:45AM +1200, rikki cattermole via
Digitalmars-d-announce wrote:

 
 On 19/05/2022 7:03 AM, H. S. Teoh wrote:

 We keep coming back to this impasse: write barriers.  It's high time
 somebody implemented this in a dmd fork so that we can actually test
 out more advanced GC designs.


 
 No. Not dmd.
 
 LDC or GDC.
 
 DMD is not suitable for experimentation due to the situation with
 atomics.
 
 Advanced GC's may need concurrent data structures like lock-free, and
 you cannot implement them with dmd due to the atomic instructions
 being 3 function calls deep. You get segfaults. Been there done that,
 what a waste of 7 months.


Sounds good, do it in ldc/gdc, then.  Nowadays I only ever use dmd when
I need quick turn-around time anyway.  In terms of codegen it's pretty
lackluster, for production builds my go-to is LDC.


T

-- 
Change is inevitable, except from a vending machine.
May 18 2022
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote:

 Hello,

 I've been building a game engine in D for the past 2 and a half 
 years and have finally reached a point where it's usable in 
 day-to-day game development. Earlier this year I decided to 
 make a simple shooter game to serve as a tech demo for the 
 engine's capabilities, and also just to get a general idea of 
 how well it works when used in a real application. I did an 
 initial release of the game yesterday on itch.io, you can find 
 more information on the product page if you are interested: 
 https://kenny-shields.itch.io/untitled-shooter-game

 This isn't an open-source project, but I wanted to post this 
 here for anyone who might be interested in seeing D used for 
 cross-platform game development. Any questions/comments about 
 the implementation and design of the game/engine are welcome.

 On a side note, I'd like to give special thanks to Walter and 
 all of you who who contribute to D to make it what it is today. 
 D is a fantastic language and really can't see myself using 
 anything else for development at this point. Also, shout-out to 
 the LDC developers as well, really great compiler.


Reminds me a lot of CS2D, good job! :)
May 17 2022
parent Kenny Shields <mail kennyshields.net> writes:
On Wednesday, 18 May 2022 at 06:09:06 UTC, bauss wrote:


 Reminds me a lot of CS2D, good job! :)


Thank you!
May 18 2022
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote:

 Earlier this year I decided to make a simple shooter game to 
 serve as a tech demo for the engine's capabilities, and also 
 just to get a general idea of how well it works when used in a 
 real application.


Nice game. Would definately be interested in seeing an open 
source D game engine :)

I had the following problems with the game:
- obstacles have unforgiving hit box, making it difficult to move
- I don't have a qwerty keyboard, it doesn't seems like I can 
play on an azert keyboard
- crash when changing map to large (and changing almost all start 
settings too)
May 18 2022
parent reply Kenny Shields <mail kennyshields.net> writes:
On Wednesday, 18 May 2022 at 12:13:57 UTC, Guillaume Piolat wrote:


 Nice game. Would definately be interested in seeing an open 
 source D game engine :)

 I had the following problems with the game:
 - obstacles have unforgiving hit box, making it difficult to 
 move
 - I don't have a qwerty keyboard, it doesn't seems like I can 
 play on an azert keyboard
 - crash when changing map to large (and changing almost all 
 start settings too)


Thank you for playing! Sorry about the crash, is there additional 
info that you can provide (OS, system resources, etc) so that I 
can look into it? It might be that the larger maps are a bit 
unstable (I haven't tested them as much), but you are saying that 
you had some issues with the other game settings as well?

Regarding the hit boxes, you are right, some of them are pretty 
extreme. Not much that I can do about the walls but I should make 
some of the entity-based ones better (like the rocks). Also I'll 
look into adding functionality for changing the keybindings for 
users with non-qwerty layouts.
May 18 2022
parent Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 18 May 2022 at 17:50:37 UTC, Kenny Shields wrote:

 Thank you for playing! Sorry about the crash, is there 
 additional info that you can provide (OS, system resources, 
 etc) so that I can look into it?


No problem.
To reproduce the crash reliably: use a 150x150 map, then click 
repeatedly on the left mouse button while loading (Windows 10).



 It might be that the larger maps are a bit unstable (I haven't 
 tested them as much), but you are saying that you had some 
 issues with the other game settings as well?


While trying to reproduce the above bug, I encountered a pretty 
esoteric one.

I have two 1920x1080p screens setup to duplicate their content.
My untitled shooter game was setup to be 1080p fullscreen, which 
works on one screen.
But when the two screen are there, and in mode "duplicated" (not 
"extends desktop"), then the displayed game is zoomed in and you 
cannot click the menu, which is out of sight.

I have nothing more to report.
May 18 2022
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote:

 This isn't an open-source project, but I wanted to post this 
 here for anyone who might be interested in seeing D used for 
 cross-platform game development. Any questions/comments about 
 the implementation and design of the game/engine are welcome.


Cool game! I got to stage 19. I had no problems with the Linux 
port, except the occasional crash when generating maps that was 
already mentioned.

Some feedback about the game:

- The engine handles 144Hz screens correctly and changes in frame 
rate, well done.

- You can make collision less frustrating by making the player 
slide along the edge of the obstacle partially in the direction 
they're facing. The easiest way to do this is that, when a 
collision happens, instead of preventing movement in the player's 
direction, you allow it to happen, but then as long as the player 
and the obstacle intersects, the obstacle pushes the player out, 
away from its center. Doing this in the same frame will make it 
seem like the player is sliding along the side of the obstacle.

- This game could be almost categorized as a twin-stick shooter, 
though it's not quite so due to only being able to move forward 
in the direction you're aiming. I'm not sure what this constraint 
adds but it does seem very unusual.

- I didn't try all combinations of craftables, but there is 
almost no reason to build a regular turret instead of the tesla 
coil. The tesla coil has a higher DPS/$, never misses, and does 
not have friendly fire.

- Oddly, sprinting energy does not recover when standing still 
but holding Shift.

- "Game seed" seems to affect only the generation of the map 
layout, but not of pickups or your initial position; perhaps 
calling it "map seed" would be more accurate.

- Choosing to play on a larger map seems to be strictly 
disadvantageous, as pickups are more rare due to being more 
spread out.
May 18 2022
parent Kenny Shields <mail kennyshields.net> writes:
On Wednesday, 18 May 2022 at 17:15:44 UTC, Vladimir Panteleev 
wrote:


 Cool game! I got to stage 19. I had no problems with the Linux 
 port, except the occasional crash when generating maps that was 
 already mentioned.


Thanks for playing! Also I think you beat my current phase 
record! Glad to hear that your
experience was good excluding the map crash issue (still looking 
into that).


 - You can make collision less frustrating by making the player 
 slide along the edge of the obstacle partially in the direction 
 they're facing. The easiest way to do this is that, when a 
 collision happens, instead of preventing movement in the 
 player's direction, you allow it to happen, but then as long as 
 the player and the obstacle intersects, the obstacle pushes the 
 player out, away from its center. Doing this in the same frame 
 will make it seem like the player is sliding along the side of 
 the obstacle.


Yes I agree, I think this would be the proper approach to 
handling collision. I actually made an attempt to implement this 
method a while back but never finished it. I think I'll re-visit 
this now to see if it can replace the current implementation.


 - This game could be almost categorized as a twin-stick 
 shooter, though it's not quite so due to only being able to 
 move forward in the direction you're aiming. I'm not sure what 
 this constraint adds but it does seem very unusual.


I've had a lot of feedback about the movement being strange and 
it definitely is compared to traditional movement schemes, though 
I think it works well enough for how simplistic the game is. I 
may look into changing it in the future but I have a feeling that 
the movement will feel less strange if the collision is reworked 
as you suggested previously.


 - I didn't try all combinations of craftables, but there is 
 almost no reason to build a regular turret instead of the tesla 
 coil. The tesla coil has a higher DPS/$, never misses, and does 
 not have friendly fire.


Admittadley I didn't put much thought into some of the craftables 
and how it melds with the gameplay, a lot of it was basically me 
getting an idea and thinking "Oh that would be cool" and then 
throwing it in. Turrets were the original defensive craftable 
that I had added, and once coils came along they definitely fell 
by the wayside. I'll be revisiting these at some point to see 
what can be done.


 - Oddly, sprinting energy does not recover when standing still 
 but holding Shift.


Good catch, I'll add a fix for that.


 - "Game seed" seems to affect only the generation of the map 
 layout, but not of pickups or your initial position; perhaps 
 calling it "map seed" would be more accurate.


Originally it was actually called "Map Seed" and was really only 
used for the map. I recently changed it to "Game Seed" because 
I'm actually passing the engine's generator 
(MersenneTwisterEngine instance that actually takes the seed) to 
all of the "chance" based areas of the game logic, things like 
enemy type when spawning, crate types and what not, so it 
definitely should be influencing things beyond the map 
generation. I wonder if maybe the generator isn't properly being 
reseeded when creating a new game after a previous game? 
Regardless I take a look to see what the deal is.


 - Choosing to play on a larger map seems to be strictly 
 disadvantageous, as pickups are more rare due to being more 
 spread out.


For sure, there unfortunately isn't really anything in the logic 
to adjust for gameplay on larger maps. Honestly I really only put 
different map sizes in there to add some variance in what the 
player was able to choose from, but I'm starting to wonder if a 
better approach would be to meet in the middle with a "medium" 
size map and just design the gameplay around that.
May 18 2022
prev sibling next sibling parent JN <666total wp.pl> writes:
On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote:

 Hello,

 I've been building a game engine in D for the past 2 and a half 
 years and have finally reached a point where it's usable in 
 day-to-day game development. Earlier this year I decided to 
 make a simple shooter game to serve as a tech demo for the 
 engine's capabilities, and also just to get a general idea of 
 how well it works when used in a real application. I did an 
 initial release of the game yesterday on itch.io, you can find 
 more information on the product page if you are interested: 
 https://kenny-shields.itch.io/untitled-shooter-game


Looks great! I used to make a game in a similar style, but never 
really got further than having a guy walking around: 
https://www.youtube.com/watch?v=kgIUXiFuJkc
May 18 2022
prev sibling next sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote:

 Hello,

 I've been building a game engine in D for the past 2 and a half 
 years and have finally reached a point where it's usable in 
 day-to-day game development. Earlier this year I decided to 
 make a simple shooter game to serve as a tech demo for the 
 engine's capabilities, and also just to get a general idea of 
 how well it works when used in a real application. I did an 
 initial release of the game yesterday on itch.io, you can find 
 more information on the product page if you are interested: 
 https://kenny-shields.itch.io/untitled-shooter-game

 This isn't an open-source project, but I wanted to post this 
 here for anyone who might be interested in seeing D used for 
 cross-platform game development. Any questions/comments about 
 the implementation and design of the game/engine are welcome.

 On a side note, I'd like to give special thanks to Walter and 
 all of you who who contribute to D to make it what it is today. 
 D is a fantastic language and really can't see myself using 
 anything else for development at this point. Also, shout-out to 
 the LDC developers as well, really great compiler.


It's pretty cool, however I can suggest you to improve the 
controls. It's pretty easy to get struck on walls, character can 
only go forward (or there's something really wrong on my end), 
menus are a bit confusing, etc.

I'm also a game developer, working on an engine 
(PixelPerfectEngine) and a lot of open-source libraries intended 
for game and app development (latest is iota, a D language native 
input-output handling library, currently stuck with window 
management). I'm also working on my first game, although a lot of 
my time and energy getting wasted on an underpaid day-job.
May 18 2022
prev sibling parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote:

 Hello,

 I've been building a game engine in D for the past 2 and a half 
 years and have finally reached a point where it's usable in 
 day-to-day game development. Earlier this year I decided to 
 make a simple shooter game to serve as a tech demo for the 
 engine's capabilities, and also just to get a general idea of 
 how well it works when used in a real application. I did an 
 initial release of the game yesterday on itch.io, you can find 
 more information on the product page if you are interested: 
 https://kenny-shields.itch.io/untitled-shooter-game

 This isn't an open-source project, but I wanted to post this 
 here for anyone who might be interested in seeing D used for 
 cross-platform game development. Any questions/comments about 
 the implementation and design of the game/engine are welcome.

 On a side note, I'd like to give special thanks to Walter and 
 all of you who who contribute to D to make it what it is today. 
 D is a fantastic language and really can't see myself using 
 anything else for development at this point. Also, shout-out to 
 the LDC developers as well, really great compiler.


Congratulations! Would you consider presenting the game and your 
experience with D in an oral presentation at Dconf? I think this 
sort of material would interest a lot of people in the community. 
All you need to do is put up a small description of the project 
and send it to social dlang.org. If it gets selected you could 
participate to dconf for free + all your expenses regarding the 
trip (flight + accommodation) will be paid by the Foundation. For 
more info check [1]. The deadline should have been 15 May but 
late submissions might be considered too.

Cheers,
RazvanN


[1] https://dconf.org/2022/index.html#schedule
May 19 2022
parent reply Kenny Shields <mail kennyshields.net> writes:
On Thursday, 19 May 2022 at 10:29:50 UTC, RazvanN wrote:


 Congratulations! Would you consider presenting the game and 
 your experience with D in an oral presentation at Dconf? I 
 think this sort of material would interest a lot of people in 
 the community. All you need to do is put up a small description 
 of the project and send it to social dlang.org. If it gets 
 selected you could participate to dconf for free + all your 
 expenses regarding the trip (flight + accommodation) will be 
 paid by the Foundation. For more info check [1]. The deadline 
 should have been 15 May but late submissions might be 
 considered too.

 Cheers,
 RazvanN


 [1] https://dconf.org/2022/index.html#schedule


Thanks! Unfortunately I won't be able to attend DConf, but it's 
looking like I should be able to submit something for DConf 
online later in the year.
May 20 2022
parent reply Kenny Shields <mail kennyshields.net> writes:
Just released an update that addresses the crashing and collision 
issues: 
https://kenny-shields.itch.io/untitled-shooter-game/devlog/383345/genera
-update-2022-05-20. For those interested in future updates to the game, you
should be able to follow the project on itch.io if you have an account.

Also, something that I forgot to mention (since this forum is 
geared toward developers), you can access the engine's console by 
hold LCtrl-Shift-Tilde. From there, you can type console.help to 
see a list of commands. If you are interested in seeing some of 
the engine's internals at work, type the command "dev.settings" 
to see a list of development settings that you can toggle.
May 20 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 5/20/22 16:24, Kenny Shields wrote:


 an update that addresses the crashing


Anything interesting there? Why was it crashing?

Ali
May 20 2022
parent reply Kenny Shields <mail kennyshields.net> writes:
On Friday, 20 May 2022 at 23:42:49 UTC, Ali Çehreli wrote:


 Anything interesting there? Why was it crashing?

 Ali


Array bounds violation, though not a D array. Essentially, the 
minimap (which basically boils down to a C++ std::vector managed 
by SFML) was not being resized when changing map sizes. Thus, 
when generating a map larger than the previously generated one, 
the minimap manager would try to update parts of the vector that 
did not exist.
May 20 2022
parent reply electricface <electricface qq.com> writes:
On Saturday, 21 May 2022 at 00:40:13 UTC, Kenny Shields wrote:

 On Friday, 20 May 2022 at 23:42:49 UTC, Ali Çehreli wrote:


 Anything interesting there? Why was it crashing?

 Ali


 Array bounds violation, though not a D array. Essentially, the 
 minimap (which basically boils down to a C++ std::vector 
 managed by SFML) was not being resized when changing map sizes. 
 Thus, when generating a map larger than the previously 
 generated one, the minimap manager would try to update parts of 
 the vector that did not exist.


./Untitled_Shooter_Game-x86_64.AppImage                           
               22:17:01
/tmp/.mount_UntitlnBkgME/usr/bin/usg: 
/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
(required by 
/tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/liblua5.3.so.0)
/tmp/.mount_UntitlnBkgME/usr/bin/usg: 
/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
(required by 
/tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/libsqlite3.so.0)

fail to run it.
Jun 28 2022
parent reply Kenny Shields <mail kennyshields.net> writes:
On Tuesday, 28 June 2022 at 14:19:14 UTC, electricface wrote:


 ./Untitled_Shooter_Game-x86_64.AppImage                         
                 22:17:01
 /tmp/.mount_UntitlnBkgME/usr/bin/usg: 
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
 (required by 
 /tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/liblua5.3.so.0)
 /tmp/.mount_UntitlnBkgME/usr/bin/usg: 
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
 (required by 
 /tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/libsqlite3.so.0)

 fail to run it.


What distribution/version of Linux are you using?
Jun 28 2022
next sibling parent reply electricface <electricface qq.com> writes:
On Tuesday, 28 June 2022 at 22:10:00 UTC, Kenny Shields wrote:

 On Tuesday, 28 June 2022 at 14:19:14 UTC, electricface wrote:


 ./Untitled_Shooter_Game-x86_64.AppImage                        
                  22:17:01
 /tmp/.mount_UntitlnBkgME/usr/bin/usg: 
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not 
 found (required by 
 /tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/liblua5.3.so.0)
 /tmp/.mount_UntitlnBkgME/usr/bin/usg: 
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not 
 found (required by 
 /tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/libsqlite3.so.0)

 fail to run it.


 What distribution/version of Linux are you using?


A debian based system.
the version of libc6 is low, should you include the corresponding 
version of libc6 in the appImage?

dpkg -s libc6:amd64                                               
                                               09:03:11
Package: libc6
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 12339
Maintainer: GNU Libc Maintainers <debian-glibc lists.debian.org>
Architecture: amd64
Multi-Arch: same
Source: glibc
Version: 2.28.19-1+dde
Replaces: libc6-amd64
Depends: libgcc1
Recommends: libidn2-0 (>= 2.0.5~)
Suggests: glibc-doc, debconf | debconf-2.0, libc-l10n, locales
Breaks: hurd (<< 1:0.5.git20140203-1), libtirpc1 (<< 0.2.3), 
locales (<< 2.28.19), locales-all (<< 2.28.19), nocache (<< 
1.1-1~), nscd (<< 2.28.19), r-cran-later (<< 0.7.5+dfsg-2)
Conflicts: openrc (<< 0.27-2~)
Conffiles:
  /etc/ld.so.conf.d/x86_64-linux-gnu.conf 
d4e7a7b88a71b5ffd9e2644e71a0cfab
Description: GNU C Library: Shared libraries
  Contains the standard libraries that are used by nearly all 
programs on
  the system. This package includes shared versions of the 
standard C library
  and the standard math library, as well as many others.
Homepage: https://www.gnu.org/software/libc/libc.html
Jun 28 2022
parent electricface <electricface qq.com> writes:
On Wednesday, 29 June 2022 at 01:07:01 UTC, electricface wrote:

 On Tuesday, 28 June 2022 at 22:10:00 UTC, Kenny Shields wrote:

 On Tuesday, 28 June 2022 at 14:19:14 UTC, electricface wrote:


 ./Untitled_Shooter_Game-x86_64.AppImage                       
                   22:17:01
 /tmp/.mount_UntitlnBkgME/usr/bin/usg: 
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not 
 found (required by 
 /tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/liblua5.3.so.0)
 /tmp/.mount_UntitlnBkgME/usr/bin/usg: 
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not 
 found (required by 
 /tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/libsqlite3.so.0)

 fail to run it.


 What distribution/version of Linux are you using?


 A debian based system.
 the version of libc6 is low, should you include the 
 corresponding version of libc6 in the appImage?

 dpkg -s libc6:amd64                                             
                                                 09:03:11
 Package: libc6
 Status: install ok installed
 Priority: optional
 Section: libs
 Installed-Size: 12339
 Maintainer: GNU Libc Maintainers <debian-glibc lists.debian.org>
 Architecture: amd64
 Multi-Arch: same
 Source: glibc
 Version: 2.28.19-1+dde
 Replaces: libc6-amd64
 Depends: libgcc1
 Recommends: libidn2-0 (>= 2.0.5~)
 Suggests: glibc-doc, debconf | debconf-2.0, libc-l10n, locales
 Breaks: hurd (<< 1:0.5.git20140203-1), libtirpc1 (<< 0.2.3), 
 locales (<< 2.28.19), locales-all (<< 2.28.19), nocache (<< 
 1.1-1~), nscd (<< 2.28.19), r-cran-later (<< 0.7.5+dfsg-2)
 Conflicts: openrc (<< 0.27-2~)
 Conffiles:
  /etc/ld.so.conf.d/x86_64-linux-gnu.conf 
 d4e7a7b88a71b5ffd9e2644e71a0cfab
 Description: GNU C Library: Shared libraries
  Contains the standard libraries that are used by nearly all 
 programs on
  the system. This package includes shared versions of the 
 standard C library
  and the standard math library, as well as many others.
 Homepage: https://www.gnu.org/software/libc/libc.html


Possibly you can reproduce it using debian buster.
Jun 28 2022
prev sibling parent electricface <electricface qq.com> writes:
On Tuesday, 28 June 2022 at 22:10:00 UTC, Kenny Shields wrote:

 On Tuesday, 28 June 2022 at 14:19:14 UTC, electricface wrote:


 ./Untitled_Shooter_Game-x86_64.AppImage                        
                  22:17:01
 /tmp/.mount_UntitlnBkgME/usr/bin/usg: 
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not 
 found (required by 
 /tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/liblua5.3.so.0)
 /tmp/.mount_UntitlnBkgME/usr/bin/usg: 
 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not 
 found (required by 
 /tmp/.mount_UntitlnBkgME/usr/lib/x86_64-linux-gnu/libsqlite3.so.0)

 fail to run it.


 What distribution/version of Linux are you using?


After putting the libm.so.6 of the higher version of libc6, it 
can be run.
Jun 28 2022