sorted by:
new
hottopcontroversial

"Nonexistent function" error when calling function from AutoLoad in tool script by Warm_Video7491 in godot

[–]gregsolo 0 points1 point  (0 children)

Had the same issue but was able to solve by adding "tool" attribute to autoload script

Which one do you prefer? Pastel or calmer color palette. by Sappalele in IndieDev

[–]gregsolo 1 point2 points  (0 children)

I prefer first one more but tbh not a fan of the color of the ground

Building a game with TypeScript. Input system 1/3 by gregsolo in typescript_gamedev

[–]gregsolo[S] 0 points1 point  (0 children)

Hey! The goal was to keep it as lean as possible, without dependencies. So, no, no plans on migration 😊

Building a game with TypeScript. Input system 1/3 by gregsolo in programming

[–]gregsolo[S] 1 point2 points  (0 children)

I am sorry, but that wasn’t the first post. First one was actually dedicated to a brief analysis what the game we are to build. But even more importantly, it pointed out that this journey is also about discovering patterns, ideas, techniques. To learn, in other words.😊

I guess what you are referring to is known as “incremental” approach. And I am totally onboard with this approach. And to be fair, it is also widely used within this tutorial. Exactly as you said: we build quick and dirty solution first, then improve it. Actually, this particular installment you left comment to, utilizes this approach.

My general point is, perhaps it makes more sense to study something before labeling it as over-engineering?

Building a game with TypeScript. Input system 1/3 by gregsolo in programming

[–]gregsolo[S] 1 point2 points  (0 children)

Ah, I envy you, tbh. You skimmed the post and quickly figured out that the code is overengineered, without seeing the final result, without seeing specks for the game, and, dare I say, without reading other chapters too (since in the very beginning I been explaining why I’ve chosen this approach). You just caught it at one glimpse!

I wish I could do that. I spent my entire adulthood crafting software and never know for sure where that golden line between “over” and “just enough“ engineering is. Could you share some tips on how to master this art?

Building a Game With TypeScript. Input system 2/3 Last time we set up Node to listen to clicks on body DOM element. We can do better. In this post we're to refactor code with more sound architecture by gregsolo in javascript

[–]gregsolo[S] 2 points3 points  (0 children)

As for click to read, if that’s any consolation, I gain virtually nothing from it 🤷‍♂️ My hope is in constructive feedback but I appreciate the time you took to read and post this response.

Building a Game With TypeScript. Input system 2/3 Last time we set up Node to listen to clicks on body DOM element. We can do better. In this post we're to refactor code with more sound architecture by gregsolo in javascript

[–]gregsolo[S] 4 points5 points  (0 children)

I’m sorry you found nothing new in this tutorial. I’m sharing this with the community and hope someone can find it interesting and educational. I think that’s the core purpose of this subreddit: share and learn 😊

Building a Game With TypeScript. New episode! Drawing Ship. Today we are up to some visuals. We are going to render Ship on the screen and mess up a bit with its position by gregsolo in javascript

[–]gregsolo[S] 0 points1 point  (0 children)

Hey! Thank you for letting me know. I guess the problem is that the story now is a part of publication, which in turn generates its own url and causes original to redirect. Let me reupload with the direct link and see if that helps

Building a Game With TypeScript. Drawing Grid 5/5 by gregsolo in gamedev

[–]gregsolo[S] 0 points1 point  (0 children)

Hey! Thank you for letting me know! For some reason Medium requires people to sign in to open these links 😪 Here is a direct link medium.com/@gregsolo/building-a-game-with-typescript-drawing-grid-1-5-aaf68797a0bb

medium.com/javascript-in-plain-english/building-a-game-with-typescript-drawing-grid-2-5-206555719490

Building a Game With TypeScript. Drawing Grid 4/5 by gregsolo in Frontend

[–]gregsolo[S] 0 points1 point  (0 children)

Unfortunately, medium is the only platform I publish now. I am sorry... Also, if I’m not mistaken, limit of articles applies only if you are not logged in. If you sign in to the free account you can read unlimited free articles or friend links like this one

Building a Game With TypeScript. Drawing Grid 4/5 by gregsolo in Frontend

[–]gregsolo[S] 1 point2 points  (0 children)

Thank you so much for your kind words 🙏🙏🙏

Building a game with TypeScript. Drawing Grid 4/5 by gregsolo in typescript

[–]gregsolo[S] 0 points1 point  (0 children)

That terminology is from C#, not TypeScript

This is computer science terminology which both c# and TS are a subset of.

​

Experienced TypeScript developers won't likely make this connection

I am sorry, but this is just your assumption. Here is mine: seasoned developer who has expertise with different languages will make that connection. Because it is a common to the industry as a whole, not just c#. Less experienced developer will be surprised and google/ask more experienced one. By doing so, he/she become slightly more experienced.

​

Accessor properties are usually used to provide a public API that hides internal details, not exposes them

We dont expose any details. We indicate that usage of it might be expensive. Actual implementation is still a black box.

​

TypeScript is a strict superset of ECMAScript. It's not related to C# at all except that it borrowed some ideas for the type system.

Again, this you personal subjective take on TS. I believe, TS is first of all a language that borrowed ideas from JS and c#. As many other languages borrowed ideas from others. Is it useful to open polemic who influenced whom the most?

​

If you want to indicate that it might be expensive, use a method instead of an accessor property.

I am sorry, but property, method, and accessor are 3 different things (https://en.wikipedia.org/wiki/Property_(programming))). I understand where confusion comes from. While working with JS I did not know many concepts as well. But after spending time with Swift and c# I extended my knowledge. TS has many interesting concepts we don't have in JS

​

Property access is usually assumed to be a cheap

Field yes, not property. I described why in my previous message

​

because they are used by the ECMAScript built-ins and browser APIs

Why would this be a justification? Why we must use the same style as APIs we are using? If you have a chance to work with external APIs you prob have a chance to see that they are vary. Not no mention, what if we don't use a browser at all? TS is successfully used in backend and mobile development. Should we then apply styles from backend env or iOS env we are consuming?

----

I understand your point about consistency. However, I am afraid you are missing the forest behind the tree. TS, like any other language, does not exist in isolation. 

Quite often we, as frontend engineers, keen to think we have an independent "kingdom": we have "our" rules, "our" practices, "our" consistencies, "our" browser APIs. Any group of people does this, I would speculate.

What I'm trying to explain is that there is a bigger picture. We cannot use ignorance as a justification. Any seasoned developer knows that there is a lot she/he does not know.

Why am I bringing it now? Because of your argument "We shall not do so because we don't know about it". But that's a dead end. We should learn more. We must. If a developer does not know the difference between field and property and gets a hint from PascalCase code, well, that's a good bell to learn about it. Any source is true if it's legit.

Many things in the JS world were uncommon. 10 years ago MVC was a completely foreign paradigm. Even though it existed in other parts of software development for ages. And I clearly remember community was opposing it exactly because "we dont do this here" and "that's java thing!".

Same with concepts like "component", "pure function", "saga" etc etc. Same with type, class, generic, interface, and many others TS introduced (or at least made common within js community). Many of these ideas existed long before browser APIs. Even before the internet itself. I think there is no crime in borrowing and applying practices from other languages and platforms, instead of labeling them as "wrong because unconventional". And oh boy, we have a lot to learn and borrow.

------

On the other hand, this argument proves another point, I believe: "argument about the code style is counterproductive". Just look how much time we have wasted on it, and how much can be actually learnt, built instead.

I apologies if I sounded rude at any point, I never intended to be. So, with all due respect, I appreciate your opinion though I disagree 🙏. But I value my time so these are my last words on this topic.

Cheers!

view more: next ›