6 ms·

I really like watching other people do game dev from scratch. If this is a space you’re into and are fine with an nonstandard opinionated developer, I’d recomme

I really like watching other people do game dev from scratch. If this is a space you’re into and are fine with an nonstandard opinionated developer, I’d recommend Molly Rocket’s YouTube channel. However; I shutter in horror at the thought of embarking on this journey for myself. This is a statement about me rather than a general statement. I know I fixate on problems and “perfect” solutions at the detriment of my project’s velocity e.g. TDD for my game projects —- especially since most tutorial code isn’t written with testing in mind. I highly suspect I would be doomed to misery if I tried. Maybe if/when I get more skilled. I feel like projects like these are an expression of programmers who are very comfortable and experienced with writing complex systems.

themodelplumber 3y ago
I find that I tend to get to the interactivity parts of gamedev and go "maybe it'd be neat if this ran itself as a simulation". ChatGPT even wrote a game for me and I thought the same then. I think this might be related to why I write so many dashboards as a hobby. Spectating is pretty cool by itself perhaps?
hutzlibu 3y ago
" I know I fixate on problems and “perfect” solutions at the detriment of my project’s velocity" I have the same, which is why my current game is still not released. Perfectionism made me reject all existing engines and write my own (I do use a physics libary, box2d, but actually am thinking about writing my own soon). I am happy with the result now, but I really had to learn to cut corners and abolish perfectionism again. And now that WebGPU has come out(I programm on the web), I have to restrain myself to not overhaul everything again, because the GPU would unlock so much more power, making awesome new things possible in the simulation beneath.. So I am just doing one simple wgsl module to speed up one important part of the simulation, giving hopefully great performance improvements. And then do it all differently and right with the next game.. "Maybe if/when I get more skilled." And the alternative would be tonstart now, making a very simple game, or using an existing engine. It depends what you want to do. If you are really into complex systems, then yes - making everything from scratch, UI, Game logic, Rendering - then it all really gets complicated soon and if you didn't start right, you will never finish. But a simple game, like a flappy birds clone or something alike, is not too complicated and will tell you, if you are really into it. Just give it a try in a language you are comfortable with. And of course there is no shame in using the right frameworks, libaries and engines, if you mainly want to get stuff done and play the result (which is very rewarding). Or rather, if you really want to ship a game, that runs stable and bugfree also on other peoples computers, then you will have to use existing work, or you won't get far, or will be buisy with it for a looong time, if you want to do anything not trivial.
- pcblues 3y ago
  This is an interesting viewpoint. I might suggest prototyping game ideas with an existing "game creation" tool, even something like roblox. Then one has multiple pathways for their design to progress - world design, interaction, story, events, as well as engine. And one can much more easily test out different aspects of graphics and physics to see which their game engine needs or demands. There is also the ability to code engine algorithms directly and tweak so many variables in the prototyping stage, that the resulting parameters/functionality can be brought back into the actual custom game codebase.
  - hutzlibu 3y ago
    I started game dev with flash, which was excellent for rapid prototyping and is still unmatched for casual games. But OP especially wanted the hard way of doing it from scratch..
- sovietmudkipz 3y ago
  As someone who creates games for web consumption, thanks for being interested in the topic. Truly thanks. If I had to write low level WebGL (and now web GPU) code I simply wouldn’t do it. It’s hard enough creating at the higher level of abstraction of my game engine of choice. It’s just a bridge too far in my mind. I’m now waiting for interested engineers like you to update Unity to enable use of web GPU. I embrace that it’s not a topic I want to care about as a creator, but instead as a consumer.
  - hutzlibu 3y ago
    The thing with WebGPU is, that it is a very different way of programming, so you cannot just enable it and benefit from it coding the way you are used to. Because the GPU are in fact lots of small cpus, meaning if you want performant code, it has to run parallel. And then the fun starts with sharing ressources, coordinating etc. So the code and data has to be structured very carefully, if you want actual improvements. And this is not new to me, but I have never done it for something serious, so far. So for my intended use case is should work, as I need to do lots of raycasting and this is where GPUs shine. (But I still need to figure out the compute pipeline) But in fact, I do intend to work something out, enabling other people to make use of it without having to do the deep dive. At least in some cases ..
WhereIsTheTruth 3y ago
forget TDD when you make a game, you want fast iteration time at all cost, gameplay is king, if you can't nail it fast enough, you'll make a bad game that is not fun it's all about the feeling Celeste's player class: https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs https://github.com/NoelFB/Celeste/blob/master/Source/Player/... https://store.steampowered.com/app/504230/Celeste/ https://store.steampowered.com/app/504230/Celeste/
- berkle4455 3y ago
  100%. tbh if you want to deliver value in any scenario you skip TDD and anything that smells of agile or scrum. Just deliver.
  - jstarfish 3y ago
    Yes. Your userbase will not give a single shit about how thoroughly tested your game is or how elegant your code is. Mainly since you'll give up on it long before they ever see it. It's a game. Treat it like one. TDD is great for your day job, where you ship bulletproof software for work. Nobody does work for fun. Look at how many games are written in Java. For a personal project, only write unit tests to ensure specific bugs get fixed. No more. This ensures you do the least possible amount of Work. In the end, you'll say holy shit, I have a ton of bugs to fix-- that guy was full of shit. But you'll have a functional game to fix the bugs on within a year, rather than a pile of exquisite code that does nothing after a decade.
    - unlikelytomato 3y ago
      sounds very similar to the arguments made against tests in a work setting. Test as appropriate for your needs and goals. Adjust over time. There is no need to artificiality skew the balance in either setting.
      - jstarfish 3y ago
        > sounds very similar to the arguments made against tests in a work setting I tried to be clear about that. Sloppiness at work could kill someone or bankrupt the company. You're being paid to be a professional, so be a professional and write tests. You only have so much free time to achieve your dreams. Cut every corner you can to make it happen.
jezzamon 3y ago
You should try doing a game jam (or, multiple!) You have an extremely short time frame, and each time you start from scratch so you learn what systems work and what doesn't in a practical way that doesn't allow for perfectionism. I've probably implemented platformers physics about 15 times now, and have a pretty good idea of how I personally like structuring game code.
- sovietmudkipz 3y ago
  I do game jams and you’re right about their benefits. I’ve done them using TDD as an inexperienced game dev, test free, TDD now that I have more experience, and it’s helped me clarify some of my own thoughts on how automated testing can fit into my workflow.
duxueudyef 3y ago
I think you give game dev too much credit. Is full of unmaubtainable code that will never be used in another game and has bugs that don’t affect the primary goal of fun. Learn to love the spaghetti and embrace not knowing what half the stuff you wrote does the next day. If it’s fun it’s good. There’s only a handful of long duration games under active development anyway.
pjmlp 3y ago
My favourite trap question for conferences is how to TDD GUI and game development, every single aspect of it. Don't write any kind of code, none of it, without a failing test first is the motto.
- nine_k 3y ago
  There is a perfect and apt answer: keep playing the game (prototype) you are developing! Not only does it test your game under sort of realistic conditions; it also gives you constant feedback on whether the game is fun, interesting, engaging — something that's infeasible to test by code.
  - ahtihn 3y ago
    That is not an answer, you are not describing anything close to TDD.
    - nine_k 3y ago
      I think it's the closest thing to TDD you can have developing a game proper. Development of a game engine is a different matter, and affords itself to classical TDD, to my mind. You can write formal tests ahead of time, because you can feasibly understand what you want to be implement before you implement that.
      - pjmlp 3y ago
        Try to TDD a shader pipeline workflow. No code before a red unit test.
  - rsaarelm 3y ago
    This exercises the happy path, but otherwise works surprisingly badly for testing. You already know what the game is supposed to be about, so you can't really tell how well the interface communicates things to someone who doesn't, and you more or less automatically play it the way you're "supposed to", so you rarely hit the sorts of buggy or game breaking corner cases testing is supposed to discover.

themodelplumber 3y ago

I find that I tend to get to the interactivity parts of gamedev and go "maybe it'd be neat if this ran itself as a simulation". ChatGPT even wrote a game for me and I thought the same then. I think this might be related to why I write so many dashboards as a hobby. Spectating is pretty cool by itself perhaps?

hutzlibu 3y ago

" I know I fixate on problems and “perfect” solutions at the detriment of my project’s velocity" I have the same, which is why my current game is still not released. Perfectionism made me reject all existing engines and write my own (I do use a physics libary, box2d, but actually am thinking about writing my own soon). I am happy with the result now, but I really had to learn to cut corners and abolish perfectionism again. And now that WebGPU has come out(I programm on the web), I have to restrain myself to not overhaul everything again, because the GPU would unlock so much more power, making awesome new things possible in the simulation beneath.. So I am just doing one simple wgsl module to speed up one important part of the simulation, giving hopefully great performance improvements. And then do it all differently and right with the next game.. "Maybe if/when I get more skilled." And the alternative would be tonstart now, making a very simple game, or using an existing engine. It depends what you want to do. If you are really into complex systems, then yes - making everything from scratch, UI, Game logic, Rendering - then it all really gets complicated soon and if you didn't start right, you will never finish. But a simple game, like a flappy birds clone or something alike, is not too complicated and will tell you, if you are really into it. Just give it a try in a language you are comfortable with. And of course there is no shame in using the right frameworks, libaries and engines, if you mainly want to get stuff done and play the result (which is very rewarding). Or rather, if you really want to ship a game, that runs stable and bugfree also on other peoples computers, then you will have to use existing work, or you won't get far, or will be buisy with it for a looong time, if you want to do anything not trivial.

pcblues 3y ago
This is an interesting viewpoint. I might suggest prototyping game ideas with an existing "game creation" tool, even something like roblox. Then one has multiple pathways for their design to progress - world design, interaction, story, events, as well as engine. And one can much more easily test out different aspects of graphics and physics to see which their game engine needs or demands. There is also the ability to code engine algorithms directly and tweak so many variables in the prototyping stage, that the resulting parameters/functionality can be brought back into the actual custom game codebase.
- hutzlibu 3y ago
  I started game dev with flash, which was excellent for rapid prototyping and is still unmatched for casual games. But OP especially wanted the hard way of doing it from scratch..
sovietmudkipz 3y ago
As someone who creates games for web consumption, thanks for being interested in the topic. Truly thanks. If I had to write low level WebGL (and now web GPU) code I simply wouldn’t do it. It’s hard enough creating at the higher level of abstraction of my game engine of choice. It’s just a bridge too far in my mind. I’m now waiting for interested engineers like you to update Unity to enable use of web GPU. I embrace that it’s not a topic I want to care about as a creator, but instead as a consumer.
- hutzlibu 3y ago
  The thing with WebGPU is, that it is a very different way of programming, so you cannot just enable it and benefit from it coding the way you are used to. Because the GPU are in fact lots of small cpus, meaning if you want performant code, it has to run parallel. And then the fun starts with sharing ressources, coordinating etc. So the code and data has to be structured very carefully, if you want actual improvements. And this is not new to me, but I have never done it for something serious, so far. So for my intended use case is should work, as I need to do lots of raycasting and this is where GPUs shine. (But I still need to figure out the compute pipeline) But in fact, I do intend to work something out, enabling other people to make use of it without having to do the deep dive. At least in some cases ..

WhereIsTheTruth 3y ago

forget TDD when you make a game, you want fast iteration time at all cost, gameplay is king, if you can't nail it fast enough, you'll make a bad game that is not fun it's all about the feeling Celeste's player class: https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs https://github.com/NoelFB/Celeste/blob/master/Source/Player/... https://store.steampowered.com/app/504230/Celeste/ https://store.steampowered.com/app/504230/Celeste/

berkle4455 3y ago
100%. tbh if you want to deliver value in any scenario you skip TDD and anything that smells of agile or scrum. Just deliver.
- jstarfish 3y ago
  Yes. Your userbase will not give a single shit about how thoroughly tested your game is or how elegant your code is. Mainly since you'll give up on it long before they ever see it. It's a game. Treat it like one. TDD is great for your day job, where you ship bulletproof software for work. Nobody does work for fun. Look at how many games are written in Java. For a personal project, only write unit tests to ensure specific bugs get fixed. No more. This ensures you do the least possible amount of Work. In the end, you'll say holy shit, I have a ton of bugs to fix-- that guy was full of shit. But you'll have a functional game to fix the bugs on within a year, rather than a pile of exquisite code that does nothing after a decade.
  - unlikelytomato 3y ago
    sounds very similar to the arguments made against tests in a work setting. Test as appropriate for your needs and goals. Adjust over time. There is no need to artificiality skew the balance in either setting.
    - jstarfish 3y ago
      > sounds very similar to the arguments made against tests in a work setting I tried to be clear about that. Sloppiness at work could kill someone or bankrupt the company. You're being paid to be a professional, so be a professional and write tests. You only have so much free time to achieve your dreams. Cut every corner you can to make it happen.

jezzamon 3y ago

You should try doing a game jam (or, multiple!) You have an extremely short time frame, and each time you start from scratch so you learn what systems work and what doesn't in a practical way that doesn't allow for perfectionism. I've probably implemented platformers physics about 15 times now, and have a pretty good idea of how I personally like structuring game code.

sovietmudkipz 3y ago
I do game jams and you’re right about their benefits. I’ve done them using TDD as an inexperienced game dev, test free, TDD now that I have more experience, and it’s helped me clarify some of my own thoughts on how automated testing can fit into my workflow.

duxueudyef 3y ago

I think you give game dev too much credit. Is full of unmaubtainable code that will never be used in another game and has bugs that don’t affect the primary goal of fun. Learn to love the spaghetti and embrace not knowing what half the stuff you wrote does the next day. If it’s fun it’s good. There’s only a handful of long duration games under active development anyway.

pjmlp 3y ago

My favourite trap question for conferences is how to TDD GUI and game development, every single aspect of it. Don't write any kind of code, none of it, without a failing test first is the motto.

nine_k 3y ago
There is a perfect and apt answer: keep playing the game (prototype) you are developing! Not only does it test your game under sort of realistic conditions; it also gives you constant feedback on whether the game is fun, interesting, engaging — something that's infeasible to test by code.
- ahtihn 3y ago
  That is not an answer, you are not describing anything close to TDD.
  - nine_k 3y ago
    I think it's the closest thing to TDD you can have developing a game proper. Development of a game engine is a different matter, and affords itself to classical TDD, to my mind. You can write formal tests ahead of time, because you can feasibly understand what you want to be implement before you implement that.
    - pjmlp 3y ago
      Try to TDD a shader pipeline workflow. No code before a red unit test.
- rsaarelm 3y ago
  This exercises the happy path, but otherwise works surprisingly badly for testing. You already know what the game is supposed to be about, so you can't really tell how well the interface communicates things to someone who doesn't, and you more or less automatically play it the way you're "supposed to", so you rarely hit the sorts of buggy or game breaking corner cases testing is supposed to discover.