5 ms·
3d engine is very structured, it isn't the creative part of game development. Lets say you want to test your bullets having HP and can be shot down. So you add
by Jensson 4y ago
3d engine is very structured, it isn't the creative part of game development.
Lets say you want to test your bullets having HP and can be shot down. So you add that in an hour, now bullets have HP, you test it, it doesn't work, so you remove it. Things like that needs to be seamless, because you need to iterate on ideas and test if things are fun. Big upfront design as you suggest where you very carefully constrain everything doesn't do well with that. It works well for 3d engines for example sure, but 3d engines are much more constrained than games.
- louthy 4y ago> 3d engine is very structured, it isn't the creative part of game development. I also did lots of the creative bit ;). I just assumed this was going to go down a performance route question, sorry! > Big upfront design as you suggest No, I am not suggesting that at all - I'm saying the opposite of that. You're the third person to think that's what I am saying now, so I assume I didn't explain myself very well. Rather than repeat myself again, my other replies cover this [1] [2]: [1] https://news.ycombinator.com/item?id=34847413 https://news.ycombinator.com/item?id=34847413 [2] https://news.ycombinator.com/item?id=34847326 https://news.ycombinator.com/item?id=34847326
- Jensson 4y agoWell, you say that works, but basically nobody who programs creatively writes code that way. People who like functional programming mostly writes compilers or similar processing throughput systems, you see it a ton there, but you barely see it on the other side of the programming landscape such as game programming. So, you say it works for you, but basically every example of the things I talked about are done in a very different way than you describe, so unless you have programmed some very impressive games I would say that the data strongly supports another style of programming than you suggest here. For compilers or parsers or stuff like medical systems? Sure, go ahead, it seems to work for those domains, but it doesn't seem to be a panacea. If games were so much easier to write that way we would see tons of them, especially among the better games, but we don't.
- louthy 4y agoThe biggest mistake you make is thinking you do something different to me or any other software engineer. You don't. You do the same thing and the same rules apply. You seem to think you're the only person doing anything creative. Well here's a newsflash: it's the same process in games as it is in all other forms of software development. The end result might look different, but the process is the same. The best devs are the creative ones, but creativity isn't limited to what appears on the screen, it comes from architecting complex solutions to difficult problems, it comes from elegance in code, and it comes from producing something that works for the end-user - whether that's a gamer, a doctor, or someone browsing on their phone. Games is one of the easiest sectors to be in, the complexity level is low compared to other sectors, especially now all the difficult bits are done for you (off the shelf engines). I assume you're not working on titles that have 15 million lines of code in, like I do every day. That is possibly why there hasn't been a big push for FP in games yet, because they haven't yet hit the complexity limit of OO like others have. Your argument is "Well we've always done it like this, why change?". Probably for the same reason people don't write games in assembly languages any more: at some point the current tools aren't good enough. Games might not have hit that ceiling yet, but you'll almost certainly be affected by the artefacts of getting close to it. I see you're even questioning my history in games. Below [1][2][3][4][5][6][7][8] are some of the titles I worked on (or my code is in). But to be clear, we didn't use these techniques back then either, because it was too soon to be doing it (or we weren't enlightened then). You should consider being a little more open minded about how you could, possibly, write software more effectively. Especially when you have someone who's been on both sides of the fence advocating it. Just writing it off because you think people who do FP just write "compilers or similar processing throughput systems" is shooting yourself in the foot more than anything. [1] Battalion Wars: https://en.wikipedia.org/wiki/Battalion_Wars https://en.wikipedia.org/wiki/Battalion_Wars [2] Fire Blade: https://en.wikipedia.org/wiki/Fire_Blade_(video_game) https://en.wikipedia.org/wiki/Fire_Blade_(video_game) [3] Warmhammer 40,000 Fire Warrior: https://en.wikipedia.org/wiki/Warhammer_40%2C000%3A_Fire_Warrior https://en.wikipedia.org/wiki/Warhammer_40%2C000%3A_Fire_War... [4] Call of Duty - Finest Hour: https://en.wikipedia.org/wiki/Call_of_Duty:_Finest_Hour https://en.wikipedia.org/wiki/Call_of_Duty:_Finest_Hour [5] The Regiment: https://en.wikipedia.org/wiki/The_Regiment_(video_game) https://en.wikipedia.org/wiki/The_Regiment_(video_game) [6] Reign of Fire: https://en.wikipedia.org/wiki/Reign_of_Fire_(video_game) https://en.wikipedia.org/wiki/Reign_of_Fire_(video_game) [7] Attack of the Saucerman: https://en.wikipedia.org/wiki/Attack_of_the_Saucerman https://en.wikipedia.org/wiki/Attack_of_the_Saucerman [8] Lunatik [canned]: https://www.unseen64.net/2020/11/16/lunatik-pure-entertainment-cancelled/ https://www.unseen64.net/2020/11/16/lunatik-pure-entertainme...