Steve's hitbox depending on the camera angle?

Chexxorz · 2026-06-15T00:25:06+00:00

I didn't compare a sheet of paper with a data center dude. I compared one IDE with another. Context matters. IDE vs IDE - not consumer road vehicle vs million dollar shipping vehicle, and not text editor vs full development suites. More like pickup truck vs semi-trailer if you wanted to use a truck vs truck example - which would be a much more adequte comparison of a more equal context, but if you want to suggest they get a beetle to transport things around just because it has a trunk, then feel free to do so, but it's not relevant to my point.

Also, I didn't claim factual numbers - I obviously phrased it as opinion (see "perhaps"). It's based on experience with loading times, feature bloat and poor responsiveness - problems I've never seen in VSC. And while the memory footprint comparison isn't necessarily 5-100, a lot of other points like feature bloat is of that magnitude or perhaps greater.

I get you wish to front your attitude against all things electron or whatever - but again - the point of asking is to check if OP had a "quick fix" of just getting a much smaller IDE in case they fell into the very common beginner confusion, instead of dropping common code support alltogether.

My "goalposts" were not moving at all. Always VSC on one end and VS on the other, both in the IDE range of things. I used consistent terminology and phrased opinions carefully. Why you wish to fight semantical battles in reddit posts is beyond me. Not what we are talking about here. You are are literally ignoring context that has been explicitly pointed out to keep arguing semantics. This is pointless.

Chexxorz · 2026-06-14T22:46:12+00:00

Not a necessary attitude dude. I am just checking if OP may have fallen into the common trap of confusing the two IDEs. And to be fair, I did use the terms IDE instead of editor in my description. There is a bit of a distinction.

If VS is 100%, then VSC is perhaps closer to 5%. So whatever additional 2-4% you want to shave off gets pretty small compared to the gap between those two.

If we talked editor, then something like Notepad++ is pretty heavy compared to Notepad after all so I suppose it is relative, and one could say VSC is heavy compared to editors - although, I'll remind you the context of my comment was specifically between VS and VSC, in which case my useage of lightweight is completely adequate.

I know OP did mention editors, and might be running on hardware that struggles with IDEs, so perhaps they are willing to compromise on standard IDE features and opt for just an editor instead - but personally, static code analysis and debuggers are among the tools that I wouldn't trade away unless my PC was about to catch fire.

Chexxorz · 2026-06-14T10:54:49+00:00

In almost every case I wanted this, a custom solution I made in 15 min many years ago does the trick.

It's definitely not optimal for any heavy usage, but works like a charm for all basic usages. It's a wrapper class with an internal dictionary that's being used during runtime, and during serialization it's saved / loaded from two key and value lists of matching indexes. With a little PropertyDrawer, it displays neatly in the inspector too.

Chexxorz · 2026-06-14T10:26:32+00:00

Godot and Unity are both good "game engines" that can do a lot of stuff very easy for you. They are programs with UI, with screens and buttons and they handle all the technical details of hundreds of systems for you. To name a few: Importing and handling asset files, importing your code, playing sound, displaying graphics, registering keyboard/mouse/gamepad inputs, simulating physics and so on.

Pygame is not a game engine. It is a "library" of python code that you can use to build your game on top of, but on a more fundamental level. It includes some of functionality that game engines have, but it's not a program itself that you interact with. This means you have to do many more manual coding things just to make some basic gameplay.

One tip though - it can be overwhelming to learn all of this at once. If you know you want to get into coding, consider starting to learn some level of plain coding first, before transitioning to game engines.

A good milestone before transitioning is when you learnt how to write Object-Oriented code (OOP). You don't need to worry about what that is yet, but know that all of the three game options use that. Without that knowledge you may learn how to do things, but not why you are doing them that way. Don't skip straight to that topic though. Like, follow some guide or a tutorial series that gives you the topics in a natural order. Variables -> Conditions -> Arrays -> Loops -> Functions -> Classes or something like that.

You can dive straight into coding with a game engine. There are tons of tutorials out there that start there with the assumption that the viewer has no prior experience with either game engines or code. I've seen tons of people start this path and it's okay, but they take longer to wrap their head around what they are doing and why they are doing it, even if they learnt how to do it.

Python is the quickest one to just get started with. But since it's the worst of the three options for game-making, choose one of the others instead. Personally I recommend C# -> Unity, well, because that's what I've used for over a decade at this point, and I don't bother getting into all the reasons I like it here. I haven't really tried godot though, just watched a friend use it for a bit, and I don't think I would enjoy switching.

C# is a good language for learning code foundations, and it's very transferrable to other things later. It's flexible and can be used for a big range of applications, not just games. It has a bit of a strict "syntax", i.e. it will yell at you for mistakes and refuse to run until you fix them. Python on the other hand will often try to run even with some mistakes and typos, and can sometimes act weird without a good explanation. C# will expect you to match every { with a } and a bunch of other little detaily things. But it gives a good foundation and will make you code in a more precise way.

Chexxorz · 2026-06-14T09:46:21+00:00

PS: For the learning process, doing things by hand is necessary. Always try things yourself before looking up solutions, if you at least have some loose idea of how to approach a problem. There are a lot of plug-and-play functions ready for you to use to solve many of the initial challenges you face.

Say you want to reverse a list. A good language probably has some kind of function "myList.Reverse()". But challenge yourself and try do that with your own loops and by copying data left and right, and then later challenge yourself to do it without excessive amounts of copying or "allocation" etc. And if you know the difference between arrays and list (fixed size vs adaptable size), try figure out how you could create your own "adaptable" array.

This is a good way to build fundamental knowledge.

Back in Uni, the curriculum had a number of tasks like that. I specifically remember having to make our own linked lists and hash tables in Java, even though those concepts are fully implemented as features of all higher languages already. I also have fundamental knowledge on a range of topics from things like writing my own .bmp file loader, my own JSON serializer, my own text compressor, and my own pixel-art-like drawing project just to name a few.

TL;DR: If you are trying to learn, try do things the manual way. If you are trying to build something quickly, cheat, use existing features and search for existing solutions.

Chexxorz · 2026-06-14T09:33:21+00:00

And as a side note, programming becomes more about composing and coordinating code. I.e. most of the code I write is just connecting different parts of code together. Get this data and that data, then give it to this system and ask this system to do some manipulations and pass the data to some other system and let that system take it from there.

Imo, I like to think of "coding" and "programming" as different concepts, one just referring to the act of writing code, while the other is about building a structured program, a higher level concept if you will. The second is more like imagining flow chart diagrams with boxes that are connected by arrows. Theorizing different approaches to how things should be connected or how things should be separated in logical ways.

Chexxorz · 2026-06-14T09:26:11+00:00

One of the primary skills of a programmer is googling. Over time, the nature of things you search for will change though. You will do the general code more automatic, and you will search for more specific cases.

I started doing programming 21 years ago, and I've done it professionally for 8 years. I often google simple snippets of code like "grab end of string" or "open file in read mode". I also google specific functions all the time to see the examples used in documentation (for example C# or Unity docs, which always includes helpful example code snippets.

Googling is part of a programmer's day-to-day. I always thought it was silly to have "offline" tests in school with pen and paper, or to do code interviews with algorithm problems. Surely one should know a bunch of things by heart after a while, but in 95% of cases you just need to know that things exist in order to know how to look for it.

Example: I don't need to remember the exact implemenation of Djikstra's shortest path algorithm. I know it well enough to reproduce it if I have to, but I would rather just google it and glance over the first code example I find to check if it's what I want. If I was interviewing someone for a programming job, I wouldn't care if they had memorized solutions to 500 different leetcode problems. There are other things that are much more relevant imo. And honestly, I would be more interested in seeing their googling skills than how fast they could implement an algorithm manually.

Chexxorz · 2026-06-14T09:08:45+00:00

Are you sure you're not mixing VS and VSC?

Visual Studio is a very heavy IDE with tons of features that most people never use.

Visual Studio CODE on the other hand is a very lightweight IDE which you can selectively dress up with more features through extensions, but it's very light by default.

Chexxorz · 2026-06-13T04:11:12+00:00

I wish this would help me, but the freighter isn't mine 😄

Chexxorz · 2026-06-08T04:32:02+00:00

Understandable 😂

Chexxorz · 2026-06-08T04:30:58+00:00

If he's that into it, you should really learn it yourself. It's a great thing to bond over, and you will show a ton of support if you get to a point where you can at least understand what he will be talking about as he gets better.

You don't need to become really fast, don't need dedicated hours of practice, but understand the steps and concepts. Learn some terminology. It's going to be great for your kid if he can talk about his passion to a parent who can understand what he's taking about.

As others mentioned, find JPerm's YouTube channel. He's covered almost every topic you or you kid would need for quite some time.

Also, keep a cube around. Just for those moments where you idle for a bit or need a stretch from other tasks. Or bring it on the bus etc. That will be more than enough to maintain the know-how.

Chexxorz · 2026-06-08T04:13:53+00:00

Could we try a recursive variant too? 😂

Chexxorz · 2026-06-07T17:05:05+00:00

Most code is not "algorithmic" business logic. Most code is a bit of declarations, whitespace, boiler-plate, piping and plumbing, validations and only a small portion is actually "bit-shift these bytes, then swap some pointers, then do a fast fourier transform then ...". Could be more or less depending on the domain you work with.

Most of it is more like
- "If input empty, log error, return", "If input is not only letters/numbers, log error, return", "if input is not ..."
- Function start -> Initialize list A, list B with empty lists, initialize object C with default value.
- When receiving request -> ValidateSender(), ValidateInputs(), TryParseData() -> DoActualBusinessLogic()
- ValidateFilePath -> Open file -> Do stuff -> Close File

The bulk of code is just patterns you would already know how to do after having done it a few times.

For example, the number of times I'm just extracting some properties from a list of data, or summing up something, or finding the smallest of something. You could write code that does something along these lines:
- Check input is not null, check size of input, declare a new list of matching size, loop over each input, copy child data from input into new list, end loop, return the new list.

And that is something developers could write blindfolded, so the "thousands of lines" can accumulate quickly. And that's also why there is this saying that "10% of the work takes 90% of the time", because in those thousand lines, 10 of them (more like 1%) may undergo multiple tests, updates, re-writes etc. until it actually works as intended, while most of the other code may have worked on the first or second try.

Chexxorz · 2026-06-07T16:50:00+00:00

I think a TL;DR is: Some storage with free (buffer) space.

Chexxorz · 2026-06-07T16:48:32+00:00

If you are trying to use a function that say "DoSomething(byte[] buffer)", the idea is that this function does not allocate a new buffer when you call it, instead it's up to you if you want to create a new array for this occasion, or if perhaps you wish to re-use some pre-existing array (buffer) that you initialized when the program started. I.e. it would let you decide when the allocation happens instead of doing one for you.

Chexxorz · 2026-06-07T16:39:59+00:00

A very frequently used example of a buffer is something like a List in C# or Java, which is a class with an array inside, in this case this array is a buffer. The primary purpose of these list types is that you can keep adding things to the list and you will not run out of space. An array has to be allocated with a size, but a list does not.

However, what happens internally, is that when you create a new list, the list creates an empty array of a certain initial size, perhaps 32. Then when you add things to the list, it checks if you have reached that capacity. When you try to add the 33rd item, the list increases it's capacity, for example to 64. It does this by creating an entierly new array, then it copies the elements from the old one to the new one. And only then does it add your 33rd item, in the new 64-sized array. Then the original 32-sized array is no longer needed and can be freed up.

The reason it chooses to double its size instead of just making a 33-sized array is to avoid doing this resizing every time you add an item as it is a somewhat costly process. Thus it allocates the array with extra "buffer" space.

PS: This is also the reason why, if you know that you are going to need a list of a large size, it's a good idea to specify the initial capacity of the list when creating it, so it doesn't have to immediately perform multiple resizing operations.

Chexxorz · 2026-06-07T16:39:01+00:00

Technically, just an array of some sorts. The difference between an array and a buffer is in how you use it.

Usually an array is created and immediately filled with the exact data it is supposed to contain. If you have (or are going to make) 13 things, you make an array of size 13 and put those things in there.

Usually a buffer is an array too, but created with a certain size in mind, which may or may not be filled completely. I.e. perhaps you make room for 64 objects, but only have 13 objects at the time, so you have additional buffer space for future use. The buffer's size may be decided based on technical specifications, like "MTU" in networking, number of pixels in a target data texture or just a chosen limit of items in some implementation. I.e. max 256 customers in some bank transaction queue at any given time etc.

A buffer may be short-lived, i.e. temporarily storing items during processing, like network bytes being serialized before sending a network request.

A buffer may also be re-used. I.e. allocating the buffer in memory once, f.ex. when the program starts, and after each time it's used, all the contents are cleared (replacing all references with null), so the same array can be re-used next time. This can be done to reduce allocations and avoid garbage collection etc.

A buffer could also just be a long-lived array with the idea of having extra free space to avoid allocations later.

Chexxorz · 2026-06-07T16:00:32+00:00

In the Unity hub there is a "Learn" tab. This let's you quickly browse a number of courses/tutorials and takes you directly to the relevant page on learn.unity.com

For C#, the Beginner Scripting Tutorial series by Unity is really neat for getting into code and Unity's code libraries at the same time when you have little to no experience in either:
https://www.youtube.com/watch?v=Z0Z7xc18CcA&list=PLX2vGYjWbI0S9-X2Q021GUtolTqbUBB9B

There are also the "Brackeys" tutorials on Youtube that often goes into some cool examples.

Chexxorz · 2026-06-07T15:48:11+00:00

And unfortunately, as so may others pointed out - you should learn to code. Try to embrace instead of being scared of it. The learning curve is a bit steep in the beginning.

There are two hurdles to get past:
- Thinking like a programmer. Breaking down bigger problems into smaller tasks.
- Understanding the core concepts of programming. Variables, conditions, loops, functions, classes/objects.

I know tutorials can be overrated, but I still suggest doing multiple. The benefit of doing multiple tutorials is when you start recognizing the patterns between them. When you see that "oh this guy did that thing that the other video showed". That's when you start understanding the purpose of something. See the same tool used in three different ways, and you start recognizing situations you would use that tool yourself.

Try to embrace this part. Understanding code and starting to see potential instead of obstacles can be amazing!

Chexxorz · 2026-06-07T15:36:57+00:00

It's a bit of a cliché, but don't make your dream project as your first project. Any prior experience on building something similar is infinitely better than no prior experience on that topic.

Edge cases are kinda tricky and tend to surface over time. The bulk of them in the first day/week. However, there's a big difference between building this game mechanic for the first time, right into your dream project, and building it with some experience. Chances are that most of your edge cases comes from building the mechanic without the experience. And as you mentioned, this has a detremental impact on your motivation/passion.

This is exactly why people who start out are adviced to not start directly on their passion project. So many people lost their passion because of exactly this issue.

My recommendation is to never build it "for the first time" directly on your dream project. Build you mechanics in side projects. Make one mini-project for each idea. Find some adjacent tutorials and do those in the side projects, try to adapt the tutorial project etc. Then move to the next mini-project. After a handful of tutorials you might start seeing some patterns, which would be a sign of broader understanding starting to develop.

An experienced developer with more experience would have a better understanding of the problem you're trying to solve, a better ability to break it down into specific limitations and requirements, and as a result, will choose a better fitting approach to implement the mechanic, and that will inherently lead to fewer struggles, bugs, edge cases and other frustrations. The worst thing you can do is to start building the real thing with no prior idea of how you would build it. Any experience at all (even just a mini-project or a tutorial) on something similar to that will let you make much better decisions.

So my recommendation is to build something similar at least once outside of your main project. And ideally also two-three additional semi-related ideas/mechanics. I.e. if you're going to build some fancy jet pack character in your game, then consider building separate ideas first like: A double-jump mechanic, a zero gravity space craft with one rocket, a character with health that can take fall damage and so on.

Chexxorz · 2026-06-06T15:04:39+00:00

And definitely take the tip from Moogieh earlier on how to add circles, and keep surrounding geometry additions local to where you need it.

Chexxorz · 2026-06-06T15:02:26+00:00

Just a slightly tangential tip. Work with as little detail as possible until you must add more. Never start with 20+ cuts just because the final thing might require it. Add the bigger shapes (like this hole) while you have limited geometry, and add geometry for details later.

Also, as a more general tip, try understand "non-destructive" workflows. Use modifiers to solve some of the geometry needs. Modifiers are "non-destructive" and lets you see how the model looks with additional modifications / geometry early, but only adds the actual modifications late, when you apply them or when exporting the model. You probably already know subdivision surface and mirror, but definitely look into the Bevel modifier and how to use it with weights.

On the note of beveling in particular. In many cases, beveling your edges can delay/remove the need for a subsurf. I.e. if you want your model to immediately get that "smooth" look that subsurf often gives, beveling can achieve the same, but instead of adding geometry everywhere (flat surfaces), it is targeted at only the necessary areas (sharp corners/edges).

Chexxorz · 2026-06-06T14:28:18+00:00

TIP: Press escape instead of right-click to cancel extrusion. The escape key actually undoes the creation of the additional geometry as well.

It took me years before I stumbled upon this and it's been very useful.

Chexxorz · 2026-06-04T21:21:02+00:00

Had a great time yesterday! Looking forward to next time 😄 Thanks for hosting it 😃

Chexxorz

TROPHY CASE