Lostcast 87


  • Patron

    First, welcome back! I’m glad you are having success and took a vacation.

    I think some of your complaints about your tech stack are valid, while some are invalid. My thoughts…

    -Your premise of a tech stack having features you don’t use is flawed. There is essentially only one bad aspect of shipping unused code: It makes your binary bigger than it needs to be. The fact you aren’t using your own servers to ship the product (you use Humble and Steam) makes the problem even less of a big deal. You could argue that HTML5 takes it to the extreme. The entirety of your art, music, and code compresses to ~20 MB, and your installer is 42MB. That is a pile of bloat. Maybe it really is a bit much. Still, I’d argue that point is minor. An additional 50 MB of bloat is not going to stop a gamer if the game is good. As long as the canvas tag runs well, who cares if you don’t ever use DOM. Unused code does not harm.

    -Yes, HTML5 JavaScript has flaws, but so does PyGame. I can assure you that the canvas tag is getting supremely more attention by well-paid developers than PyGame. Nothing wrong with PyGame, but I am not convinced that A Wizard’s Lizard would run all that great on it. Perhaps my Python skills were weak when I tried it out years ago, and maybe it has improved. I know made far faster progress when I switched to HTML5.

    -You made a very valid point about 90% of your revenue is the Windows desktop. There are native-level toolkits that you can use that would really squeeze performance. I find it interesting you are using HTML5 and just focusing on the desktop. HTML5’s two biggest selling points is that it is cross-platform and uses JavaScript. Since cross-platform is not that an issue for you, I assume you are mostly using HTML5 because you like JavaScript. I am surely very impressed at what you have done with AWL with it.

    If you do decide to switch to another stack, C++ actually is not that bad if you have a good toolkit on top of it (like Boost or Qt). Please don’t switch to Game Maker.

    Quick edit: Wow, I just read my post, and I sound angry. I am not. I enjoyed the podcast. I was joining the conversation and offering my thoughts.


  • LDG

    @dannagle said:

    Your premise of a tech stack having features you don’t use is flawed. There is essentially only one bad aspect of shipping unused code: It makes your binary bigger than it needs to be.

    My concern is that the all the other things that the web browser needs to do related to DOM and CSS are hindering the performance of the canvas tag. I don’t know that for sure, but that’s my hunch.

    Yes, HTML5 JavaScript has flaws, but so does PyGame. I can assure you that the canvas tag is getting supremely more attention by well-paid developers than PyGame.

    Definitely a good point. ALL stacks have their weaknesses. I don’t know much about PyGame specifically, but, again, my feeling was that it might be faster if the canvas calls were going into a layer specifically designed for drawing graphics to the screen. (As opposed to the canvas tag within the DOM meant for rendering lots of various content). @Josue and @Affordable_Desk also brought up some great points in another thread about how the bottleneck might be the JavaScript->C++ bridge and thus a Node.js/SDL stack might also suffer the same performance issues.

    You made a very valid point about 90% of your revenue is the Windows desktop. There are native-level toolkits that you can use that would really squeeze performance. I find it interesting you are using HTML5 and just focusing on the desktop. HTML5’s two biggest selling points is that it is cross-platform and uses JavaScript. Since cross-platform is not that an issue for you, I assume you are mostly using HTML5 because you like JavaScript. I am surely very impressed at what you have done with AWL with it.

    I think this hits the nail on the head. I loooooove JavaScript and I’ve got a lot of experience using it. On the cross-platform side though, we do benefit from being able to deploy on Windows, OSX, and Linux fairly easily. I’m sure we’d have more problems trying to port a .NET/Mono game to non-Windows platforms. I believe that Escape Goat 2 was written using Mono and its OSX port is definitely not up to par with the Windows original.

    If you do decide to switch to another stack, C++ actually is not that bad if you have a good toolkit on top of it (like Boost or Qt). Please don’t switch to Game Maker.

    I think if we did switch (which is rather unlikely) C++ on SDL might be a good choice. I don’t know that I’m ever going to feel comfortable with higher level IDEs like Game Maker or Unity. I felt the same way about Flash. I am really interested in working on a proof of concept with Node.js and SDL so I can put my brain to rest.

    Quick edit: Wow, I just read my post, and I sound angry. I am not. I enjoyed the podcast. I was joining the conversation and offering my thoughts.

    Totally! Didn’t come across as angry at all.


  • LDG

    Well I had a reply all geared up but then @geoffb said exactly what I was going to. GET OUT OF MY HEQD!

    Really appreciate the feedback, feels great to know that awesome devs are listening :)


  • Patron

    I once wrote a daemonized TCP server using Python. It choked once I got to around 10 concurrent connections. CPU was spiked with nothing to do but hold the socket open and wait for commands. I rewrote the whole thing in plain C Berkeley sockets. I was up to around 50 concurrent connections, and the CPU was still just idle. I stopped the test, and even though it required far more work, I declared C/C++ the winner for writing network servers. That is why I expressed strong doubts about PyGame performance. Here is a 4-year-old test I did with it: http://dannagle.com/2010/03/python-sidescroller/ Performance was horrible. Source code is included on the page if you wish to glance at it.

    Python is great because it is a nice cross-platform interpretive language with a lot of modules available. It gets bonus points because it is default-available on Linux and Mac (though it is the Python 2 branch). If you are switching to Python because you think it is fast and efficient, I am afraid you will be disappointed.


  • LDG

    @dannagle To be clear, we’re not thinking of switching to PyGame. I’m using PyGame as an example of the concept of Dynamic/Scripting language -> Native Bridge -> SDL. If we ever did go that route, it’d be Node.js on SDL, not Python. Not a big fan of whitespace significant languages. :)

    Your concerns about performance though might also exist in the Node.js flavor if the bottleneck is the native bridge. I wonder if V8 is faster than the Python engine, though?



  • After listening to episode 87, I really want to spend some quality time researching node-webkit, atom-shell, chromium, etc. to see if there are any forks that attempt to strip down the code to focus on the canvas. Don’t know how to put that in words, but I’m sure after I research this beyond “I THINK SOUND GOOD”, I’ll have a better understanding of what I’m hoping already exists.

    Good episode guys!


  • LDG

    @Faison Thanks! The recent popularity in the web based desktop app space is great. I’m really interested in spending more time with Atom Shell as it seems to be more frequently updated and benefits from an engaged corporate sponsor (GitHub).


  • LDG

    Just a few years ago we were eagerly pouncing on any new technology that popped up, offering the promise of desktop HTML5 apps. First was Titanium, which felt over-engineered and was laughably slow. A slow, steady drip of new projects came and went, and each one we’d investigate, kick the tires, and walk away disappointed. It’s so great now to see that we not only have a solid, proven option, but there’s also competition. And there are even better ideas on the horizon!


Log in to reply