Lostcast 176: Mise en Cast
- Spelunky by Derek Yu
- Mise en place
- A Wizard’s Lizard: Soul Thief
- Join us on Discord
- Hello Fresh
- No Man’s Sky
- Lostcast on Patreon
- The Art of Game Design: A book of lenses
- You were played out by Corridor
edit: fix Discord URL
Had this playing while I was cooking tonight actually :).
Have to agree on just getting shit done. I’ve done refactors where I felt it was needed to make things work, and not have changing things cause bugs. My snowball code feels old and gross in some ways, but I still understand it, I can piece it together, so i dont let it bother me too much. My next project I hope to use more ECS stuff, and keep things much cleaner from the get go.
“Always learning” it’s actually the thing I love about not just game programming, but programming in general. There’s always a way to level up and get better at the craft. It’s tricky to get bored. Though the flip side is it can lead to new tech burnout.
There’s a time and a place, I’ve been listening to Rougelike radio, and the presenter has a project that is a 400,000 line python file, he’s considering breaking out into a second one because he’s having trouble getting editors to work with 8meg text files.
He goes on to say that he can’t really backtrack, because his code is self dependent and any change will effect everything he’s worked on since then. I don’t want to think of how some issues are solved.
I’m currently working on a “Single Responsibility” refactor, for much of the reason mentioned above, my original design did most things in a monolithic base class, and as stuff got abstracted out, the chains of ownership became messy, and strange bugs crept in.
a 400,000 line python file
Food Network fans UNITE!
k, because his code is self dependent and any change will effect everything
My solution would be to drop in placeholders such as DEPENDENCY_FILENAME and have a make script concatenate the various files before running the python build.
I thought the book discussion was interesting. I tend to avoid programming books that are more than a year old because I assume all the tech and best practices are out of date. I wonder if that is a bad strategy.
Maybe if Hello Fresh and Adafruit could team up and make Arduino/RasPi kits I can build to automate the preparation of the ingredients and recipe they ship, I would enjoy cooking more. :D
I don’t mind grilling, though. Still … automators gonna automate.
Ponders… then snaps out of it
Rougelike radio, and the presenter has a project that is a 400,000 line python file
@salmonmoose I listened to that episode and it also came to mind for me as well. I think the wrong lesson can be taken from stories like this and the Spelunky example. For every person that ships a game like this, I bet there are hundreds that throw it all out to do it again or had unplayable messes. There’s an element of hubris to it that maybe I need more of, but I tend to think best practices exist for a reason so it’s best to follow them.3
Currently working on http://sparklite.redbluegames.com
@lucasblucas oh, it’s a horrible example for the real world, but there’s a bunch of projects out there that are no different, and they can work. I used to work on a CMS that was essentially the same thing, 1500 odd clients, and a single PHP script. All of the pages and customizations for clients were driven through conditional statements, it was a work of art, in the same way as those elephant paintings are.
There’s certainly a balance between making stuff work, making it pretty, and making it good, and knowing when to refactor is hard but the answer is never “don’t refactor”.
I tend to avoid programming books that are more than a year old because I assume all the tech and best practices are out of date. I wonder if that is a bad strategy.
There are certainly some timeless tomes; The Pragmatic Programmer is a good example, it’s less about explaining systems, and more about being in the right headspace to code. That’s something that hasn’t changed.
This closes in on a discussion in /r/gamedev recently - why are all tutorials so basic? - I feel the same can be said of many textbooks. They teach you the fundamentals, and kind of stop.
You’ll find a tutorial on how to draw a triangle in opengl, and it’ll put all the code in the main loop, and leave you hanging - if you go on from there you end up with a mainloop that does everything - and eventually a 400,000 line script.
There are few tutorials on how to build an application, just how to build the various components - which is exactly what you need if you already know how to build an application. But if you don’t know how to glue things together, and do it well, you end up with 400,000 lines of code. (I’m fairly certain this is his starting point: http://www.roguebasin.com/index.php?title=Complete_Roguelike_Tutorial,_using_python%2Blibtcod,_part_1 )
why are all tutorials so basic