trjh2k2

Members
  • Content count

    101
  • Joined

  • Last visited

Community Reputation

418 Neutral

About trjh2k2

  • Rank
    Member

Personal Information

  • Interests
    Art
    Design
    Production
    Programming
  1. I could see maybe bundling those up into a simpler rule of just "make it easy to build on a windows machine". Outside of that, just my 2c, but I'd avoid adding rules that don't directly play into the theme or goal of the particular challenge/competition. If the goal is, for example, to examine certain gameplay mechanics, then it shouldn't matter what tools are used to get there. If the goal is maybe to teach how to make an ECS-like system, or to teach how rendering works, then yeah, you'd want to restrict the toolset in that case, since the rule then supports the end-goal. This is keeping in mind again that if we're targeting beginners, limiting the workflow might again reduce the participants by those who aren't familiar or comfortable with certain tools or workflow yet. You could argue that it's part of the point, but it depends on what the stated goals of the particular challenge are.
  2. This. I've run into payment systems that don't let you test without actually spending money. Seems like that would be an obvious one, hah.
  3. ^ In an ideal world, everyone would be great at handling criticism, but this is not that ideal world- the majority of people, as far as I know, naturally have some level of hangups around putting themselves in a position to be criticized. Doesn't matter whose fault that is, it still presents as a challenge to attract beginners into something being labeled a competition.
  4. ^ I like the idea of using small competitions like this - but why that set of rules? "No engines" and "you can use SDL, etc" seem to kind of negate eachother don't they? Seems a bit arbitrary to force a particular workflow unless it ties into the theme/point of a particular competition. Adding a bunch of workflow restrictions is also going keep beginners out, IMO, which might defeat some of the purpose. I do think that's a lot of the challenge in something like this: The competition is there to help beginners grow, but beginners are going to be leary of joining competitions because of lack of confidence, or lack of wanting to be judged, knowing they are beginners.
  5. I never claimed to be any authority, it's just my opinion that javascript as assembly is a poor analogy- the only reason I include the fact that I've made games this way was an attempt to preempt the "how would you know, I bet you've never used javascript before" argument, despite the fact that I use it quite regularly. Am I not allowed to have my own opinion?
  6. I get where you're going with it, but I don't think you'll convince me that it's a useful way to think about how javascript is used. You can draw comparisons between browsers and processors if you want, but the comparison isn't useful, IMO. Just my 2c. For the record, I'm saying that from a place of having made entire games in both javascript and C++/c#, etc.
  7. I don't consider the browser to be a processor, I think that's also a bad analogy. Javscript is already a very high-level way of working, and I think it would be a stretch to say that it should be avoided like you would avoid writing assembly. I know there are a lot of workflows that involve working at higher levels than that, and compiling stuff into javascript, or into subsets of it, etc., but it's just as common to just work in Javascript itself, as far as I know.
  8. Googling it still doesn't mean I've heard anyone actually make that comparison, not that nobody has ever said it. Thanks for being condescending about it though. I skimmed through some of the top results, and I stick by my opinion- Javascript as assembly isn't a good analogy. One of the top results starts with a comment about opening up the 'view source' of a page and being surprised by the fact that the markup and code for the page had been minified and obfuscated. They proceeded to calling it a "GUID", which makes zero sense. That's not what a GUID is, and minifying a page has nothing to do with assembly. If the point was the ubiquity of use, then a comparison to C or C++ would have been better, since it seems super uncommon for people to actually write assembly instead of something higher level, whereas people just write plain JS all the time. If the point was that you can compile other languages into Javascript, then that still is a bad analogy 'cause you can do that with almost any other language.
  9. Yeah, it definitely can be. I just mean that it's not the only way. And knowing lots of languages doesn't mean necessarily that you can do any of them well. IMO a deep understanding of a small number of languages is better than a shallow understanding of a huge number of languages. Like if I was going to hire a guy for javascript- I'd rather hire the guy who says "I've been using javascript for years, I don't really know any C++ though", than the guy who says "I know 100 languages! Javascript is just one of them!" I think it's fair to say that continuing to learn is always a good thing, but I personally wouldn't focus on something like the number of languages. You could also spend that time learning new ways to use the languages you already know. Or learning how to use a new engine, package, library, etc. you've never used before. Or learn how audio works. Or learn how ECS works. Or learn how to use Windows API instead of using something like SDL or what have you to manage windows for you. As long as you're learning something at all.
  10. I've never heard anyone make that comparison before. And it's kind of a terrible analogy. Javascript is about as far from assembly as you can get in terms of the kinds of languages we've spoken about so far. Unless you count data/markup in that conversation.
  11. How many or which languages you know is not what makes a good programmer though- it's about how you employ those languages to accomplish whatever your task or goal is.
  12. ECS has nothing to do with being data-driven. You can have a data-driven setup without components. For example, my current game project uses a bunch of json files to populate a level (the data is separate from the logic), but I don't use components, I'm using simple inheritance, since it's the simplest solution that accomplishes what I need for my use-case. ECS doesn't "solve" the problem of deciding what class is responsible for what, it just changes it. Now instead of deciding if an entity should have any say over another entity, you're deciding if one component has any say over another component, or the entity, or other entities, etc. ECS answers the question "how do I compose the objects in my game", it doesn't answer the question of "what object is responsible for what".
  13. Fixed update in game loop

    I don't think the goal should be to prioritize the time budget between rendering and logic, so much as just make sure that either one is not a bottleneck. The point of the fixed time step is not to say "I am budgeting this much time to each frame" for performance or something like that, but rather to keep each step of your simulation consistent, regardless of how long you've given it.
  14. Care to elaborate on "hidden specs"? I'd almost argue that, at least in terms of laptops, the value you get for something new isn't great right now. I looked around for new laptops maybe 6 months ago and found the current options to be pretty disappointing. Small hard drives, usually-upgradable parts are being soldered in, and specs don't seem to have gone up significantly in the last few years- so a $1k laptop now doesn't get you much more than what that same $1k would have got you 4-5 years ago. Instead, anything less than a "high end" laptop mostly gets you something like a glorified internet browsing machine.
  15. I've been doing most of my at-home work on an older laptop, despite having a much better desktop available- and I've been treating it as sort of a benchmark or minimum spec for how well the project performs. If my small project game can't run on this old laptop, then that's a sign that I've made choices/mistakes that are costing me too much in terms of performance. If what you have now is enough to comfortably use the tools you need, then that's good enough.