|
SlightlyMadman posted:It's not the fact that it's attached to a GameObject, so much as that it all has to be in a single function in a single script. I'd prefer to split things out into separate scripts by function, so I have one script for UI, one script for terrain generation, one script for AI, etc. It doesn't. You're free to build whatever giant software system you want, however you want. You essentially just need a game object somewhere to instantiate your management system during OnAwake (or whatever) to at least be notified when a new frame happens via Update (or whatever) and pass that fact along to your management system. A "blank" game object like people describe just serves as your portal into the notifications/events that unity exposes. You can just put a monolithic script in there, or use it to just call delegates on/post events to your MASTERWORKSYSTEM, or something in between. Unormal fucked around with this message at 18:01 on Apr 12, 2013 |
# ? Apr 12, 2013 17:59 |
|
|
# ? May 12, 2024 05:44 |
|
So I've got my senior project coming up for next year and decided to form an indie team rather than jumping on the large team project. We've settled on an RTS, so I was wondering if anyone has used the Fury Framework plugin for Unity. It seems impressive and has built-in networking but I wanted to know if there were any hitches I should know about or plan for before I drop 100 bucks on it.
|
# ? Apr 12, 2013 18:20 |
|
Unormal posted:It doesn't. You're free to build whatever giant software system you want, however you want. You essentially just need a game object somewhere to instantiate your management system during OnAwake (or whatever) to at least be notified when a new frame happens via Update (or whatever) and pass that fact along to your management system. A "blank" game object like people describe just serves as your portal into the notifications/events that unity exposes. You can just put a monolithic script in there, or use it to just call delegates on/post events to your MASTERWORKSYSTEM, or something in between. Right, I get that, my problem is that I'm not instantiating the Script1.cs object, so I have no idea how to access it from another script. The only way I can think of doing so is with a singleton class since I can use static methods. I thought there must be some way to have one script reference another script, but it sounds like you're all saying that most people just cram every single line of code into one update function, so I guess there's not. I was hoping there was something like "Script1 s1_instance = UnityEngine.GetInstance(Script1)" but if there's not then I'll just use a Singleton and move all of my business logic out of the gameobject scripts. edit: To be more clear, here is one very specific example: Let's say TerrainGenerator.cs has an array called "GameGrid". I have a script InputController.cs that handles mouse clicks. On a mouse click event in InputHandler, I want to reference TerrainGenerator's "GameGrid" array so I can switch a bit inside it, but I can't figure out how to access the TerrainGenerator object that Unity created from within my InputController object. The only solution I can think of is to create a "GameSingleton" class that stores the GameGrid property, so in InputController I'd just call: "GameSingleton.GetInstance().SetGameGrid(x, y, 1)" If I were using PyGame or something else code-based, I'd have created the TerrainGenerator and InputHandler objects from a parent class that handles everything. SlightlyMadman fucked around with this message at 19:10 on Apr 12, 2013 |
# ? Apr 12, 2013 19:03 |
|
SlightlyMadman posted:Right, I get that, my problem is that I'm not instantiating the Script1.cs object, so I have no idea how to access it from another script. You can split the difference and have a singleton gameobject / script which extends the normal MonoBehavior stuff so you can use the usual functionality of update() and the like. Note: This is in Haxe, but it's pretty straightforward to turn in to C#. Here's a snippet of the relevant stuff from our Dispatcher: code:
code:
|
# ? Apr 12, 2013 19:17 |
|
I also just found this: http://docs.unity3d.com/Documentation/ScriptReference/index.Accessing_Other_Game_Objects.html That should help me do the same thing as well, so I think that's enough for me to go on.
|
# ? Apr 12, 2013 19:18 |
|
You can call {scriptName}.{method} to access a method from another Unity script.
|
# ? Apr 12, 2013 21:09 |
|
SuicideSnowman posted:You can call {scriptName}.{method} to access a method from another Unity script. Huh, I'll try that tonight. Are you sure that's not just for static methods? The only way I could see that working is if Unity does some sort of preprocessing before it compiles, since that shouldn't be valid c# syntax. Either way, the link I posted above has tons of techniques for accessing other scripts or game objects, so I should be all set. I figure I'll have a single primary game script, but store most of my persistent data in a library class that has some singleton access so it can be polled directly if needed, but my miscellaneous scripts can mostly just call back to the primary game script with GetComponent() SlightlyMadman fucked around with this message at 21:51 on Apr 12, 2013 |
# ? Apr 12, 2013 21:44 |
|
My bad, I'm not positive that it works with methods but it does work with variables (as long as the variable is public).
|
# ? Apr 12, 2013 21:49 |
|
SuicideSnowman posted:My bad, I'm not positive that it works with methods but it does work with variables (as long as the variable is public). Hmm, if it's standard c# code it shouldn't unless the variable is also static. Maybe it's a javascript only thing?
|
# ? Apr 12, 2013 21:52 |
|
You'll need to cache the script before you can call it. so say you have a class called Wind on an object named WindObject. if you just want the script, then in the script you want to be able to access from: code:
Edit: And you'll need to set windObject in the editor for this method, you can also use GameObject.Find to get it as well. Edit2: You can also just set the script in the editor too: code:
Bondematt fucked around with this message at 22:03 on Apr 12, 2013 |
# ? Apr 12, 2013 21:57 |
|
Torch Dexter posted:Obviously the draw order isn't working quite as expected - in my experience with unity (using my own Sprite implementation, not 2D toolkit), in order to get sprites to always draw in the correct order you should be drawing sprites using a shader that has ZWrite turned on. This looks like the results you get when you try and draw close together sprites with a shader that has ZWrites turned off (as most of the standard unity shaders do). As your floor is solid - if you set that to work with a shader without transparency that might fix the issue as well - I've only ever seen it occur where two semitransparent objects overlap. This draws transparency over the floor making it so the "blue space" of the background draws where the player should be transparent. Anyway I messed around with splitting up the atlases and using different render queues and that seems to have fixed it.
|
# ? Apr 12, 2013 22:02 |
|
Bondematt posted:You'll need to cache the script before you can call it. Yeah, the link I posted above is very useful. There's apparently all sorts of different ways of doing it.
|
# ? Apr 12, 2013 22:05 |
|
SlightlyMadman posted:Yeah, the link I posted above is very useful. There's apparently all sorts of different ways of doing it. I typically attach all my non-object specific game scripts to the main camera instead of an empty, just because that camera is typically always in your scene by default anyways, and has a handy shortcut reference. I then do stuff like the following from any prefab objects that need to access the global scripts: code:
Azazel fucked around with this message at 14:59 on Apr 13, 2013 |
# ? Apr 13, 2013 14:44 |
|
If some of your scripts have order dependencies this is really useful: http://docs.unity3d.com/Documentation/Components/class-ScriptExecution.html I usually only go manual update methods if it's for performance reasons or if I need one script to be updated in the middle of another.
|
# ? Apr 13, 2013 15:04 |
|
Shalinor posted:Render #1 and #2 to an off-screen buffer. #1 is the base layer, write / no z / no alpha. #2 is blended over the top of that additively. Then take the composite buffer and render it over the regular scene buffer multiplicatively. Make sure that the composite buffer is double-buffered - which would lag your lighting a single frame, but keep you from trashing perf with a dependent render. seiken posted:You probably don't need Layer 2 either depending on what you're doing. Unless your light sprite is really complicated you can probably do this without needing to render to an intermediate 'light' texture. Just calculate the value directly in the shader and multiply. If your light sprite is really complicated such that you actually need multiple passes to render it then you can use an off-screen texture, I guess. Jewel posted:Oh yeah what the heck you don't need to render a black rectangle on top with alpha cutout, I'm being an idiot. Apply a postprocess shader to the render target with this and that's basically it. Anyway, I have it working. I ended up using a 'light' texture because it seemed like a cleaner implementation to me and it allows me to do goofy arbitrary shaped lights without worrying about writing the math in the shader. I wanted to make sure what I was doing wasn't completely backwards, so can you folks take a look at my steps and make sure I'm not wasting time or doing anything silly? This is DX9. 1. In setup, create a Texture ('lightTexture') of the same size as my normal backbuffer, with the Usage.RenderTarget flag set. 2. Pass this texture reference into a shader, 'std.fx' 3. For each frame... 4. Set the device render target to the texture surface. 5. Clear the device to the ambient light color (this could also be done as a constant in the pixel shader, but whatever) 6. Device.BeginScene() 7. Render all light sprites using an shader 'lights.fx', which is a simple pass-through filter. 8. Device.EndScene() 9. Set the device render target to the original backbuffer 10. Clear device to whatever color 11. Device.BeginScene() 12. Render all non-light sprites using another shader, 'std.fx', which multiplies pixels by sampling the variable set in step #2 (lightTexture). 13. Device.EndScene() and Present(). Is there a simpler way to do this? (Not complaining, as this is actually pretty simple) It works perfectly, just wanted to check before making it un-hacky code. Additional question: Let's say I want a HUD layer that's on top of all of this and doesn't care about lights. Would I implement that with a third render target?
|
# ? Apr 13, 2013 16:46 |
|
Orzo posted:Is there a simpler way to do this? (Not complaining, as this is actually pretty simple) It works perfectly, just wanted to check before making it un-hacky code. Additional question: Let's say I want a HUD layer that's on top of all of this and doesn't care about lights. Would I implement that with a third render target?
|
# ? Apr 13, 2013 17:09 |
|
I don't use z-buffering, I draw layers in order. But the HUD layer would be drawn last, so yeah, what about just switching to another shader that ignores lighting and then rendering?
|
# ? Apr 13, 2013 17:20 |
|
Orzo posted:I don't use z-buffering, I draw layers in order. But the HUD layer would be drawn last, so yeah, what about just switching to another shader that ignores lighting and then rendering? Definitely better than doing an extra off-screen render target. What would you gain from doing that? You'd still have to change all the parameters for that off-screen render, then you'd just end up rendering it again onto the main screen, now with a bonus big lump of VRAM in use for no reason. (Again, unless your HUD is going to be mostly static and only re-render when something changes, in which case it might make some sense to be able to just render it in one call onto the screen. Though even then you'd still need to turn off all the fancy shaders and stuff.)
|
# ? Apr 13, 2013 17:47 |
|
Thanks. One more quick question: I am noticing a fairly dramatic drop in performance if I have a lot of overlapping lights (which are in additive blend mode) rendered to the lights target texture. Before I spend too long getting into this, is there some kind of common error people make when doing this stuff? The problem definitely scales with the number of lights, and additionally with how much they overlap. It seems like the number shouldn't matter really (beyond typical overhead of adding more sprites, which is very small, this starts dominating the graphics card at ~10 overlapping lights) since I'm still only doing two passes no matter what. Edit: This might be a non-issue, turned on DirectX debug mode (I have to get into the habit of doing this more frequently) and I'm getting all sorts of warnings, gotta solve those first... Orzo fucked around with this message at 01:26 on Apr 14, 2013 |
# ? Apr 14, 2013 00:40 |
|
Yes, it definitely sounds like something is wrong. You're not really doing any extra work compared to one light, and rendering 10 alpha-blended sprites shouldn't kill your graphics card. The fact that overlapping makes it worse is kind of weird, too. I can't think of an immediate explanation. I don't know DirectX, but I know OpenGL has hint parameters when you create a texture to indicate how often you're going to modify the texture. If DirectX has something similar it could be you've told it "I'm never going to write to this" so it's stored it somewhere where writes are terribly inefficient.
|
# ? Apr 14, 2013 01:29 |
|
seiken posted:I don't know DirectX, but I know OpenGL has hint parameters when you create a texture to indicate how often you're going to modify the texture. If DirectX has something similar it could be you've told it "I'm never going to write to this" so it's stored it somewhere where writes are terribly inefficient. So, like: Render Light A To Light Texture Render Scene With Light Texture Render Light B To Light Texture Render Scene With Light Texture Render Light C To Light Texture Render Scene With Light Texture Render Light D To Light Texture Render Scene With Light Texture Will be MASSIVELY slower than: Render Light A To Light Texture Render Light B To Light Texture Render Light C To Light Texture Render Light D To Light Texture Render Scene With Light Texture Render Scene With Light Texture Render Scene With Light Texture Render Scene With Light Texture Even worse if you're doing something like: Render Light A To Intermediate Light Texture Render Intermediate Light Texture To Light Texture Render Scene With Light Texture Render Light B To Intermediate Light Texture Render Intermediate Light Texture To Light Texture Render Scene With Light Texture Note that you don't even have to do a full "Render Scene With Light Texture". If you're, for instance. locking the Light Texture? God help you. (my guess is that you're doing something like the above, and blowing cache... which will destroy perf super, super fast)
|
# ? Apr 14, 2013 02:08 |
|
Thanks for the help everyone. Pretty sure I sorted out my issues, I turned on more verbose warnings for DirectX and sorted them out, something about clearing the device's cached textures before writing to the light texture again. Here's a video of the results. Not the prettiest lights in the world yet, but I should be able to do some cool stuff with them once I'm making something besides a tech demo. https://www.youtube.com/watch?v=BXgs22SCXXk&hd=1
|
# ? Apr 15, 2013 01:34 |
|
Just out of curiosity, and I was only thinking this because I was playing Anodyne yesterday, what is the math behind jumping in a Zelda-esque game?
|
# ? Apr 15, 2013 01:38 |
|
Yodzilla posted:Just out of curiosity, and I was only thinking this because I was playing Anodyne yesterday, what is the math behind jumping in a Zelda-esque game? If you mean Link's Awakening where you can free jump, free jumps don't change your map elevation, they just prevent you from falling into pits while in the air.
|
# ? Apr 15, 2013 02:08 |
|
Yodzilla posted:Just out of curiosity, and I was only thinking this because I was playing Anodyne yesterday, what is the math behind jumping in a Zelda-esque game? Right, I haven't done the 'jumping off ledges' thing yet like OneEightHundred said, although I'm going to get to that eventually. The jump is implemented visually as a y-offset, nothing more. The 'Player' entity is decomposed into several child entities, for example the 'body' (which would also have accessories, etc--basically anything that jumps) and the shadow (which is not affected by jumping). My engine has a sort of state-machine implementation for entities. The code relevant to jumping is this: code:
code:
Collision is simple. If you check out this old post and the related video, you'll see how I can use collision categories to control behavior. I add a collision category 'air' when the jump begins (code for the Standard state removes it). Then, in enemy code, collision with the player is configured such that 'hoppable' enemies like the 'spike' can be set up like this: code:
|
# ? Apr 15, 2013 02:35 |
|
Ha! Yeah that's about what I was thinking, I didn't know if it was any more complex than that. Thanks for the clarification.
|
# ? Apr 15, 2013 02:40 |
|
Orzo posted:1. In setup, create a Texture ('lightTexture') of the same size as my normal backbuffer, with the Usage.RenderTarget flag set. For future reference, you don't have to use EndScene/BeginScene between render targets. In fact the documentation suggests that it may cause a performance hit. Just use them once per frame.
|
# ? Apr 15, 2013 10:26 |
|
Rottbott posted:For future reference, you don't have to use EndScene/BeginScene between render targets. In fact the documentation suggests that it may cause a performance hit. Just use them once per frame.
|
# ? Apr 15, 2013 14:36 |
|
For any of you interested the recently Kickstarted 2D skeletal animation tool Spine released their Unity and generic C# runtimes today. I'm not entirely sure how to use it and if it's possibly to integrate into Futile but I'm drat sure going to try.
|
# ? Apr 15, 2013 14:41 |
|
Hey QBasic guy - saw you featured on Gamasutra (saw QBasic in the headline and immediately knew what game it was.) Congrats on the exposure, game is looking great.
|
# ? Apr 15, 2013 19:57 |
|
I dunno a whole lot about various languages really, is there a specific reason nobody writes games in QBasic? Is it just that it's a fairly old language that hasn't really kept up with the times or something?
|
# ? Apr 15, 2013 20:45 |
The OP hasn't been updated since 2007, what would I want to go get to mess around and try to put together a game in?
|
|
# ? Apr 15, 2013 20:48 |
|
Zereth posted:The OP hasn't been updated since 2007, what would I want to go get to mess around and try to put together a game in?
|
# ? Apr 15, 2013 21:30 |
Oh hey yes that information would be necessary, wouldn't it. Desktop, not much, and uh. Probably some sort of turn-based RPG type thing to start with but I'd like to branch out into other things later.
|
|
# ? Apr 15, 2013 21:39 |
|
Surprise T Rex posted:I dunno a whole lot about various languages really, is there a specific reason nobody writes games in QBasic? Is it just that it's a fairly old language that hasn't really kept up with the times or something? OneEightHundred fucked around with this message at 21:45 on Apr 15, 2013 |
# ? Apr 15, 2013 21:41 |
|
Yodzilla posted:For any of you interested the recently Kickstarted 2D skeletal animation tool Spine released their Unity and generic C# runtimes today. I'm not entirely sure how to use it and if it's possibly to integrate into Futile but I'm drat sure going to try. The Kickstarter specifically says it will work with Futile and 2D Toolkit.
|
# ? Apr 15, 2013 22:07 |
|
Zereth posted:Oh hey yes that information would be necessary, wouldn't it. In 2D, I would go for Flixel or FlashPunk (Flash game dev libraries). Really easy language to pick up, and you can get something on screen quickly (which I find is very important for keeping motivation up if you don't really know what you're doing). In 3D, Unity is far easier than anything else you're likely to find. You can put a simple game together with very minimal programming, and go from there.
|
# ? Apr 15, 2013 23:08 |
|
Suran37 posted:The Kickstarter specifically says it will work with Futile and 2D Toolkit. It'll worth with it but there will have to be work done on Futile's part which is more what I meant. From Futile's creator on the release: quote:Yes! This is definitely something I want to integrate. I'm not exactly sure how much work it'll take to turn that generic runtime into something Futile can use, but I don't think it'll be that bad.
|
# ? Apr 15, 2013 23:15 |
|
Yodzilla posted:worth with it but there will have to be work done on Futile's part which is more what I meant. From Futile's creator on the release: Oh I misunderstood you. I'm excited to try it out, but it crashes on launch for me at the moment.
|
# ? Apr 16, 2013 00:43 |
|
|
# ? May 12, 2024 05:44 |
|
I have always wanted to make a game, and I believe I am ready to start, but I don't know which technologies will make my life easier. I want to start with a Worms-like clone, with multiplayer. I am decent at C++, but I am willing to learn other languages in necessary. However, I would prefer a Linux release in addition to the PC. Can you guys point me to libraries, frameworks which would make my life easier? I would prefer not to start from scratch, as I will get delayed by at least a year.
|
# ? Apr 16, 2013 01:03 |