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