Game Creation/Design Catch All

I got around those issues by creating them with their target set to undefined and then waiting a number of frames to detect a target and then if the target is beyond a certain range resetting it to undefined and making it wait a while again. I have to do like 3 or 4 if instance_exists checks to keep it from crashing the game at various points like when another missile kills the target first. I thought about just getting the target’s x and y and then setting a delay for it to recheck the target existence and position and still may to give it a little less power.

Humble Bundle is having a Zenva fire sale bundle.
Way too much game dev stuff (unreal, unity, c++, VR, AI) to list for $25:
https://www.humblebundle.com/softwar...

Wow, that's a wild assortment of stuff for a whole range of engines.

Topics, engines, shear volume, it has got it all

I did some calculation today based on The Steam Hardware Survey numbers and found that around 90% of Steam users are using a 16:9 or nearly 16:9 monitor:

IMAGE(https://i.imgur.com/OkXQMdZ.png)

This is no surprise of course. Using this data that 16:9 (or very close to it) is being used by most people using Steam (and opting in to the hardware survey) I decided to do some math to figure out what the best resolutions were for integer scaling in game design. I have seen a lot of people pushing 320x180, but I wanted to see how things looked for myself. Here are the results of that (I have hidden the resolutions and scaling factors that didn't match any monitor resolutions except 16x9 which would eventually hit everything just requires a scaling factor of 80 to hit 720p):

IMAGE(https://i.imgur.com/JOLuJ2N.png)

The really interesting ones are 320x180 (no surprise people smarter than already figured this out) and 640x360. The first will perfectly scale to every 16:9 resolution I was looking at including 8K and the oddball 1600x900 and 640x360 hits them all except 1600x900. Being able to hit both 720p and 1080p is tricky because 720*1.5 = 1080 and then 1440p is tricky because it is another 1.5x multiplier.

This also gave me an idea for a game jam: 16px by 9px. Even the Atari 2600 had a higher resolution display than that

Sounds like a great resolution for a mastermind clone ;P

I'm still on a 10 year-old 1680x1050 Acer.

Quintin_Stone wrote:

I'm still on a 10 year-old 1680x1050 Acer.

My secondary display is an older Dell that runs that (and my 1080p display is probably 9 or 10 years old now). I have been thinking about getting some new monitors lately. Thinking about getting a 4K and a 1440p with higher refresh rate, but I would like to find these in basically matching displays as far as brand/bezels/size/etc goes. At the same time though I get super annoyed now because the difference in resolution causes my mouse to get stuck moving from one to the other. And the way Windows handles that compared to macOS is extra annoying. In Windows it gets stuck at both the top and the bottom corners and apparently this is a feature.

That Acer is my primary though. What's funny is my secondary monitor, that I use for my secondary PC and my RetroPie, is a 1920x1080 LG.

Introducing the Three.js subscription plan!

Includes:
* 1 npm download / day
* 1 hour of docs usage / day
* 10 examples view source / day
* 5 jump-the-line feature request
* Premium access to XR features
* Up to 100TB in Imagine Cloud

Only $14.99/month!

Imagination for all.

Quinternions must be extra.

Been working on my prototype some more. A lot of the stuff I have done is under the hood stuff like detecting gamepads and setting up stuff for moving between rooms and different game states, but I did add a couple things that are more visible. First off is a sway effect so that the player's plane isn't quite so static:

And the second feature is wingmen:

I still need to fine tune them a bit more as their movement is too synced with the player and each other right now. In the final version they will be using a different smaller drone type sprite if we leave them in. May also set them up to fly in different formations that the player can switch between.

Looking good, Rykin! Nice work!

I've started working on an RPG tutorial course in Unity. Making good progress.

Which course if we may ask?

astralplaydoh wrote:

Which course if we may ask?

Whoops, sorry so slow to answer!

This one:
Learn to Create an RPG Game in Unity

There are pros and cons to the course.

This is the second course I've taken with this instructor. He's very good at getting things done and explaining things, and I've learned a lot about Unity features and how to apply them.

However, he does a number of things that fly in the face of Unity fundamentals, like exposing every variable as public. Eek!

That is probably not bad for development since you can test and tweak everything. But you should definitely not make them public as you approach release.

fangblackbone wrote:

That is probably not bad for development since you can test and tweak everything. But you should definitely not make them public as you approach release.

Why? It all gets compiled anyway, so it's not like the player will be able to tweak them. Is it a performance thing?

Fredrik_S wrote:
fangblackbone wrote:

That is probably not bad for development since you can test and tweak everything. But you should definitely not make them public as you approach release.

Why? It all gets compiled anyway, so it's not like the player will be able to tweak them. Is it a performance thing?

I'll take a shot...

My understanding is that a public variable is a global variable. General coding practice is to limit the scope of variables to only what is needed so you don't have variables conflicting with each other by accidentally being named the same thing, etc. This gets important on larger projects or projects where more than one person is coding.

Even though it's not critical to limit the scope on a small, one-person project, it just gets you into bad habits by not doing it the right way.

Godzilla Blitz wrote:
Fredrik_S wrote:
fangblackbone wrote:

That is probably not bad for development since you can test and tweak everything. But you should definitely not make them public as you approach release.

Why? It all gets compiled anyway, so it's not like the player will be able to tweak them. Is it a performance thing?

I'll take a shot...

My understanding is that a public variable is a global variable. General coding practice is to limit the scope of variables to only what is needed so you don't have variables conflicting with each other by accidentally being named the same thing, etc. This gets important on larger projects or projects where more than one person is coding.

Even though it's not critical to limit the scope on a small, one-person project, it just gets you into bad habits by not doing it the right way.

It’s been awhile since I did anything with unity but I thought public variables were scoped to the component? They are in c# terms class variables?

I am one of those people who generally no longer makes class variables private unless they is a class invariant relationship that needs to be enforced between the variables. Like if you have a class which is a 3D vector, there isn’t a relationship between the x, y and z variables. It’s safe to just make them public. However if you have a class which is a normal vector, then the length of the vector must always be 1, so any change to one of x, y or z requires changes to the others. That requires those variables to be private.

Having every class variable be private with setters and getters is an old object oriented style that is mostly out of fashion at the cutting edge of languages like C++.

Made a worm type enemy for my prototype:

Nice work!
The split off mechanic is really well done!

DoveBrown wrote:
Godzilla Blitz wrote:
Fredrik_S wrote:
fangblackbone wrote:

That is probably not bad for development since you can test and tweak everything. But you should definitely not make them public as you approach release.

Why? It all gets compiled anyway, so it's not like the player will be able to tweak them. Is it a performance thing?

I'll take a shot...

My understanding is that a public variable is a global variable. General coding practice is to limit the scope of variables to only what is needed so you don't have variables conflicting with each other by accidentally being named the same thing, etc. This gets important on larger projects or projects where more than one person is coding.

Even though it's not critical to limit the scope on a small, one-person project, it just gets you into bad habits by not doing it the right way.

It’s been awhile since I did anything with unity but I thought public variables were scoped to the component? They are in c# terms class variables?

I am one of those people who generally no longer makes class variables private unless they is a class invariant relationship that needs to be enforced between the variables. Like if you have a class which is a 3D vector, there isn’t a relationship between the x, y and z variables. It’s safe to just make them public. However if you have a class which is a normal vector, then the length of the vector must always be 1, so any change to one of x, y or z requires changes to the others. That requires those variables to be private.

Having every class variable be private with setters and getters is an old object oriented style that is mostly out of fashion at the cutting edge of languages like C++.

This is all new to me. I'm curious to learn more about this.

Does this answer the question about scope?

DoveBrown wrote:
Godzilla Blitz wrote:
Fredrik_S wrote:
fangblackbone wrote:

That is probably not bad for development since you can test and tweak everything. But you should definitely not make them public as you approach release.

Why? It all gets compiled anyway, so it's not like the player will be able to tweak them. Is it a performance thing?

I'll take a shot...

My understanding is that a public variable is a global variable. General coding practice is to limit the scope of variables to only what is needed so you don't have variables conflicting with each other by accidentally being named the same thing, etc. This gets important on larger projects or projects where more than one person is coding.

Even though it's not critical to limit the scope on a small, one-person project, it just gets you into bad habits by not doing it the right way.

It’s been awhile since I did anything with unity but I thought public variables were scoped to the component? They are in c# terms class variables?

I am one of those people who generally no longer makes class variables private unless they is a class invariant relationship that needs to be enforced between the variables. Like if you have a class which is a 3D vector, there isn’t a relationship between the x, y and z variables. It’s safe to just make them public. However if you have a class which is a normal vector, then the length of the vector must always be 1, so any change to one of x, y or z requires changes to the others. That requires those variables to be private.

Having every class variable be private with setters and getters is an old object oriented style that is mostly out of fashion at the cutting edge of languages like C++.

I'd contend that having private local variables is not out of fashion. Rust is pretty modern and all struct variables are private by default. You have to explicitly declare them as public.

And functions in Angular (typescript) are public by default. Guess it all depends what you're working on.

The whole thing with making variables public vs private really seems to be about making classes/modules/methods/functions/etc that are "safe" to hand off to other people. The idea is really that if you are handing the code off to someone else they can't break the internal functionality of your class by directly accessing the variables/properties/function forcing them to rely on any getter/setter methods you have created that are hopefully robust enough to keep them from breaking the internal functionality of your class. At least this is how I was taught it by a couple of my professors (one who was a programmer for the FAA and the other was a programmer for GM) back when I got my degree.

As a theory head on programming, I can speak to this.

The high-level answer is: making all your variables public is bad because it breaks encapsulation. All nontrivial programming ultimately boils down to managing complexity, and encapsulation is the most powerful way to do that.

To explain, imagine a program where every variable is global, and there are no classes or objects. Technically speaking it might work, but programming that way is a terrible idea because the complexity would quickly become unmanageable. Every line of code can both affect and be affected by every variable, so you can't fully understand any one piece of the program without also understanding everything else.

So to make things better, you split up the code - into modules, objects, classes, functions, etc. But if every object can see every other object, and every property is public, then you haven't actually changed anything! The complexity is all still there - every line of code can still read and write every property, they're just organized differently.

So that's where encapsulation comes in. If a module exposes only one public property, then no matter how complex it might be on the inside, code outside that module can only affect or be affected by that one property. As a result, when you're editing code inside that module you need to understand its internals, but when you context switch and start working elsewhere, you can forget all that and treat that entire module as just a container for its one public property.

-----

So that's the conceptual answer. Note though, that the conceptual situation doesn't necessarily have to match the implementation details. E.g. if you're using a language that doesn't have private class variables, you can still have encapsulation by prefixing private variables with "_", and then never accessing those variables from outside the module. Or in the reverse direction, if you make all your class variables private, but you also give them all public getters and setters, then there's no encapsulation going on and the fact that they're private doesn't mean anything.

I kind of want to get out of the weeds here because Encapsulation is one of these Shibboleths of the Object Orientated Programming crowd and that public class variables are bad. There is a cost to putting setters and getters on every variable. As Fenomas says you haven't hidden any complexity or made things easier by putting them.

For example

class Foo { public: int GetBar() const { return m_bar; } void SetBar(int in_bar) { m_bar = in_bar; } private: int m_bar; }

That used to be considered good style. The variable has been wrapped with a setter and getter so Encapsulated. But we have gained nothing and there is now a function call cost to be paid on every access[1].

The argument for doing that is that you change what m_bar is, then you don't need to change any client code. Which I guess is great if you work at a large enterprise operation where you don't know what people are using your client code and safety is your primary concern. However in games the primary concern is hitting your target frame rate. In the context of games, you will definitely need to check all the client code, because if you change m_bar, you need to check every usage of GetBar() and SetBar() because those functions are no longer cheap as chips integer accesses. People who quite reasonably used GetBar() within tight inner loops need to know that the cost of that has changed. So what did you gain by using a Setter and Getter? In would be safer to use a public variable since if you change m_bar, then the client code breaks as well in the compiler and you can easily see what else needs to change.

The important concept is not public and private variables in classes, the important concept is the class invariant that your class design is enforcing. If there is then private variables are an appropriate language feature to help you achieve that.

For example, I have decided to have an NPC class and because it's a children's game when the NPC enemy dies, I just want to disappear the enemy in a puff of smoke and drop some loot. My class invariant is then that the NPC's health must always be a positive number. So what would normally be the SetHealth method also needs to be checking that the health is greater than 0 and if it ever does then call the particle system and loot drop. But chances are, I don't really want entities setting the absolute health on my NPC, I want to apply a delta. When the player hits the NPC with their sword, I want to apply a loss of 10 hp to the NPC. So I probably don't have a SetHealth() method on the NPC at all. I have an ApplyDamage method, which takes that 10hp as input and subtracts it from the NPC's health (and checks it is greater than 0). Then if I come along later and add Armour to my NPCs I am changing the ApplyDamage method, so that armour is checked at that point. So my class sort of looks like this:

class NPC { public: HitPoints GetHitPoints() const { return m_health; } void ApplyDamage(HitPoints in_damage) { HitPoints modified_damage = m_armour.GetArmour(in_damage); m_health = m_health - modified_damage; if( m_health <= 0 ) { ParticleSystem::PuffOfSmoke( m_position ); LootBoot::DropLoot( m_position ); GameWorld::DeleteMe( this ); } } public: // No restrictions on what armour can be used with an NPC, just allow other entities to set it Armour m_armour; private: Vector3 m_position; // The position must be valid in the world and is enforced by the NPC's movement code Hitpoints m_health; // Health must be greater than zero } };

The point is that this class shows Encapsulation because client code is isolated from the details of how damage is applied and the client code doesn't have to care about the class's case invariant.

The TL;DR I am not saying that private variables are out of fashion, I am saying simple setters and getters are out of fashion. Private variables aren't encapsulation on their own, but a feature that can allow you to achieve encapsulation. The important thing is that you design your classes so that you know what properties you are attempting to keep hidden from client code and what properties you need to enforce for your class to be correct.

I was reacting to a statement above that said that a tutorial used public variables which the commenter claimed was against Unity fundamentals. Using public variables is a design choice, neither good or bad on its own. When talking about code the context is generally more important than blanket statements.

One of the problems with programming theory is that a lot of the large enterprise software development can be far removed from the requirements of game development. A nice video I came across recently about the difference in mindset by Mike Acton is this one:

[1] You would hope the compiler will remove this but it definitely won't in debug builds, so your debug builds run slower.

Thanks for all the thoughts and info, I have become study.

Start up and basic menu in place. Second run shows how you can skip the logos and input check screen by pressing a key/button thus completing the input check before being prompted.