Lostcast 136: Whatever in the World


  • LDG


  • Tiger Hat

    @geoffb “the other day” is very Irish phrase and we definitely use it loosely to mean “any previous day” - drives a lot of my non-Irish friends crazy because the concept of time is hard to figure out :D

    Another popular one is “your man” or “your one” (but pronounced “yer man” or “yer wan”) and they mean “that guy” or “that woman” but doesn’t imply any sort of relationship to them. This annoys some people so they respond with “he’s not my man”.

    e.g. "I would’ve been over sooner but yer man was taking ages to order his drink"
    or, “who does yer wan think she is?”

    Unity - C# vs JS this was actually a question I was going to ask you guys about for a future Lostcast. I have a few friends who tried to stick out doing everything in JS but are quickly making the move to C# because they’re finding it makes life easier. I think while there’s the learning curve it’s often better to go with the “preferred” choice - C# in this case.

    PS cheers for sorting out my account :)


  • Patron

    You could still put all your big art stuff in to Git. When the repo starts to get really bloated and slow, you can blast the git repo and start fresh when you two reach milestones.

    If Geoff doesn’t want to lose C# commit history, you can have your own art repo that you periodically restart at certain milestones. I’m not an artist, but I suspect commit history is not as important for binary art files.

    The important takeaway is that disk space is cheap. Your art is not.


  • Jammer

    @geoffb
    Within this podcast you briefly went over how Unity uses an entity component system that holds some or all of the logic affecting the entity within the component itself. This, as you mentioned, is not in line with your opinion of the “Bags of Data” methodology, which you’ve spoke about numerous times.

    My question is, in vanilla HTML5/Javascript, is the Bags of Data approach still optimal in your opinion?

    I have been in the consume, learn, percolate, prototype process for a couple of years now. As more of a hobbyist/dreamer with no formal education to speak of, I find myself diving headfirst into your and Matt’s experience loaded explanations of how to approach many facets of development, as they have steered me in the right direction many times. I am, for better or for worse, hell bent on constructing each piece of my games from scratch, or whatever works native in chrome.

    Sorry for the lengthy post, I hope that it clear and understandable.


  • LDG

    @Vox said:

    My question is, in vanilla HTML5/Javascript, is the Bags of Data approach still optimal in your opinion?

    In my opinion, yes. JavaScript tends to lend itself towards functional programming, and trying to shoehorn in classical inheritance is a mistake. I love the resulting simplicity of the “bags of data” approach.

    On a related note, I had the urge to work on a minimalist JavaScript game engine, for use in js13k maybe. It sticks to the bag of data approach and I’m trying to avoid using new at all. It’s early days so there’s not much there, yet. I plan to tinker with it a few hours each week.


  • Jammer

    @geoffb
    Oh wow, thank you so much for this reply! Seeing your work is invaluable, as well as knowing that the last couple of months I’ve spent really trying to get an ECS Bags of Data approach nailed down, or at least usable in contrast with how I was doing things in the past (Entities hold every piece of logic that has anything to do with them - aka bad) was not in vain.

    Seeing how you’ve organized your code into separate js files, brings me to another question I’ve had for some time. If this is not out of place, I’d like to inquire about code separation and structure. Maybe a good Lostcast topic would be planning? Or design structure as a whole? I’ve found that in my searches there are many articles about how to solve many different issues, but when it comes to putting it all together, that can be overwhelming. I feel that I personally lack a good sense of organization, and the idea of having some direction in that area backed by experience would be very helpful.

    But all in all, I understand you guys can’t be answering questions all day so I just want to finish with, I’m a big fan of LDG and really appreciate all the content you guys put out.

    Thanks!


  • LDG

    Code organization would certainly make a good Lostcast topic.

    In general, I try to keep pieces of code a separate as possible. Some of it comes down to experience, but it’s OK to write something messy the first time through. I tend to iterate a lot, coming back to modules/systems and refactoring them until they are more simple. Sometimes it’s just not very easy to understand how code should be organized until you’ve written a bunch and seen where the problems arise in a particular project.

    In JavaScript specifically, code organization is awful due to the lack of a native module system. For this tiny project I’m using the node module pattern and browserify to package them all up. I also use watchify to automatically compile the files as I develop. You can get an idea of how this works in my Makefile.


  • Jammer

    This has definitely been an eye opener. Thank you for going over this a bit. I will say that learning by doing is 99% of where I have resided for a while, but seeing your code, and reading how you put it together really clarifies a lot for me, so thanks again!


  • Tiger Hat

    Hey LostCast. Your “Go with the flow” is great advice!

    After my last game devolved into brittle, hard-coupled, spaghetti code, and callback hell (even in Unity this can happen) I tried to learn better code organization by using a few assets that follow the MVC design pattern. One was uFrame MVVM, and the other was StrangeIOC. uFrame MVVM was just too hard to understand and the tutorials were out of date, and StrangeIOC (it’s almost like a cult as the developers and worshipers swear it suits Unity) while it has a lot of great ideas, like inversion of control and code injection, just didn’t seem to make sense with Unity and had the opposite effect of making code organization easier to follow .

    Anyway trying these assets quickly made developing in Unity an ordeal instead of a pleasure and brought my coding in Unity to a halt as I was trying to shoehorn these methodologies into Unity, and just couldn’t. And I feel that the MVC pattern (unless bastardized) does not fit with Unity’s way of doing things.

    So now I am just going to go with the flow and just try to use more messaging and UnityEvents to decouple my code, and keep it more organized.

    But for the ECS people, uFrame is releasing a ECS system for Unity. uFrame ECS. And maybe people who are also trying to improve their code organization will have more luck than I did with uFrame MVVM (expensive but 50% off during the Unity Madness Sale) or StrangeIOC (free with great support).


  • Tiger Hat

    I think that C# is the way to go with Unity because it’s “normal” C#. The javascript is not “normal” javascript, and I’m not just talking about the lack of the browser. It’s really just a javascript like syntax, and coming from a “normal” javascript background with HTML or Node, it makes my brain hurt.

    Going with the flow is definitely good advice, I struggle with it all the time. Issues with NPH (not programmed here) just slow you down. It’s tough tho, for example I love three.js library, it makes webgl much much easier, but I hate mrdoobs code style. Plus it’s a big monolithic library that can be a little bloated. But if I don’t embrace it, then I lose the time that I was trying to save by not writing my own engine.

    Here’s my take on ces that I’ve been playing around with for the js13k. My components are only data, and the systems operate on them, we’ll see as things get more complicated how well it works.


  • LDG

    @TokyoDan said:

    So now I am just going to go with the flow and just try to use more messaging and UnityEvents to decouple my code, and keep it more organized.

    I really like both of these methods. I sometimes struggle with which to use when, but there’s a use case for both. For performance sensitive code, I believe events are the way to go, and they provide more structure around passing parameters. However, the messages are great for more generic actions such as interaction. In AWL2, when the player interacts with something, I send an “Interact” message to the object and its scripts can handle that interaction message however they like. (e.g. flip a switch, open a chest, etc).


  • Jammer

    Sometimes it’s just not very easy to understand how code should be organized until you’ve written a bunch and seen where the problems arise in a particular project.

    That is me in every respect. I often have to code something terribly in order to code it right.

    Also i liked hearing about the tile spacing issue. Had the same issue with libgdx, where as tiled rendering in MelonJS does not have that problem. Luckily the libgdx tile renderer accepts spacing & margin arguments, so i just had them set in the Tiled XML, updated the tiles with padding and it worked like a charm.


Log in to reply