Game:

Counter-Strike: Source (2004)

Category:

Guide

Duration: 7:02

74 views

1

M-muh muh-muh muh property... muh property!
twitter.com/yuugijoou
discord.gg/bKT9pRW

---

Alice's Guide
The Basics of Object Properties

Now this is a topic that I took a bit more interest in than I probably should have during the lessons themselves, but I find what makes, breaks, and even inspires game design within a humble little tool such as this will be the lengths and limitations the basic building blocks have imposed upon them.

Maybe that sounds a little dramatic to you, because OBVIOUSLY game design is putting people and things and STUFF all over the place and letting 'em all have at each other until... whatever the object of the game is runs its course. Or doesn't. I don't know, it's YOUR hypothetical... that I'm attributing to some mystery second-person audience member. (Yeah, I'm talking to YOU, Christopher!)

(At some point... that's going to run the serious risk of confusing someone named Christopher. Y'know, if anyone read descriptions. On videos most people have better sense than to click on in the first place... it's still not a ZERO percent chance that could happen!)

But that's where Christopher would be wrong! And the (equally-hypothetical) non-Christophers (and also Christophers who didn't have the hypothetical idea to interrupt my lecture, don't think I've unfairly lumped you all together like that!) would be right to sit quietly and nod their head.

Programming is a descriptive art, limited only by the manner in which we choose to describe the things we're dealing with. If the "language" (oh no, I'm getting dangerously close to what people call "programming" when they actually mean "coding"!) with which you describe the objects within a scenario of your own design is limited, so too will be your ability to control and engage with the interactions between those objects.

In Mario games, we take for granted that you stand on ground, you hit blocks to break them, and you stomp on enemies before they can hurt you... but what does a computer know about any of these concepts? What makes a "Mario" different from an "enemy"? What makes a "block" different from the "ground"? What even differentiates different enemies or blocks?! (What about a "Mario" from a "Luigi"?!)

For starters, you can specify that "enemies" of their various diabolical construction have the "property" that they hurt. "Blocks" and the "ground" are for standing on. "Enemies" and some types of "blocks" can be destroyed, while other kinds of "blocks" and the "ground" are typically stationary and indestructible. Or any of the three categories could have the ability to move freely in some fashion or another! A machine can understand such descriptors and apply them broadly or narrowly to know how to make things act in certain situations... WITHOUT you having to dictate the specifics of each and every one every time you want to use them. Then you, the designer, can focus on putting them into place and letting them act out their routines for the player to interact with.

Careful, though! With all these objects with their various properties designed from the outset, you might find that the descriptive language you used to tell the computer guiding their actions and responses was not handled specifically enough, and unintended consequences arise. The descriptive nature of properties will be as powerful or as weak as the "wording" you use to set them up in the first place!

---

Oh, um... I mean... we were meant to get into the BASICS, right?

Alice has the right idea, let's stick with down-to-earth concepts... like what it means to be "solid" or "visible" or "movable"... and... um... "destructible" and "destructive"?

Since it's only (supposed to be) the basics, I probably shouldn't call attention to the extra "..." tabs on the end of certain properties... and we're definitely not ready for whatever "Other" means! (...but that just lets us know that there's plenty more where this came from!)

Personally, I think Alice's little show-and-tell sequence speaks well enough for itself... so I'll spare you a retread and instead offer my own personal reactions and insights into what's going on...

If the "Solid" property is disabled... it means intangible to ALL things, including the baseline "ground" that we ignored for the sake of Ultimate Tag.

"Destructible" and "Destructive" are relative. An Object can be one, both, or neither... and, for that matter, it can presumably be selectively destructible or destructive to other Objects, seeing as how it has more to tinker with if you dig down into that "..." tab... but let's stick with the basics for now.

Something that's "Invisible" still exists!

Using stuff to destroy other stuff or be destroyed by stuff is pretty self-evident in its applications to game-making... but what kinds of sneaky tricks could the others just found in these examples let people get up to?!

I think that's up for clever builders to game around with, and I wouldn't want to spoil the surprises they have in store!

Other Statistics