Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Shalinor: No fair! How are any of the rest of us supposed to top that on such short notice?

# ? Jul 29, 2013 02:46

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 00:14

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

Given that the SA theme is "subversive edutainment", it would probably score higher to use jews instead of puppies...

...

I think I'm going to hell for even being able to generate that thought...

# ? Jul 29, 2013 02:46

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Internet Janitor posted:

Shalinor: No fair! How are any of the rest of us supposed to top that on such short notice?

You still have 48 hours. Use that time intelligently. And by intelligently, I mean adding puppies. And kittens. And baby turtles getting tooth brushed on their shells.

EDIT: I may or may not be being totally sarcastic and actually really love the look of the puppies going into the furnace game.

Shalinor fucked around with this message at 04:16 on Jul 29, 2013

# ? Jul 29, 2013 04:04

Synthbuttrange: May 6, 2007

But but Subversively Educational! As in 'things you shouldnt do with puppies'!

# ? Jul 29, 2013 04:07

SneezeOfTheDecade: Feb 6, 2011; gettin' covid all
over your posts

SynthOrange posted:

But but Subversively Educational! As in 'things you shouldnt do with puppies'!

It's totally apropos, it just reminded me that I hadn't played with my dogs in a couple hours, that's all. Your game looks like the kind of thing I would nominally hate and then spend hours and hours playing.

# ? Jul 29, 2013 04:49

TheresaJayne: Jul 1, 2011

Orzo posted:

If I recall correctly, the root of the issue is that the collision event gets fired on BOTH spheres, so he needs a way to *consistently* determine a winner from the perspective of either instance.

That is, the code should be
code:
if (I win the battle)
  Destroy other, make myself grow
else
  Do nothing, the other collision event will take care of business.

Isn't that wrong...

Should it not be

code:

if (i win the battle)
    Make myself Grow based on Size of Other object
else
    Destroy myself

no object should be destroying the other sphere each object deals with itself and nothing else.

# ? Jul 29, 2013 12:46

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

TheresaJayne posted:

Isn't that wrong...

Should it not be
code:
if (i win the battle)
    Make myself Grow based on Size of Other object
else
    Destroy myself
no object should be destroying the other sphere each object deals with itself and nothing else.

Logically that makes sense but it's a bit dangerous since you don't know what order the two calls will play out in or what information might become unavailable on destroy. So it's safer to do both things on the one call, that way you know you're always doing "grow then destroy" rather than having the order determined by some arbitrariness within the engine.

# ? Jul 29, 2013 14:31

TheresaJayne: Jul 1, 2011

roomforthetuna posted:

Logically that makes sense but it's a bit dangerous since you don't know what order the two calls will play out in or what information might become unavailable on destroy. So it's safer to do both things on the one call, that way you know you're always doing "grow then destroy" rather than having the order determined by some arbitrariness within the engine.

So you are saying to ignore all the best practice of the OO development environment in favour of a central monolithic game loop....

If so why use objects in the first place?

# ? Jul 29, 2013 14:37

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

TheresaJayne posted:

So you are saying to ignore all the best practice of the OO development environment in favour of a central monolithic game loop....

Try reading what I said again, because it was nothing like that at all, that's a loving stupid slippery slope argument.
Sometimes it's worth compromising OO purity principles to get a predictable execution order and outcome. That doesn't mean literally everything has to be done the other way.

# ? Jul 29, 2013 14:48

xzzy: Mar 5, 2009

TheresaJayne posted:

So you are saying to ignore all the best practice of the OO development environment in favour of a central monolithic game loop....

If so why use objects in the first place?

I think the "ideal" solution for this kind of problem is to have some kind of overseer that hands out size changes and deletion messages to affected objects (and receives messages from objects when they register collisions). This eliminates the race conditions and lets you keep OO design, just with an added layer.

# ? Jul 29, 2013 14:49

Telarra: Oct 9, 2012

I fail to see how adding an entire new 'overseer' system solves any problems that the 'the winner/only one object takes the actions' approach doesn't, much less solve them well enough to be worth all the added complexity.

I mean really, worst case scenario, you can always just have the object with the bigger GetInstanceID() be the authority on what happens, and *there's* your 'overseer' without the added abstraction layer and overhead costs.

# ? Jul 29, 2013 16:47

SneezeOfTheDecade: Feb 6, 2011; gettin' covid all
over your posts

Moddington, as I understand it, your approach would be something like

code:

private Collide(that) {
    if (this.instanceID > that.instanceID) { // I'm the arbiter
        if(this.isRed OR that.isRed) { // One of us is a red sphere
            if(this.size > that.size OR (this.size == that.size AND random(0,1) > 0.5)) { 
            // I'm bigger, OR we're the same size and I won the coin toss
                this.Wins(that)
            } else {
                that.Wins(this)
            }
        }
    }
}

public Wins(obj) {
    this.getLarger(n);
    obj.Damage();
}

public Damage() {
    this.destroySelf();
}

Is that right? It does seem more elegant than a central controller, and the calculations only have to be run once. The losing object can do whatever data reporting it needs to in Damage() or destroySelf(), and it doesn't violate OO best practices because this isn't actually implementing that's destruction. (It also generalizes Wins() so that it can be used for non-collision interactions if it needs to be.)

(I had Suicide() up there where Damage() is now, but it occurred to me that you could have the function do different things depending on the sphere's type. A red metallic sphere might take two distinct collisions to kill, for instance.)

(Knowing me, though, I've missed something obvious.)

SneezeOfTheDecade fucked around with this message at 17:45 on Jul 29, 2013

# ? Jul 29, 2013 17:39

KoRMaK: Jul 31, 2012

Besesoth posted:

Moddington, as I understand it, your approach would be something like
code:
private Collide(that) {
    if (this.instanceID > that.instanceID) { // I'm the arbiter
        if(this.isRed OR that.isRed) { // One of us is a red sphere
            if(this.size > that.size OR (this.size == that.size AND random(0,1) > 0.5)) { 
            // I'm bigger, OR we're the same size and I won the coin toss
                this.Wins(that)
            } else {
                that.Wins(this)
            }
        }
    }
}

public Wins(obj) {
    this.getLarger(n);
    obj.Suicide();
}

public Suicide() {
    this.destroySelf();
}
Is that right? It does seem more elegant than a central controller, and the calculations only have to be run once. The losing object can do whatever data reporting it needs to in Suicide() or destroySelf(), and it doesn't violate OO best practices because this isn't actually implementing that's destruction. (It also generalizes Wins() so that it can be used for non-collision interactions if it needs to be.)

(Knowing me, though, I've missed something obvious.)

This is how I handle similar situations. Like when a bullet hits a player, the bullet removes itself from the game and then tells the colliding object (which is a player) to do stuff to it's health.

# ? Jul 29, 2013 17:45

No Safe Word: Feb 26, 2005

Besesoth posted:

the kind of thing I would nominally hate and then spend hours and hours playing.

This should probably be the unofficial subtitle of every SA GameDev Challenge.

# ? Jul 29, 2013 17:51

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

I'm not using Unity, but my engine supports the same kinds of constructs, and what I do is use an abstract messaging system to impart damage and other things.

For example, my 'Blob' enemy has code like this for when it collides with another entity, where 'other' is the collision target (the player, for example) and 'Entity' is more or less 'myself'.

code:

other.Trigger(new DamagePlayer(Entity.WorldPosition, BLOB_DAMAGE_AMOUNT));

Now, without knowing anything about the target (i.e. player) the blob can impart a message/trigger to whatever happens to be listening. It's sort of like a targeted event handler system.

The player subscribes to the trigger 'DamagePlayer' and has access to the 'damage source position' (in this case, the blob's position) and the damage amount, and can react accordingly, with a knockback, a state change, and a health decrease. But the 'blob' behavior and 'player' behavior know nothing about each other.

I bet you could set up something very similar in Unity, assuming they support some sort of messaging system.

# ? Jul 29, 2013 17:53

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Orzo posted:

I bet you could set up something very similar in Unity, assuming they support some sort of messaging system.

In fact, they already have one - SendMessage. It's not as efficient as C# events, but it works.

The gist is, any public member of a component can be triggered by a SendMessage targeting the object it's attached to. The limitation is that you can only send one (or zero) arguments.

So if you have "public void WasShot()" in a component on an object somewhere, you can trigger it from, say, a gun shooting it, with "targetObj.SendMessage("WasShot");". That will fire every WasShot method on every single component attached to that game object. You can even make it recursively fire on every child of the game object, if you add an argument to the SendMessage.

# ? Jul 29, 2013 18:01

Toadsniff: Apr 10, 2006; Fire Down Below: Crab Company 2

Hello, I want to get started using Unity as it seems like the platform I want to work off of down the road, but I'm finding out that I need to develop some skills in scripting, I used to do a little (very basic) coding in Flash but gave up after finding out it's probably not going to last. So I wanted to get started with another language (thinking JavaScript as it is ECMA, like AS3) and also some tutorials on how scripting is accomplished. I'm kind lost as where to start the script learning + unity integration process. Please help!

# ? Jul 29, 2013 20:38

Polio Vax Scene: Apr 5, 2009

Download a bunch of samples, play them, choose a random thing and be all like "how did they do that" then go look at the source and figure it out, then mess with it until it breaks. Repeat. Don't learn Javascript if you're starting fresh, may as well get into C#, it's actually friendlier.

# ? Jul 29, 2013 20:43

xzzy: Mar 5, 2009

Toadsniff posted:

Hello, I want to get started using Unity as it seems like the platform I want to work off of down the road, but I'm finding out that I need to develop some skills in scripting, I used to do a little (very basic) coding in Flash but gave up after finding out it's probably not going to last. So I wanted to get started with another language (thinking JavaScript as it is ECMA, like AS3) and also some tutorials on how scripting is accomplished. I'm kind lost as where to start the script learning + unity integration process. Please help!

Find a tutorial for a "my first game" or "hello world" equivalent, whatever, just to get you familiar with the overall workflow in Unity. Then once you start wanting to script your own things, google is your best friend. I guarantee every single question you can think of has a hit on answers.unity3d.com somewhere. From there you emulate the code samples you find and experiment with the results until you get the result you want.

I say this because there doesn't seem to be a decent resource for describing Unity's design scheme or best practices.. it's a whole bunch of "use this hammer to fix every problem until you figure out what drawer the screwdriver is in."

# ? Jul 29, 2013 20:44

Toadsniff: Apr 10, 2006; Fire Down Below: Crab Company 2

Thank you, I will spend some time researching answers.unity3d.com and take a look at C#, will report on my progress when I feel I can actually make something. Thanks again.

# ? Jul 29, 2013 20:48

Sab669: Sep 24, 2009

On the topic of Unity, any good books for absolute beginners? I've got a degree in software engineering and have been working with C# for a year now, haven't looked at any lower-level languages in a long time though. Absolutely no idea where to begin with 2D or 3D art and game dev.

It might take me 10 years but drat it, if Nippon Ichi won't port their Disgaea games to PC I'll make something similar :argh:

# ? Jul 29, 2013 20:49

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

Start right here for the easiest transition into Unity: http://www.unity3dstudent.com/

e: this goes for both of you i guess :v:

# ? Jul 29, 2013 20:50

xzzy: Mar 5, 2009

Yodzilla posted:

Start right here for the easiest transition into Unity: http://www.unity3dstudent.com/

e: this goes for both of you i guess

loving video tutorials man. Am I the only person left on the internet who prefers a static html document with still pictures?

It's so much easier to flip back and forth in a simple text document. :qq:

# ? Jul 29, 2013 20:51

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

I agree with you completely but I imagine people don't do them mostly because they're more time consuming to create.

# ? Jul 29, 2013 20:54

Toadsniff: Apr 10, 2006; Fire Down Below: Crab Company 2

Is Unity 3.x much different than 4.x? Like can I get a book or a Lynda tutorial for 3.x and still be able to use the free 4.x version efficiently?

# ? Jul 29, 2013 21:00

Lanithro: Aug 31, 2006

I have a question about 2D collision detection against the environment (e.g. walls, unwalkable paths, etc).

In unity, mesh colliders seem to be the thing to get this done. Using colliders on objects that move around makes sense (I'm actually using Futile, so I'm planning to avoid Unity's colliders for as much as I can, anyway); however, it seems kind of expensive to do this for the environment in a 2D game.

Consider this image from Zelda:

Using mesh colliders, you would have to create a bunch of cubes like so:

This seems like overkill to me. What I have considered doing is just creating a greyscale image that defines the walkable path on the map:

There are a few things you can do with this, but I think the most simple is to just read in just the black pixel's coordinates into a hashtable/dictionary/whatever-you-want-to-call-it when the level is loading (or have a text file built ahead of time).

Then you can check each coordinate of the character's bounding box to see if they've run into the environment by checking if the coordinate exists in the hash table, which would be a constant-time operation and much more efficient than checking more complicated intersections ala colliders.

Does this sound reasonable?

Edit: also, kind of funny: another approach is what an old XNA tutorial recommended, but is kind of janky. You can render this greyscale map onto a rendertarget and check the character's bounding box pixels against the pixels on the rendertarget -- since this is continually copying data from the GPU to CPU using GetPixels(), it could potentially cause the game to hang while the data is being copied.

Lanithro fucked around with this message at 21:37 on Jul 29, 2013

# ? Jul 29, 2013 21:29

Polio Vax Scene: Apr 5, 2009

Checking a pixel against another pixel is fast, but when you start checking each pixel of a character's bounding box it becomes easier to just say "does this box intersect this box y/n".
Your method also falls short when the 'walkable' area constantly changes, or changes based on certain conditions.

# ? Jul 29, 2013 21:45

Vinterstum: Jul 30, 2003

Lanithro posted:

however, it seems kind of expensive to do this for the environment in a 2D game.

Why do you think this is expensive?

Unless the greyscale image approach actually saves you implementation time, this smells like a premature optimization. Mesh vs. mesh collision of super simple meshes (boxes) like this is generally pretty cheap.

# ? Jul 29, 2013 22:04

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

Or just use box-colliders instead of meshes.

http://docs.unity3d.com/Documentation/Components/class-BoxCollider.html

# ? Jul 29, 2013 22:09

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Lanithro posted:

Does this sound reasonable?

No, it doesn't sound reasonable, because you're operating on a number of false assumptions.

1) The original way isn't 'overkill.' Making each block of the wall into its own collider also isn't 'overkill'--any reasonable spatial hashing algorithm is going to cut the computation cost to 'trivial' for you.

2) The proposed way is more complex.

3) What are you going to do for off-screen collisions? Don't bind your rendering behavior to your physics behavior.

# ? Jul 29, 2013 22:18

SuicideSnowman: Jul 26, 2003

Lanithro posted:

I have a question about 2D collision detection against the environment (e.g. walls, unwalkable paths, etc).

In unity, mesh colliders seem to be the thing to get this done. Using colliders on objects that move around makes sense (I'm actually using Futile, so I'm planning to avoid Unity's colliders for as much as I can, anyway); however, it seems kind of expensive to do this for the environment in a 2D game.

If a video game device that was designed 20 years ago and was merely a fraction as powerful as a modern day phone was capable of handling collision in most likely a similar way, I'm not sure why you'd consider this "expensive".

# ? Jul 29, 2013 22:29

Lanithro: Aug 31, 2006

Vinterstum posted:

Why do you think this is expensive?

Unless the greyscale image approach actually saves you implementation time, this smells like a premature optimization. Mesh vs. mesh collision of super simple meshes (boxes) like this is generally pretty cheap.

I think it would get expensive once you start having diagonal or concave paths. I expect that it would become a lot more than checking 4 corners in a short-circuit evaluation, but maybe it's not as bad as I think.

Here's an example of a diagonal path. I think in Unity, I may be able to get away with a series/hierarchy of circles and cubes to create the shape, but I'm not sure whether or not that would be faster than checking each pixel of the character's bounding-box (40 pixels max for the feet area, maybe).

Orzo posted:

No, it doesn't sound reasonable, because you're operating on a number of false assumptions.

1) The original way isn't 'overkill.' Making each block of the wall into its own collider also isn't 'overkill'--any reasonable spatial hashing algorithm is going to cut the computation cost to 'trivial' for you.

2) The proposed way is more complex.

3) What are you going to do for off-screen collisions? Don't bind your rendering behavior to your physics behavior.

Total beginner here, so apologies if I sound nuts. I wasn't really planning on allowing anything sufficiently off-screen to update.

Lanithro fucked around with this message at 22:40 on Jul 29, 2013

# ? Jul 29, 2013 22:34

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Lanithro posted:

I think it would get expensive once you start having diagonal or concave paths. I expect that it would become a lot more than checking 4 corners in a short-circuit evaluation, but maybe it's not as bad as I think.

It isn't. Trust us.

Lanithro posted:

Total beginner here, so apologies if I sound nuts. I wasn't really planning on allowing anything sufficiently off-screen to update.

No worries, you don't come off as nuts, just pointing out what I think is true and will end up saving you some grief in the long run.

Orzo fucked around with this message at 22:59 on Jul 29, 2013

# ? Jul 29, 2013 22:38

FuzzySlippers: Feb 6, 2009

I also pretty much never use mesh colliders and always use box and this is even in 3D.

This sounds like way premature optimizations to me though. I don't believe collision is ever going to be where you are losing performance but instead only what you are doing with that collision data could cause slowdown. I pull an excessive amount of information about collisions every frame (due to managing physics myself instead of letting Unity do it for the pc) and I've never had that impact performance.

If part of your objective is to avoid having to set up mesh colliders manually it isn't hard to do something like you want with your hash table and then use that data to generate box colliders where they need to be.

# ? Jul 29, 2013 22:41

Workaday Wizard: Oct 23, 2009; by Pragmatica

This talk about collision hashes reminded me that I've never done anything that demanded better collision performance than naive collision checking.

Anybody got good references for the fancier algorithms? So far the only one I tried to implement was the quad tree one but I didn't finish my implementation because :effort:

and it wasn't worth it for my basic game.

E: woah check out the length on those sentences. Shakespeare look out here I come

# ? Jul 29, 2013 22:45

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

FuzzySlippers posted:

I also pretty much never use mesh colliders and always use box and this is even in 3D.

Yeah it's pretty incredible what you can get done with only box colliders even in seemingly complex situations.

If you really want to create complex meshes from sprites easily, a buddy showed me Uni2D the other day. Seems kinda neat?

https://www.youtube.com/watch?v=mE2Pmujbaw0

# ? Jul 29, 2013 23:25

Xerophyte: Mar 17, 2008; This space intentionally left blank

Shinku ABOOKEN posted:

Anybody got good references for the fancier algorithms? So far the only one I tried to implement was the quad tree one but I didn't finish my implementation because and it wasn't worth it for my basic game.

Real-time collision detection is a really nice reference book, if you like reference books. If you just want an overview then I'm less sure. Wikipedia should work I guess?

# ? Jul 30, 2013 00:16

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

Cross posting this here, in Unity I want to create a wavy shader effect sort of like what some SNES games did for water. An example can be seen here in Metroid:

https://www.youtube.com/watch?v=gBLIyqF_nRM&t=1270s

What exactly is this called and what should be looking for to learn how?

# ? Aug 3, 2013 05:47

Zizi: Jan 7, 2010

Yodzilla posted:

Cross posting this here, in Unity I want to create a wavy shader effect sort of like what some SNES games did for water. An example can be seen here in Metroid:

https://www.youtube.com/watch?v=gBLIyqF_nRM&t=1270s

What exactly is this called and what should be looking for to learn how?

We were discussing distortion map shaders in one of the threads a week or so ago, maybe. That would probably do the trick. I think Orzo brought it up for his game.

# ? Aug 3, 2013 07:01

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 00:14

Spatial: Nov 15, 2007

Not a Unity user, but hopefully my explanation will still be useful.

The basic principle behind the effect is applying an X offset based on a waveform generated from the Y position plus some constantly increasing value. Super Metroid uses a triangle wave.

Here's a triangle wave generator. Given a linearly increasing input F it produces a wave in the inclusive range [-1:+1], one dip and peak per period.

code:

float triwave( float f, float period ) {
    float phalf = period * 0.5;
    float fmp   = mod(f, period) - phalf;
    float wave  = abs(m / phalf);
    return (wave - 0.5) * 2.0;
}

Applying the effect is pretty simple:

code:

float wave = triwave(texcoord.y + currentTime, wavePeriod);
texcoord.x += wave * waveRange;

In practise you'd want to scale the values by the texture size so you can work in pixels.

A sine wave looks a bit more watery. Generating one from a linear input is similar:

code:

float sinewave( float f, float period ) {
    float phalf = period * 0.5;
    float fmp   = mod(f, period) - phalf;
    float pm1   = fmp / phalf;
    return sin( pm1 * pi );
}

Here's the effect applied to an image with these parameters:
waveRange = 2
wavePeriod = 16

Normal:

Triangle wave:

Sine wave:

# ? Aug 3, 2013 18:43

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »