Re: A New Game Written in D
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.
Re: A New Game Written in D
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.
Re: A New Game Written in D
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.
Re: A New Game Written in D
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.
Re: A New Game Written in D
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
Re: A New Game Written in D
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.
Re: A New Game Written in D
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
Re: A New Game Written in D
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
Re: A New Game Written in D
On Wednesday, 18 May 2022 at 06:09:06 UTC, bauss wrote: Reminds me a lot of CS2D, good job! :) Thank you!
Re: A New Game Written in D
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.
Re: A New Game Written in D
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?
Re: A New Game Written in D
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.
Re: A New Game Written in D
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!
Re: A New Game Written in D
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)
Re: A New Game Written in D
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! :)
