Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
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!

Sarcophallus posted:

I didn't know that, actually. So could I generated mostly-random geometry, like rooms, with textures in place, or does it have to use pre-fabricated objects?
Yeah, you can generate everything, use all prefabs, mix and match, or even do strange hybrid things, eg. I made a function where you give it an object (which might be from a prefab) and a plane, and it chops it into two objects, slicing along the plane. By slicing on a few random planes you can smash an object into chunks. Procedurally generated geometry, but based on prefab models.

So you could, eg. use a prefab as a model but generate a new object based on it where you've adjusted the geometry by some algorithm. Or you can just generate geometry from scratch virtually the same way you would if you were working with raw DirectX or OpenGL. You have access to the geometry right down to the "points and indices and texture coordinates" level, and you can apply your own shaders for drawing. The only limitation I've encountered really is that it's a bit slower at direct geometry mangling than raw C++ would be, but so long as you're not doing it on the fly that's really not an issue - and even if you are doing it on the fly, smashing a cube into 128 arbitrary-shaped pieces using my slice function, which actually requires generating 255 chunks because there are all the intermediate chunks too when it's done by halving, only takes the framerate down to 30ish for the one frame you do it in, from 60, which is a barely noticeable jostle. And my computer isn't all that high-end.

So in essence, so long as you're not regenerating an entire complex scene from scratch every frame, it's just fine.

Adbot
ADBOT LOVES YOU

Unormal
Nov 16, 2004

Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
Fun Shoe

roomforthetuna posted:

To be fair, it's hard to make a habit of typing "==" when you often actually need to type "=", whereas it's relatively easy to make a habit of putting the "low priority" comparators first because you rarely need to put them second. (I say "low priority" because yeah, sometimes there's no constant operand, and it would tend to fray the habit if you don't have something consistent there.)

And if you make that a habit then it might sometimes catch a typo for you.

But I agree that it's really probably more trouble than it's worth and tends to make the code less intuitive to read. In that respect it's similar to endorsing "x.multiply(y.add(5))" over overloading operators.

As a random thought, I rarely (never) make this mistake, even though I don't use the "safer" boolean-first pattern, even in C++. (even though I am prone to many other similar sorts of fat-finger mistakes.) I and a co-worker once tried to figure out why during a code review; we realized that when I say the statement out loud (or think it in my head as I type it), I say "equals" for assignment and "does equal" (saying 'does' when I type the first equal, and 'equal' for the second) for equality. I guess my brain just automatically internalized the different grammar. Go-go gadget homo-sapiens language instinct. Not thinking "equals" for both cases helps me hijack my instinctual language centers to help me automatically avoid the issue, since you'd (I'd) never say "equals" in an if statement, that's just "wrong feeling", you always say "does equal"! :pseudo:

e: For procedural work in Unity, I find it to be quite good. However, object creation, in particular, is pretty drat slow. However, you can use pooling strategies to work around this pretty satisfactorily.

Unormal fucked around with this message at 23:16 on Apr 1, 2013

Shalinor
Jun 10, 2002

Can I buy you a rootbeer?

roomforthetuna posted:

Yeah, you can generate everything, use all prefabs, mix and match, or even do strange hybrid things, eg. I made a function where you give it an object (which might be from a prefab) and a plane, and it chops it into two objects, slicing along the plane. By slicing on a few random planes you can smash an object into chunks. Procedurally generated geometry, but based on prefab models.
Would you be willing to share this function? :3:

(though unless you're disabling the original object and making all new ones, I bet it'd play havok with a spawn pool... but that'd be easy to account for)

Incidentally, the one caution I would apply to roomforthetuna's post is that creating new objects - Instantiate - is massively more expensive on mobile. We're talking "framerate hitches if you instantiate even a few objects in a single frame" severe. Optimizing Unity 3D on mobile requires some care, previous experience (or a friend with such), and most certainly a spawn pool. On PC though? There's way less to worry about, it works basically as you'd expect / normal optimization rules apply.

EDIT: Though it's possible that the same is true on any lower powered hardware. It's just that the bar for average desktops these days is so high, Unity's intrinsic overheads barely register.

Shalinor fucked around with this message at 23:52 on Apr 1, 2013

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!

Shalinor posted:

Would you be willing to share this function? :3:
It's truly hideous, but I'll see if I can find it - at the very least it might be educational about how one goes about wrangling geometry, it took me a while to find that poo poo.

quote:

(though unless you're disabling the original object and making all new ones, I bet it'd play havok with a spawn pool... but that'd be easy to account for)
Yeah, I was just making new objects, it's not optimized. It occasionally struggled with the physics of the new objects overlapping slightly and thus catapulting things into space, too, I forget whether I fixed that. Probably did.

I'll get back in a few minutes if I can find the function.

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!
Here it is - javascript! It must have been one of the first things I did, because I switched to using C# pretty early on in my Unity-ing.

(Ha ha, the only code comments are the two lines at the top saying how to use the functions!)

Edit: note, "Instantiate" is only used in the "MakeChunk" function, which is to do with putting a particular texture on the sliced sides of the new objects - if there isn't a texture then they're just made with "new GameObject" which I suspect is significantly less resource-hogging, though still not great.

Edit2: maybe? gently caress knows what I was doing, I've not looked at that code in a year and I only did a very cursory glance at it just then because I remembered more 'new' and not so much 'Instantiate'.

Edit3: oh yeah, it's also doing a bunch of other stuff - what I actually did with it was shatter an object and then bind the pieces back together in their original positions using weak fixed joints, when something smashy approaches the target object - that way when it actually hits, the physics can smash it apart appropriately, rather than turning it into blocks and trying to apply the forces at the same time. I should probably have made that a separate function really, but I wasn't going for reusable or expecting to give the code to anyone.

roomforthetuna fucked around with this message at 00:57 on Apr 2, 2013

SlightlyMadman
Jan 14, 2005

I'm trying really hard to understand Unity, but I'll freely admit that I tend to view an IDE as something that's in the way between me and my code.

I've been going through this tutorial but I'm completely stuck
http://catlikecoding.com/unity/tutorials/runner/

I've gotten to a point where I'm supposed to "drag the Skyline Close prefab onto the Prefab field of our Skyline Close Manager" but I have no "Prefab" field. I can see clearly in the screenshot where it's supposed to be, but it's just not there. I'm sure this is simply because I forgot to check some box at some point that makes this component eligible for prefab inclusion, or I dragged something into the wrong something else and nothing will ever work now, but it's extremely frustrating.

I was looking into Futility, but I'm not really seeing the point of using unity at all then?

poemdexter
Feb 18, 2005

Hooray Indie Games!

College Slice

SlightlyMadman posted:

I was looking into Futility, but I'm not really seeing the point of using unity at all then?

Futile is a 2D lib that harnesses all the power of Unity. It's 99.9% C# code and you only hit play to test. You have access to all Unity stuff in your code along with his great library. It's like XNA without all the annoying poo poo.

TastyShrimpPlatter
Dec 18, 2006

It's me, I'm the

SlightlyMadman posted:

I'm trying really hard to understand Unity, but I'll freely admit that I tend to view an IDE as something that's in the way between me and my code.

I've been going through this tutorial but I'm completely stuck
http://catlikecoding.com/unity/tutorials/runner/

I've gotten to a point where I'm supposed to "drag the Skyline Close prefab onto the Prefab field of our Skyline Close Manager" but I have no "Prefab" field. I can see clearly in the screenshot where it's supposed to be, but it's just not there. I'm sure this is simply because I forgot to check some box at some point that makes this component eligible for prefab inclusion, or I dragged something into the wrong something else and nothing will ever work now, but it's extremely frustrating.

I was looking into Futility, but I'm not really seeing the point of using unity at all then?

Make sure that your prefab field is public. Also worth trying to run your project and see if it gets updated in unity (I've noticed the inspector is slow to update code changes sometimes)

superh
Oct 10, 2007

Touching every treasure

MrSamurai posted:

Make sure that your prefab field is public. Also worth trying to run your project and see if it gets updated in unity (I've noticed the inspector is slow to update code changes sometimes)

Or, if you haven't finished debugging all classes (even ones you're not worried about at the moment) to remove all errors, the inspector will never update.

SlightlyMadman
Jan 14, 2005

poemdexter posted:

Futile is a 2D lib that harnesses all the power of Unity. It's 99.9% C# code and you only hit play to test. You have access to all Unity stuff in your code along with his great library. It's like XNA without all the annoying poo poo.

So is the idea that I could use Futile to render 2D sprites on a 3D landscape, like earlier 3D games did? The banana game in the demo seems like it could be written much easier with XNA or MonoGame, or for that matter one of the python 2D libs.

MrSamurai posted:

Make sure that your prefab field is public. Also worth trying to run your project and see if it gets updated in unity (I've noticed the inspector is slow to update code changes sometimes)

I'll check that tonight, but I don't even know how to pull up the code for the prefab field? I created a prefab by dragging something into something else.

To clarify what I'd like to accomplish, I want to put together something like the recent Anno games, where there's a 3D environment that the player can plop buildings and draw roads on. I'm totally fine with it being a completely flat game with untextured blocks dropped on it for the moment. I'm about ready to give up and go back to isometric tiles, but I'd really prefer a 3D environment so the player can move the camera around.

The Gripper
Sep 14, 2004
i am winner

SlightlyMadman posted:

So is the idea that I could use Futile to render 2D sprites on a 3D landscape, like earlier 3D games did? The banana game in the demo seems like it could be written much easier with XNA or MonoGame, or for that matter one of the python 2D libs.
It's not particularly amazing if you're just targeting PC, but for someone targeting multiple platforms having a 2D framework that can out-of-the-box support everything you need without changes it's a huge timesaver.

SlightlyMadman
Jan 14, 2005

The Gripper posted:

It's not particularly amazing if you're just targeting PC, but for someone targeting multiple platforms having a 2D framework that can out-of-the-box support everything you need without changes it's a huge timesaver.

Windows/Linux is definitely a priority for me, so I guess that's a good reason. I guess I'll give Futile a shot. I was also discouraged reading some forum posts about it not handling more than a few hundred sprites well, which could be a problem since I'd be building a tile-based game, but I'm sure I could work around it somehow.

Chunderstorm
May 9, 2010


legs crossed like a buddhist
smokin' buddha
angry tuna

SlightlyMadman posted:

Am I the only one who would type that as "if (!s.sortedInTurnOrder)"?

No, and normally I would, but I've been frantically writing these scripts and can't be assed to go back and fix it as long as it's working. :v:

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!

SlightlyMadman posted:

Windows/Linux is definitely a priority for me, so I guess that's a good reason. I guess I'll give Futile a shot. I was also discouraged reading some forum posts about it not handling more than a few hundred sprites well, which could be a problem since I'd be building a tile-based game, but I'm sure I could work around it somehow.
Tile maps are generally not implemented as individual sprites.

SlightlyMadman
Jan 14, 2005

roomforthetuna posted:

Tile maps are generally not implemented as individual sprites.

Interesting, that's the only way I've ever seen it done. How else would you do it? I'm not too familiar with how feasible this would be in Futile, but the only other technique I've used was to blit the tiles to an off-screen layer then blit that as a single image to the display, but that can actually end up being slower.

Orzo
Sep 3, 2004

IT! IT is confusing! Say your goddamn pronouns!
I too am wondering why you would ever implement tile maps as anything but instances of sprites that happen to be positioned in a certain way with no rotation and a fixed size.

Unormal
Nov 16, 2004

Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
Fun Shoe
I just do mine with individual sprites; but I could see instantiating big mapped meshes being faster to load than instantiating all the individual sprite objects, in Unity, because of how costly game object instantiation is.

SlightlyMadman
Jan 14, 2005

Orzo posted:

I too am wondering why you would ever implement tile maps as anything but instances of sprites that happen to be positioned in a certain way with no rotation and a fixed size.

Wow, thanks for being super condescending instead of actually offering any useful information. So can I blit an image to a screen without defining it as a sprite in Futility? I've never used the framework before and there's no documentation, so I seriously have no clue.

Unormal posted:

I just do mine with individual sprites; but I could see instantiating big mapped meshes being faster to load than instantiating all the individual sprite objects, in Unity, because of how costly game object instantiation is.

Yeah, this seems to be the issue with it. You can either instantiate all your sprites and run into problems with it crapping out after a few hundred, or instantiate them as needed for display and suffer serious delays from object instatiation.

I'll look into the mesh mapping though, thanks for the tip!

SlightlyMadman fucked around with this message at 17:48 on Apr 2, 2013

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!

SlightlyMadman posted:

Interesting, that's the only way I've ever seen it done. How else would you do it? I'm not too familiar with how feasible this would be in Futile, but the only other technique I've used was to blit the tiles to an off-screen layer then blit that as a single image to the display, but that can actually end up being slower.
Like Unormal says, a big mesh (or possibly several smaller-than-the-whole-thing-but-bigger-than-one-tile meshes) is pretty common for tilemap rendering. Ideally you also do some sort of generated collision objects rather than having one for each tile, if you're using physics - not only does it make it faster, but it also eliminates issues with potentially catching on 'corners' while travelling on a flat surface.

Flixel certainly does tilemaps this way (albeit not as a mesh) as a separate object because hundreds of FlxSprites is performance-awful.

I also found this, which appears to have a Futile tilemap class, but I don't know if that's just a wrapper around lots of sprites or if it's doing something proper, I didn't really look into it, just googled for Futile tilemap.

SlightlyMadman
Jan 14, 2005

Yeah, I found that as well, plus a couple discussions, and they all use one sprite per tile. I guess I'll use something else if this is going to suck at a tile based game.

Orzo
Sep 3, 2004

IT! IT is confusing! Say your goddamn pronouns!

SlightlyMadman posted:

Wow, thanks for being super condescending instead of actually offering any useful information. So can I blit an image to a screen without defining it as a sprite in Futility? I've never used the framework before and there's no documentation, so I seriously have no clue.
What the hell? How is echoing your exact question and sentiment being 'condescending?'

Edit: Re-reading, I'm thinking maybe you thought I was making fun of you or being ultra sarcastic? I wouldn't do that, and I didn't--I was being sincere.

Orzo fucked around with this message at 18:50 on Apr 2, 2013

SlightlyMadman
Jan 14, 2005

Orzo posted:

What the hell? How is echoing your exact question and sentiment being 'condescending?'

Edit: Re-reading, I'm thinking maybe you thought I was making fun of you or being ultra sarcastic? I wouldn't do that, and I didn't--I was being sincere.

Oh wow, I'm sorry, I completely misunderstood you. I thought you were being sarcastic because it should be obvious to me that sprites are the wrong thing. I was probably also reading your post in Duke Nukem's voice.

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!
A quick caveat so I'm not endorsing bad advice too strongly - I don't know what Unity or Futile does under the hood, so it could be that a tilemap consisting of hundreds of sprites that aren't interacting significantly is fine.

Chances are, if Futile doesn't implement a sprite as a GameObject then it's probably fine to just make your tilemap out of lots of sprites.

If, on the other hand, each sprite is a GameObject then tilemaps implemented that way is almost certainly a bad idea.

Unormal
Nov 16, 2004

Mod sass? This evening?! But the cakes aren't ready! THE CAKES!
Fun Shoe
Do you really need that many at once though? If you have 11 bajillion tiles, but only a hundred are on the screen at once, you could certainly just use a pool of a hundred actual active sprite objects and just recycle to and from the pool as the underlying objects come and go from the display.

Orzo
Sep 3, 2004

IT! IT is confusing! Say your goddamn pronouns!

roomforthetuna posted:

A quick caveat so I'm not endorsing bad advice too strongly - I don't know what Unity or Futile does under the hood, so it could be that a tilemap consisting of hundreds of sprites that aren't interacting significantly is fine.

Chances are, if Futile doesn't implement a sprite as a GameObject then it's probably fine to just make your tilemap out of lots of sprites.

If, on the other hand, each sprite is a GameObject then tilemaps implemented that way is almost certainly a bad idea.
This is pretty interesting to me. In the engine/game I'm working on, I started off with separate 'Tile' and 'Entity' classes, but eventually realized the overlap between the two was too great to warrant separate logic. So now, everything is an Entity. I consider my Entity class to be sort of a 2D (and much simplified, I'm sure) version of Unity's 'GameObject' class--you can attach a collision model, scripting behaviors, child entities, manipulate a transformation node, property controllers (basically things that modify properties over time, like making a pulsing effect or a fade-out transition). But all of these things are totally optional (except the transformation node), so tiles end up being Entities with basically a fixed position and size, no rotation, a texture/animation, and a layer. So far this is working out great for me, so I guess I'm wondering why you would claim that it would be 'almost certainly a bad idea' for Futile.

Orzo
Sep 3, 2004

IT! IT is confusing! Say your goddamn pronouns!

Unormal posted:

Do you really need that many at once though? If you have 11 bajillion tiles, but only a hundred are on the screen at once, you could certainly just use a pool of a hundred actual active sprite objects and just recycle to and from the pool as the underlying objects come and go from the display.
There are actually a number of ways to solve this problem, depending on what you're doing. If you really do have an enormous amount of tiles (11 bajillion or more), you're going to want to do some sort of live data streaming, as loading all tiles into memory at once is not feasible.

Regardless of your strategy for holding the level in memory, almost all performant engines use some sort of space partitioning structure (for 2D, generally a quadtree or a fixed grid) for determining what polygons need to be rendered (these structures are also used to optimize collision).

If you are doing data streaming extremely quickly to the point where object creation and destruction are actually expensive (I don't think this is really that common--it can be useful for particle systems, though), then using a pool of objects like you said helps for a few reasons, namely increasing performance via less object initialization and less garbage generated (for GC'ed languages)

Polio Vax Scene
Apr 5, 2009



Here's what I do for my game. Since it's relevant sort of. Fully homemade tile system with lots of :spergin: mixed in.

Each tile is placed individually, but after being placed, the 'chunk' that that tile is in groups tiles together into two groups, first based on collision, then based on drawing.


This is the collision mask, it works by trying to merge the tiles horizontally then vertically. Then vertically first, and uses whichever one has less rectangles. The number of collision rectangles is reduced from 57 to 6! Shadows from lights use these for calculations, along with movable game objects. I forgot to place a light source before this writeup though.

Drawing is an entirely different beast, tiles have to be grouped based on texture and depth:

First the textures are drawn (repeating textures) without borders or shadows. That's 9 rectangles, indicated by the light blue.

Then borders and shadows are added on a per-tile basis, which are then regrouped so that repeating borders or shadows are done in one draw. Below you can see bottom borders in yellow, and right borders in green, with an X indicating which tile 'owns' that border and thus draws it.

You can't see it in this image but the green tiles are a lower depth than the others, and the surrounding tiles are casting shadows on them as well. The shadows use the same border-grouping code, except corners are treated differently.

All of the drawing optimization is wasted effort as the entire thing is prerendered to a surface stored by the chunk which then gets drawn in a single square each redraw anyway :smith:

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!

Orzo posted:

so I guess I'm wondering why you would claim that it would be 'almost certainly a bad idea' for Futile.
Again, I don't really know what Unity is doing under the hood, which is why the "almost", but I do know that it takes significantly long to instantiate a GameObject, which to me implies that GameObjects are very likely a bit resource-heavy in some way. At an absolute minimum, every tile would end up with an unnecessary 3D transformation object, since all GameObjects have a transform. And unless the sprite class has completely worked around what Unity does, the tiles would presumably all undergo an unnecessary distinct 3D transformation on rendering too.

And even if none of that's a problem, it'd be infuriating when you [accidentally] click to expand the contents of your "tilemapcontainer" object in the editor-debugger (I assume you'd put all the tiles in a container because otherwise this problem would be all the time) and it has to expand out several thousand items.

And again, that's all on the assumption that Futile's sprites are a subclass of GameObject, which they may not be, I am not familiar with Futile.

I'm not knocking doing things that way in your own engine, absolutely it makes sense to do a tilemap as a collection of sprites if your engine has slim sprites and other things will still operate appropriately. Though even then you might still want something for not even iterating through them to determine whether rendering them is necessary, when they're far off screen, for big maps.

Orzo
Sep 3, 2004

IT! IT is confusing! Say your goddamn pronouns!
Oh, I didn't think you were criticizing the way I was doing it, no worries. I was just trying to understand your general philosophy, but as you've explained its not so much about engines in general as it is about Unity, and specifically how long it takes to instantiate a GameObject. I wonder why it takes so long? Transformation objects specifically are usually just a few properties and possibly a couple of cached matrices, but maybe Unity is doing something fancier.

roomforthetuna posted:

Though even then you might still want something for not even iterating through them to determine whether rendering them is necessary, when they're far off screen, for big maps.
I use spatial hashing with a grid for this. That is, my entire map is divided up into a 2D array of cells sized 32x32 (which is the same size as my tiles). The viewport figures out which of these cells are currently visible (which is at most a few hundred) each frame, and then gets the contained entities in all of these cells, and draws those. When an entity moves at all, it's marked as grid-dirty, which means its grid cells will be updated at the end of the frame. For tiles, this is pretty much never, so it performs very well.

Calling Update() on every entity on every frame adds quite a processing time. Even a map with 400x400 tiles would be 160,000 updates every frame. Even if they're basically no-ops, this is a huge waste of time. So I do a trick with Update() where I maintain a list of 'live' entities. Every entity (and thus every tile) starts off as 'alive', but will 'die' during the Update() call if there's no reason to keep it alive anymore--that is, there are no property controllers (this includes the thing that updates the animation frame, like a water texture or something), no update scripts, etc. If some other script adds some kind of script or controller to that entity, it will 'wake' that entity up. So when I start a level, the first frame of the game might update 500,000 entities, but the next frame and every frame after might only be 100-200 updates.

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!

Orzo posted:

Calling Update() on every entity on every frame adds quite a processing time.
Yeah, I'm not sure whether Unity would be doing that behind the scenes for things that don't have an explicit Update function on a component on them, but that's another thing I'd be wary of for using GameObject-based tiles.

Even if that is an issue, I guess it might be okay if you go around disabling all the tiles that go off-screen. But I'm still not sure - does Unity iterate through all the objects going "if (enabled) call functions" or does it maintain a list of enabled-GameObject-update-functions to call or what? We just don't know.

My conclusion is, I'm not sure what Unity would do with a tilemap made of GameObjects, but I'm convinced enough that it would be bad that if I were implementing a tilemap, I would not take the time to do it that way and see, rather than taking a bit longer in the first place implementing a lower-level tilemap class.

SlightlyMadman
Jan 14, 2005

Honestly it sounds like Unity just isn't suited for games on a tiled grid.

Shalinor
Jun 10, 2002

Can I buy you a rootbeer?

roomforthetuna posted:

Yeah, I'm not sure whether Unity would be doing that behind the scenes for things that don't have an explicit Update function on a component on them, but that's another thing I'd be wary of for using GameObject-based tiles.
Adding an Update() method to a Unity class registers it for updates - if you don't add one, that cost isn't there. If you want to do your own updates, but only update based on proximity or whatever, you can make your own ProximityUpdate() that you call or don't call as you see fit. You could even use a fancy C# delegate that your components register on if they're within range, and the whole thing would be largely hands-off.

SlightlyMadman posted:

Honestly it sounds like Unity just isn't suited for games on a tiled grid.
Unity's not suited to anything, it's just a component-based game engine. It would be crackerjack at doing a 3D grid, if you cared to write the logic.

What Unity isn't suited to is 2D. For that, you want to plug in Futile, or grab 2DToolkit or SpriteManager 2. Then, Unity's perfectly suited to 2D.

Shalinor fucked around with this message at 22:02 on Apr 2, 2013

SlightlyMadman
Jan 14, 2005

Shalinor posted:

Unity's not suited to anything, it's just a component-based game engine. It would be crackerjack at doing a 3D grid, if you cared to write the logic.

What Unity isn't suited to is 2D. For that, you want to plug in Futile, or grab 2DToolkit or SpriteManager 2. Then, Unity's perfectly suited to 2D.

Yeah, I'm checking out Futile, but I said the above in response to the consensus here that the game object inefficiencies in Unity will prevent sprites in Futile from ever working well. I'll look into 2DTollkit and SpriteManager 2 though, that's the first I've heard of them. Do they bypass the game objects?

edit: having said that, can you give me more information about creating a 3D grid in Unity? The whole reason I approached unity in the first place was that I wanted to make a procedural 3D game, but I still can't figure out how to do that without creating things by hand and dragging and dropping them. Is there any sort of example code or tutorial that might be able to get me started? Everything I'm finding is pre-designed platformers or FPS games.

SlightlyMadman fucked around with this message at 22:11 on Apr 2, 2013

FuzzySlippers
Feb 6, 2009

Since I am always doing things the dumb way as part of my testing in Unity I was generating game levels that consisted of thousands of cube primitives each a separate gameobject, mesh, and one of 5 different material (all parented behind a gamelevel object at least). I never bothered to implement any mesh combining because I noticed that the number of draw calls and performance did not suffer whether the level was dozens or thousands of primitives. I was also generating at runtime even. This was on the web player and desktop so I can't say how it would run on mobile, but my understanding is that Unity is pretty smart about batching so it was already managing off screen rendering. I had trigger spheres to turn off far away gameobjects in the level but it didn't improve anything though when I implemented torches disabling off screen lights did have a major impact.

I'm not generating levels like that anymore but in my testing it seemed a completely valid way to go about things and unless I'm missing something I don't see why it would be any different using a 2D texture instead of textures wrapped around a cube as long as you were sharing materials.

In particular the variance in my performance and draw call usage from how I was creating the level was incredibly minimal compared to even the smallest usage of lighting.

Question: when people talk about not instantiating are they referring to avoiding the use of Resources.Load and using Instantiate on an already loaded object or avoiding the use of Instantiate completely?

SlightlyMadman
Jan 14, 2005

Ah cool, that's strange to me that Unity can handle thousands of textured 3D cube objects, but not thousands of image sprites, but I guess that's the nature of the engine so it makes sense.

So I know I can create c# scripts and add them as behaviors to various objects, but how would I got about creating a main script that controls the game? I'd basically want a single script that would initialize those blocks in code and add them to the game.

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!

SlightlyMadman posted:

Yeah, I'm checking out Futile, but I said the above in response to the consensus here that the game object inefficiencies in Unity will prevent sprites in Futile from ever working well. I'll look into 2DTollkit and SpriteManager 2 though, that's the first I've heard of them. Do they bypass the game objects?
Just to be clear, I'm not suggesting it would be bad for sprites in general, I'm just suggesting that I believe it would be not great to make a tilemap out of such sprites. Active sprites that are independently moving around and doing things being represented by Unity's GameObjects would absolutely make good sense. And I might be wrong about making tilemaps out of such sprites, they might be fine!

quote:

edit: having said that, can you give me more information about creating a 3D grid in Unity? The whole reason I approached unity in the first place was that I wanted to make a procedural 3D game, but I still can't figure out how to do that without creating things by hand and dragging and dropping them. Is there any sort of example code or tutorial that might be able to get me started? Everything I'm finding is pre-designed platformers or FPS games.
A very basic way to do that (and this is suffering from the same thing I'm saying I wouldn't do for a 2D grid, every block is going to be a GameObject) would be to declare a 3D array then iterate through the array creating objects from prefabs
code:
public GameObject BlockPrefab; //set from the editor
private GameObject[] blocks=new GameObject[XSIZE*YSIZE*ZSIZE];

function Start() {
  for (int z=0; z<ZSIZE; z++) {
    for (int y=0; y<YSIZE; y++) {
      for (int x=0; x<XSIZE; x++) {
        int index=z*(XSIZE*YSIZE)+y*(XSIZE)+x;
        if (GetSquareFromMap(x,y,z)==TYPE_BLOCK) {
          blocks[index]=Instantiate(BlockPrefab,Vector3(x,y,z),Quaternion.identity);
        }
      }
    }
  }
}
(Here I'm assuming the blocks are sized 1*1*1, because the position vector of the new object is not being scaled)

If you want to generate objects not from prefabs then it gets a lot more complicated.

quote:

So I know I can create c# scripts and add them as behaviors to various objects, but how would I got about creating a main script that controls the game? I'd basically want a single script that would initialize those blocks in code and add them to the game.
Generally you'd have at least one (non-physical) object in the scene that contains any scripts of that nature. In this case I'd probably go with an object named "Map" whose functions initialize only those things rather than the whole game, and which would then contain the generated objects (blocks[index].transform.parent = this;)

roomforthetuna fucked around with this message at 23:56 on Apr 2, 2013

SlightlyMadman
Jan 14, 2005

roomforthetuna posted:

Just to be clear, I'm not suggesting it would be bad for sprites in general, I'm just suggesting that I believe it would be not great to make a tilemap out of such sprites. Active sprites that are independently moving around and doing things being represented by Unity's GameObjects would absolutely make good sense. And I might be wrong about making tilemaps out of such sprites, they might be fine!

It's not just you, I was reading through the reddit Futile forum and found several posts to the same effect, with no real good answers for how to make a tiled game with a decent frame rate. I think it's just not the type of game it's designed to handle.

roomforthetuna posted:

A very basic way to do that (and this is suffering from the same thing I'm saying I wouldn't do for a 2D grid, every block is going to be a GameObject) would be to declare a 3D array then iterate through the array creating objects from prefabs

(Here I'm assuming the blocks are sized 1*1*1, because the position vector of the new object is not being scaled)

If you want to generate objects not from prefabs then it gets a lot more complicated.

This makes sense to me. So I could make one prefab cube per terrain type, and just clone them as needed?

roomforthetuna posted:

Generally you'd have at least one (non-physical) object in the scene that contains any scripts of that nature. In this case I'd probably go with an object named "Map" whose functions initialize only those things rather than the whole game, and which would then contain the generated objects (blocks[index].transform.parent = this;)

Sounds reasonable, I'll give it a shot.

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!

SlightlyMadman posted:

This makes sense to me. So I could make one prefab cube per terrain type, and just clone them as needed?
Yup. Careful if iterating over the array that you check for nulls first, assuming you're going to leave empty squares as null.

Back on the subject of tilemaps, if Unity does okay with thousands of cubes as FuzzySlippers says then I can't see why it would be struggling in 2D unless it's something Futile is doing - eg. maybe it's attaching a trivial 'Update' function to every sprite object, which stops being trivial when you have thousands of them.

Kind of surprised there's no Tilemap-specific class. Seems like a thing that belongs in any 2D game library.

Yodzilla
Apr 29, 2005

Now who looks even dumber?

Beef Witch

roomforthetuna posted:

Kind of surprised there's no Tilemap-specific class. Seems like a thing that belongs in any 2D game library.

I haven't tried it but isn't that what FTilemap is? I've used his camera class and it works well, it might be worth investigating his tilemap implementation too.

Adbot
ADBOT LOVES YOU

SlightlyMadman
Jan 14, 2005

roomforthetuna posted:

Yup. Careful if iterating over the array that you check for nulls first, assuming you're going to leave empty squares as null.

There shouldn't be any empty squares in a terrain grid, or they'd be bottomless pits. I'll probably start with water, grass, and road, although I'll need to add multiple road puzzle pieces to join them together. I'll store the buildings in a separate array, so I don't have to iterate through terrain when I want to check buildings.

SlightlyMadman fucked around with this message at 04:43 on Apr 3, 2013

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply