I usually prefer to have my methods organized into sort of "verbs", like MoveForward(). Hooks like Update() can call them, but generally I isolate things as much as possible.
I absolutely agree, that's not your PHP background that's just general best practice.
I was going for more "one step at a time."
The point is you want the movement code in the objects themselves, and if another object is going to do something, it's going to be changing parameters on them. If you absolutely must have a separate object call a moveForward() method, by putting it in a separate script you can say:
You can add instances of the MoveForwardable component to that list no matter what other components the game object has, which means your 20 different objects can all be in one list and can easily be accessed by their capability instead of their specific reference or name.
Incidentally, does anyone know what the idiomatic methods are for compartmentalize inputs in Unity? E.g. cut off inputs to the character and redirect them to a menu.
My current approach is a state machine. What I'd like is for 1) the Update() on my state machine to call 2) Update() on the activate state(s), which then 3) gets the inputs to the components that need them. This way, I get the double benefit of deactivating a state cutting it off from both inputs as well as Update()s.
Currently I use a simple, hand rolled version of the new unity ControlScheme input system which was linked earlier in the thread. Looks like you basically are too.
I also separate my controls into an object so that logic is never directly mapped to inputs, logic instead polls to see if a particular type of input has been entered.
Currently I use a simple, hand rolled version of the new unity ControlScheme input system which was linked earlier in the thread. Looks like you basically are too.
I also separate my controls into an object so that logic is never directly mapped to inputs, logic instead polls to see if a particular type of input has been entered.
Yeah, I've got separate MovableCharacter and CharacterController components, so that's sorted. But what I'm getting at is what you do to compartmentalize input during different modes or "phases" of gameplay. For example, when you pause, how do you keep menu inputs from affecting the game?
2 week left before our friends and family alpha and we're still waiting on the debit card for the LLC account which we need for amazon web services, the new player experience/tutorial is full of placeholder text and I kept discovering areas of our game that weren't 100% finished because we planned to come back later and then forgot all about it, and my main partner is going to be starting a new job and will have little time if any to contribute anymore.
That's something I'm debating on: a tutorial. I know I should have one, it's just an annoying thing to actually build. It would be easier to just make a series of videos of me playing and explaining things but some people might hate that. However the priority is just finishing the damned thing because I've been working on this for like 3 years.
Steam Profile | My Art | NID: DarkMecha (SW-4787-9571-8977) | PSN: DarkMecha
0
KoopahTroopahThe koopas, the troopas.Philadelphia, PARegistered Userregular
That's something I'm debating on: a tutorial. I know I should have one, it's just an annoying thing to actually build. It would be easier to just make a series of videos of me playing and explaining things but some people might hate that. However the priority is just finishing the damned thing because I've been working on this for like 3 years.
Finish game first, make tutorial after you're finished but before launching.
That's something I'm debating on: a tutorial. I know I should have one, it's just an annoying thing to actually build. It would be easier to just make a series of videos of me playing and explaining things but some people might hate that. However the priority is just finishing the damned thing because I've been working on this for like 3 years.
Finish game first, make tutorial after you're finished but before launching.
Yeah good point. No sense in making a tutorial for a game that isn't done hah.
Steam Profile | My Art | NID: DarkMecha (SW-4787-9571-8977) | PSN: DarkMecha
Currently I use a simple, hand rolled version of the new unity ControlScheme input system which was linked earlier in the thread. Looks like you basically are too.
I also separate my controls into an object so that logic is never directly mapped to inputs, logic instead polls to see if a particular type of input has been entered.
Yeah, I've got separate MovableCharacter and CharacterController components, so that's sorted. But what I'm getting at is what you do to compartmentalize input during different modes or "phases" of gameplay. For example, when you pause, how do you keep menu inputs from affecting the game?
I use a state machine where each state's update sends input to where it needs to go for that state. For example, the MainMenuState sends input to my main menu UI controller, and the GameState sends input to the player controller, etc.
I usually prefer to have my methods organized into sort of "verbs", like MoveForward(). Hooks like Update() can call them, but generally I isolate things as much as possible.
I absolutely agree, that's not your PHP background that's just general best practice.
I was going for more "one step at a time."
The point is you want the movement code in the objects themselves, and if another object is going to do something, it's going to be changing parameters on them. If you absolutely must have a separate object call a moveForward() method, by putting it in a separate script you can say:
You can add instances of the MoveForwardable component to that list no matter what other components the game object has, which means your 20 different objects can all be in one list and can easily be accessed by their capability instead of their specific reference or name.
Well, some background on my odd choices; first of all this is an endless runner; the gameobjects (islands) are therefore always moving, in void update(), towards the player at a specific rate but will regularly move sidewards (when reset beyond the horizon. Since everything happens on a sphere Quaternion.eulerAngles are in play! hurrah!)
The player interacts with the islands with collision boxes that have scripts attached. Two trigger crashes (well actually a penalized roll to left or right), one picks up credits, or fuel, or...
Well, this is actually the simple version. What I do is I have nodes at the center of the sphere that rotate, onto which islands are instantiated, onto which pickups are instantiated. And the player pickupchecker script determines where those pickups will be dropped of, which means there's a list for each island specifying future instantiated pickups, etc. etc.
However now I'm putting in opponents, and I decided (this is a gut move) to actually have the opponents check the coordinates of the game objects rather than have a pile of collision boxes flying around.
However, if everything moves during update in separate but parallel scripts, I'm not sure if the correct positions are available to the opponents when they execute their update. There's some debate about lateupdate timing in Unity, and aint nobody got time for that.
So if I put everything into one script, I can call the functions during one long update, with order and resulting variables easily determined. First my islands, then the opponents, then we check for collisions and work out the results.
A bonus for doing it this way is that I can have AI for my opponents rather than cleverly set up collision boxes...
It also makes it easier for me to track what function is happening where. I've been flummoxed several times by scripts that didn't have public gameobjects or text fields defined; Unity then just drops what it's doing and starts the next function.
But in general there's some other things I've been doing, such as making my planes come together from 9 separate objects that have very identical methods/functions to get them to/from a save game, instantiate them, check if they are already bought or not, set prices, buy, etc. etc.
All of which makes for a long list of functions like buy_wings(), buy_engine(), buy_fuselage(), buy_empennage() etc. Where only the words wings, engine, fuselage, etc. differ! 3000 lines of code that make me want to pick up something as exiting and varied as, oh say, trainspotting as a hobby. I KNEW there had to be something less verbose out there.
So that's basically why I want to reuse methods/functions (I'm confused. what are they named?). Something like for each item in list do item.do. Or, what Rend said. I'm definitely going to look into that! But probably in a test scene.
I usually prefer to have my methods organized into sort of "verbs", like MoveForward(). Hooks like Update() can call them, but generally I isolate things as much as possible.
I absolutely agree, that's not your PHP background that's just general best practice.
I was going for more "one step at a time."
The point is you want the movement code in the objects themselves, and if another object is going to do something, it's going to be changing parameters on them. If you absolutely must have a separate object call a moveForward() method, by putting it in a separate script you can say:
You can add instances of the MoveForwardable component to that list no matter what other components the game object has, which means your 20 different objects can all be in one list and can easily be accessed by their capability instead of their specific reference or name.
Well, some background on my odd choices; first of all this is an endless runner; the gameobjects (islands) are therefore always moving towards the player at a specific rate but will regularly move sidewards. (Since everything happens on a sphere Quaternion.eulerAngles are in play! hurrah!)
The player interacts with them with collision boxes that have scripts attached. Two trigger crashes (well actually a penalized roll to left or right), one picks up credits, or fuel, or...
However now I'm putting in opponents, and I decided (this is a gut move) to actually have the opponents check the coordinates of the game objects rather than have a pile of collision boxes flying around.
However, if everything moves during update in parallel scripts, I'm not sure if the correct positions are available to the opponents. There's some debate about lateupdate timing in Unity, and aint nobody got time for that.
So if I put everything into one script, I can call the functions during one long update, with order and resulting variables easily determined. First my islands, then the opponents, then we check for collisions and work out the results. A bonus is that I can have AI for my opponents rather than cleverly set up collission boxes...
It also makes it easier for me to track what function is happening where. I've been flummoxed several times by scripts that didn't have public gameobjects or text fields defined; Unity then just drops what it's doing and starts the next function.
But in general there's some other things I've been doing, such as making my planes come together from 9 separate objects that have very identical methods/functions to get them to/from a save game, instantiate them, check if they are already bought or not, set prices, buy, etc. etc.
All of which makes for a long list of functions like buy_wings(), buy_engine(), buy_fuselage(), buy_empennage() etc. Where only the words wings, engine, fuselage, etc. differ! 3000 lines of code that make me want to pick up something as exiting and varied as, oh say, trainspotting as a hobby. I KNEW there had to be something less verbose out there.
So that's basically why I want to reuse methods/functions (I'm confused. what are they named?). Something like for each item in list do item.do. Or, what Rend said. I'm definitely going to look into that! But probably in a test scene.
Code blocks are named different things depending on context. A function has a signature, a return type, and 0-many parameters. If it's attached to a class, it's called a method. In C#, you generally deal with methods.
For your buying functions, I would try `public void buy_upgrade(int upgradeID)` or `buy_upgrade(Upgrade selectedUpgrade`.
Refactoring things to be more generic is a big part of learning how to think like a programmer. Honestly, the fact that you're getting code down is more important than it being academically perfect, but I would be happy to talk refactoring and data structures all day.
For your situation, I'd honestly just try Unity as intended first. There are definitely edge cases in which you need to re-invent a few things in your own code, but Unity has way more structure and collective community testing than anything we could write on our own.
If you find that it really doesn't work for you, try using a generic List as Rend suggested above. If you declare it public, the inspector will even tell you what it contains.
I've historically gone with a stack for input control, but one thing to think about is that sometimes you might want multiple components to receive input at the same time. In my case, the player can move the camera around while a menu is visible.
Currently I use a simple, hand rolled version of the new unity ControlScheme input system which was linked earlier in the thread. Looks like you basically are too.
I also separate my controls into an object so that logic is never directly mapped to inputs, logic instead polls to see if a particular type of input has been entered.
Yeah, I've got separate MovableCharacter and CharacterController components, so that's sorted. But what I'm getting at is what you do to compartmentalize input during different modes or "phases" of gameplay. For example, when you pause, how do you keep menu inputs from affecting the game?
I use a state machine where each state's update sends input to where it needs to go for that state. For example, the MainMenuState sends input to my main menu UI controller, and the GameState sends input to the player controller, etc.
Ah, so you've already gone over this part!
What do you send to the controller scripts? Do you package input into a data payload, or do you just call the methods in those controller scripts? I'm trying to genericize my input buffer manager.
How do you handle updates in your state machine? With everything in Unity being an object with components, I can't just package them up into states like I would in other frameworks. How do you e.g. prevent enemies from moving during a pause menu?
While we're at it, if every object is constantly moving towards the player, and they're moving at assumedly the same rate, wouldn't it be easier to, uh, move the player? The objects can still move, but it seems easier to track where things are if they generally aren't the thing that's moving too much.
Also, yes, instead of buy_wings() I would definitely suggest buy_item(Item item).
However, if everything moves during update in separate but parallel scripts, I'm not sure if the correct positions are available to the opponents when they execute their update.
You can set the execution order of scripts in unity to ensure the scenery elements go before the ai elements.
Your instinct about writing less code is correct. But typically it's a better idea to spread code out than it is to centralize it.
Question. why do you want to avoid a pile of collision boxes?
So it's going well, but sometimes I definitely feel like an outsider in a specialized field. Which... I am. But wow. I've run across a couple neat tricks that I assume most people wouldn't think up themselves.
For example, to loop through a two-dimensional array back to the beginning, you can loop through this expression:
And people also do this clever thing to get correct horizontal and vertical movement in two lines:
(use input to set true/false on the variables up/down/left/right)
x +=(right - left) * speed;
y +=(down - up) * speed;
I have no ability to conceptualize how the first example works (although I ran through some different hypos just to verify that, yeah, it really always works like that), and, although I can understand the second example, it's a little mind blowing because it combines two different concepts (using the arbitrary computer values for true and false to do math that just happens to work out). The same thing with using bitwise operators to store and compare a bunch of true/false flags rather than using them to do math.
Hopefully I'll just luck across all these kinds of things that I need to know or figure out good-enough alternatives to the rest.
Currently I use a simple, hand rolled version of the new unity ControlScheme input system which was linked earlier in the thread. Looks like you basically are too.
I also separate my controls into an object so that logic is never directly mapped to inputs, logic instead polls to see if a particular type of input has been entered.
Yeah, I've got separate MovableCharacter and CharacterController components, so that's sorted. But what I'm getting at is what you do to compartmentalize input during different modes or "phases" of gameplay. For example, when you pause, how do you keep menu inputs from affecting the game?
I use a state machine where each state's update sends input to where it needs to go for that state. For example, the MainMenuState sends input to my main menu UI controller, and the GameState sends input to the player controller, etc.
Ah, so you've already gone over this part!
What do you send to the controller scripts? Do you package input into a data payload, or do you just call the methods in those controller scripts? I'm trying to genericize my input buffer manager.
How do you handle updates in your state machine? With everything in Unity being an object with components, I can't just package them up into states like I would in other frameworks. How do you e.g. prevent enemies from moving during a pause menu?
Thanks!
I guess I worded it kind of poorly, I'm not really sending anything from the state other then an update call. Instead, my characters have their own state machine which queries my input handler during it's Update, but the character's state machine's Update is called by my GameState. So it only asks for input when it updates, and it only updates while in the GameState. This isn't ideal for some things, like exiting the game, so I cheat a little and have some input's outside of the player character's state machine that are queried during Unity's update. This implementation probably isn't great if you want to do something like what Delzhand mentioned, where some subset of inputs work in multiple states but others don't, you could probably work around it but it might get messy.
Like I just mentioned, my state machine has an UpdateState function that calls the current State's Update. I have my upper most state machine, that has my MainMenuState and GameState, which belongs to a game manager type component. The game manager calls the main state machine's UpdateState during Unity's update, GameState.Update then calls UpdateState on the player's character and on the enemies' state machine. But MainMenuState.Update does not call those updates, so if you're in the menu or paused or whatever the AI and player just don't update at all. It's probably worth mentioning that I'm not even close to polishing yet, so animations will still play/loop even when paused and I haven't really thought of how I'll handle that yet.
Question. why do you want to avoid a pile of collision boxes?
Well, gut feeling.
I could fly a series of colission boxes in front of my opponents to have them steer towards islands. Or I could just use one box that gets the position of any island it encountered. Or I could just get those positions from a list (or set of variables).
Likewise for opponents not crashing into eachother, etc.
To me it just makes more sense to have one script that keeps track of where everything is, than to set of stuff and have it interact in the Unity world.
But also it makes it easier for me to keep track of how things are interacting, and figure out how to debug/improve that interaction.
I don't have twenty million bullets flying around with their trajectories being handled by the engine, because that I wouldn't try to centralize...
Start with a kinematic floor say a scale 100, 1, 100 cube with a collider but no rigidbody. Use normal gravity.
Create a stack of unit cubes with rigidbody and box collider and a phyiscs material that has no bounce and maximum friction. The cubes can't be sleeping when the scene starts.
Question 1: how do you position the cube stack so that there is no visible movement when the scene starts
Question 2: how high can you stack the cubes before they vibrate off of each other
In my experiments there is no initial position that prevents movements when the scene first starts. And the maximum stack that doesn't fall over is about 10 assuming the mass is 1 and gravity is default.
Start with a kinematic floor say a scale 100, 1, 100 cube with a collider but no rigidbody. Use normal gravity.
Create a stack of unit cubes with rigidbody and box collider and a phyiscs material that has no bounce and maximum friction. The cubes can't be sleeping when the scene starts.
Question 1: how do you position the cube stack so that there is no visible movement when the scene starts
Question 2: how high can you stack the cubes before they vibrate off of each other
In my experiments there is no initial position that prevents movements when the scene first starts. And the maximum stack that doesn't fall over is about 10 assuming the mass is 1 and gravity is default.
#1: I'm not sure that you can. Maybe add a loading screen and then wait until all the blocks rigidbody.IsSleeping.
#1&2: In Project Settings>Physics enable "Adaptive Force." From the manual:
The “adaptive force” affects the way forces are transmitted through a pile or stack of objects with the aim of giving more realistic behaviour. This option enables or disables the adaptive force. Note that from Unity 5.0, this is disabled by default.
And then play with increasing Solver Iteration Count and Sleep Threshold.
-writing a proper raycast controller
-figuring out delegates/event systems etc
- proper state handling
- i wrote a first person controller
- a little ballistic solver for grenades
- etc
I applied smooth low frequency 3d voronoi noise with an extra higher frequency 3d noise disturbance to a volumetric material.
In other news, this weekend I installed the SSD I got from the spring jam and all I have to say is I should have put in an SSD a long time ago. The difference is huge.
I applied smooth low frequency 3d voronoi noise with an extra higher frequency 3d noise disturbance to a volumetric material.
In other news, this weekend I installed the SSD I got from the spring jam and all I have to say is I should have put in an SSD a long time ago. The difference is huge.
You haven't been using an SSD? :bigfrown:
It was the biggest upgrade I've ever made. I can hardly stand HDD PCs anymore!
I applied smooth low frequency 3d voronoi noise with an extra higher frequency 3d noise disturbance to a volumetric material.
In other news, this weekend I installed the SSD I got from the spring jam and all I have to say is I should have put in an SSD a long time ago. The difference is huge.
You haven't been using an SSD? :bigfrown:
It was the biggest upgrade I've ever made. I can hardly stand HDD PCs anymore!
No when I built my last computer I put in a GTX1070 and decided that I was spending enough on this machine and that I could add an SSD later so I was still using HDD and swearing at how much IO is hurting performance.
The input manager in Unity could use some work. It's where you map inputs to axes, but look at this:
You might expect to be able to use wasd, the arrow keys, or the joystick's 6th axis.
Nope. The "Type" field, 3/4 of the way to the bottom, is set to Joystick Axis. So the keys don't work. It's not broken, but it is awful UX. The type field should be first, and the button fields shouldn't even appear unless type is set to Key/Mouse Button.
Runevision (long time unity3d forumer, now working on the input team) hasn't laid out a timeline, but even using the unfinished system is a huge upgrade. It handles multiple controllers beautifully, mappings are stored in serialized ScriptableObject assets, and you can separate them into multiple control schemes for different modes (e.g. vehicle, on foot, etc).
They've warned that it may change drastically by its official release, but I've found it entirely worth it to integrate now.
Well, the new Unity update completely broke my action maps, meaning my current build is unplayable on 5.6. So, fuck my advice / hold off for now.
I made the mistake of purchasing Shin Megami Tensei IV as a weekend road-trip game, and wound up spending the last two weeks more or less exclusively employed in reaching the end of it. On the plus side, that, plus remembering that Cosmic Star Heroine exists, plus having the idea kicking around in my head for a game with a completely ridiculous elemental damage chart, plus also having a vague concept for the core of an RPG battle engine also knocking around there, has converged into spending about ten to fifteen hours this week (I lost track due to the code trance) knocking together what will be my third or fourth JRPG battle engine. Maybe I'll actually add graphics to this one once I'm done!
In any event, here's the central premise: all the abilities your characters can use are assigned to either Rock, Scissors, or Paper, and the moves interact with each other in the relationship those describe. Scissors moves consist of anything that causes direct damage. Rock moves comprise all those that redirect, weaken, and counter-attack against direct damage. Paper moves are the entire universe of abilities that don't cause direct damage, like DoTs, healing, and other status moves. The turn order is determined by whether an ability is Rock, Scissors, or Paper; Rock moves always go first and distribute their reaction effects, Scissors moves go after that and cause their damage (potentially triggering a reaction from the previous Rock move's effects), and Paper moves go last-- but fail if the user took any damage as a result of a Scissors move. So Rock beats Scissors because it retaliates with stronger counter-attacks, Scissors beats Paper because it makes Paper lose its turn, and Paper beats Rock because Rock doesn't react to indirect attacks.
There's more to it than that, but I think the nuances follow naturally from the premise and don't necessitate typing them all out.
What I will say is that this setup provides an easy way to make an intelligent-seeming AI opponent-- all it has to do is watch the history of what moves you selected and pick an appropriate counter-move from what the characters it controls can use. Your healer consistently throws Paper moves, so the AI knows to use a Scissors move on them, without needing to know much more than that. And the player can then know that their healer is building up some aggro over multiple turns, have them use a Rock move, and feel like they outsmarted the computer.
Of course, the pareto optimal strategy for Rock-Paper-Scissors is complete randomness in your decisions, so maybe it can't seem too intelligent in the long run. But that'll come out in play-testing, which I'm getting close to hitting. I'll let you know how it turns out next week.
My favorite musical instrument is the air-raid siren.
I have no idea how FFT implemented line-of-sight without a dedicated collision system or floating point math.
Just to be clear, is that because arrows seem to have an actual physical arc? If so, I can't help with that.
Otherwise, my first instinct was to adapt Bresenham's line algorithm to three dimensions. You get the line of "pixels" (actually in-game tiles) from attacker to target, and if any of them read as "blocked", line-of-sight fails. It may not be a perfectly accurate simulacrum of FFT's physics, but whether that matters depends on whether you're aiming for absolutely 100% parity with FFT.
My favorite musical instrument is the air-raid siren.
Posts
I absolutely agree, that's not your PHP background that's just general best practice.
I was going for more "one step at a time."
The point is you want the movement code in the objects themselves, and if another object is going to do something, it's going to be changing parameters on them. If you absolutely must have a separate object call a moveForward() method, by putting it in a separate script you can say:
List<MoveForwardable> moveForwardables; void Update(){ foreach(MoveForwardable moveForwardable in moveForwardables){ moveForwardable.moveForward(); } }You can add instances of the MoveForwardable component to that list no matter what other components the game object has, which means your 20 different objects can all be in one list and can easily be accessed by their capability instead of their specific reference or name.
My current approach is a state machine. What I'd like is for 1) the Update() on my state machine to call 2) Update() on the activate state(s), which then 3) gets the inputs to the components that need them. This way, I get the double benefit of deactivating a state cutting it off from both inputs as well as Update()s.
Is this too much? Have I missed a simpler way?
I also separate my controls into an object so that logic is never directly mapped to inputs, logic instead polls to see if a particular type of input has been entered.
Yeah, I've got separate MovableCharacter and CharacterController components, so that's sorted. But what I'm getting at is what you do to compartmentalize input during different modes or "phases" of gameplay. For example, when you pause, how do you keep menu inputs from affecting the game?
*screams incoherently*
Ok I feel slightly better now.
Finish game first, make tutorial after you're finished but before launching.
Yeah good point. No sense in making a tutorial for a game that isn't done hah.
I use a state machine where each state's update sends input to where it needs to go for that state. For example, the MainMenuState sends input to my main menu UI controller, and the GameState sends input to the player controller, etc.
Well, some background on my odd choices; first of all this is an endless runner; the gameobjects (islands) are therefore always moving, in void update(), towards the player at a specific rate but will regularly move sidewards (when reset beyond the horizon. Since everything happens on a sphere Quaternion.eulerAngles are in play! hurrah!)
The player interacts with the islands with collision boxes that have scripts attached. Two trigger crashes (well actually a penalized roll to left or right), one picks up credits, or fuel, or...
However, if everything moves during update in separate but parallel scripts, I'm not sure if the correct positions are available to the opponents when they execute their update. There's some debate about lateupdate timing in Unity, and aint nobody got time for that.
So if I put everything into one script, I can call the functions during one long update, with order and resulting variables easily determined. First my islands, then the opponents, then we check for collisions and work out the results.
A bonus for doing it this way is that I can have AI for my opponents rather than cleverly set up collision boxes...
But in general there's some other things I've been doing, such as making my planes come together from 9 separate objects that have very identical methods/functions to get them to/from a save game, instantiate them, check if they are already bought or not, set prices, buy, etc. etc.
All of which makes for a long list of functions like buy_wings(), buy_engine(), buy_fuselage(), buy_empennage() etc. Where only the words wings, engine, fuselage, etc. differ! 3000 lines of code that make me want to pick up something as exiting and varied as, oh say, trainspotting as a hobby. I KNEW there had to be something less verbose out there.
So that's basically why I want to reuse methods/functions (I'm confused. what are they named?). Something like for each item in list do item.do. Or, what Rend said. I'm definitely going to look into that! But probably in a test scene.
Code blocks are named different things depending on context. A function has a signature, a return type, and 0-many parameters. If it's attached to a class, it's called a method. In C#, you generally deal with methods.
For your buying functions, I would try `public void buy_upgrade(int upgradeID)` or `buy_upgrade(Upgrade selectedUpgrade`.
Refactoring things to be more generic is a big part of learning how to think like a programmer. Honestly, the fact that you're getting code down is more important than it being academically perfect, but I would be happy to talk refactoring and data structures all day.
For your situation, I'd honestly just try Unity as intended first. There are definitely edge cases in which you need to re-invent a few things in your own code, but Unity has way more structure and collective community testing than anything we could write on our own.
If you find that it really doesn't work for you, try using a generic List as Rend suggested above. If you declare it public, the inspector will even tell you what it contains.
Ah, so you've already gone over this part!
Thanks!
Also, yes, instead of buy_wings() I would definitely suggest buy_item(Item item).
You can set the execution order of scripts in unity to ensure the scenery elements go before the ai elements.
Your instinct about writing less code is correct. But typically it's a better idea to spread code out than it is to centralize it.
Question. why do you want to avoid a pile of collision boxes?
For example, to loop through a two-dimensional array back to the beginning, you can loop through this expression: And people also do this clever thing to get correct horizontal and vertical movement in two lines: I have no ability to conceptualize how the first example works (although I ran through some different hypos just to verify that, yeah, it really always works like that), and, although I can understand the second example, it's a little mind blowing because it combines two different concepts (using the arbitrary computer values for true and false to do math that just happens to work out). The same thing with using bitwise operators to store and compare a bunch of true/false flags rather than using them to do math.
Hopefully I'll just luck across all these kinds of things that I need to know or figure out good-enough alternatives to the rest.
I guess I worded it kind of poorly, I'm not really sending anything from the state other then an update call. Instead, my characters have their own state machine which queries my input handler during it's Update, but the character's state machine's Update is called by my GameState. So it only asks for input when it updates, and it only updates while in the GameState. This isn't ideal for some things, like exiting the game, so I cheat a little and have some input's outside of the player character's state machine that are queried during Unity's update. This implementation probably isn't great if you want to do something like what Delzhand mentioned, where some subset of inputs work in multiple states but others don't, you could probably work around it but it might get messy.
Like I just mentioned, my state machine has an UpdateState function that calls the current State's Update. I have my upper most state machine, that has my MainMenuState and GameState, which belongs to a game manager type component. The game manager calls the main state machine's UpdateState during Unity's update, GameState.Update then calls UpdateState on the player's character and on the enemies' state machine. But MainMenuState.Update does not call those updates, so if you're in the menu or paused or whatever the AI and player just don't update at all. It's probably worth mentioning that I'm not even close to polishing yet, so animations will still play/loop even when paused and I haven't really thought of how I'll handle that yet.
Well, gut feeling.
I could fly a series of colission boxes in front of my opponents to have them steer towards islands. Or I could just use one box that gets the position of any island it encountered. Or I could just get those positions from a list (or set of variables).
Likewise for opponents not crashing into eachother, etc.
To me it just makes more sense to have one script that keeps track of where everything is, than to set of stuff and have it interact in the Unity world.
But also it makes it easier for me to keep track of how things are interacting, and figure out how to debug/improve that interaction.
I don't have twenty million bullets flying around with their trajectories being handled by the engine, because that I wouldn't try to centralize...
Start with a kinematic floor say a scale 100, 1, 100 cube with a collider but no rigidbody. Use normal gravity.
Create a stack of unit cubes with rigidbody and box collider and a phyiscs material that has no bounce and maximum friction. The cubes can't be sleeping when the scene starts.
Question 1: how do you position the cube stack so that there is no visible movement when the scene starts
Question 2: how high can you stack the cubes before they vibrate off of each other
In my experiments there is no initial position that prevents movements when the scene first starts. And the maximum stack that doesn't fall over is about 10 assuming the mass is 1 and gravity is default.
I'm putting together my defence, and for fun I squashed up one of the early screenshots with one of the latest screenshots.
I'd say there's been some progress there.
#1: I'm not sure that you can. Maybe add a loading screen and then wait until all the blocks rigidbody.IsSleeping.
#1&2: In Project Settings>Physics enable "Adaptive Force." From the manual: And then play with increasing Solver Iteration Count and Sleep Threshold.
How's this for a list of things to implement?
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
Did you already figure out your player's Plane Movement and maneuvers?
volumetric lightin
Oh in gamedev news, I started adding different ammo types today.
so far ive used it to learn
-writing a proper raycast controller
-figuring out delegates/event systems etc
- proper state handling
- i wrote a first person controller
- a little ballistic solver for grenades
- etc
fun times
I applied smooth low frequency 3d voronoi noise with an extra higher frequency 3d noise disturbance to a volumetric material.
In other news, this weekend I installed the SSD I got from the spring jam and all I have to say is I should have put in an SSD a long time ago. The difference is huge.
Steam: Handkor
I'm using UE4, and that came with a prototype for a flight game, and that came with controls for the player's plane, and they are good enough for now?
You haven't been using an SSD? :bigfrown:
It was the biggest upgrade I've ever made. I can hardly stand HDD PCs anymore!
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
No when I built my last computer I put in a GTX1070 and decided that I was spending enough on this machine and that I could add an SSD later so I was still using HDD and swearing at how much IO is hurting performance.
Now all is well.
Steam: Handkor
Well, the new Unity update completely broke my action maps, meaning my current build is unplayable on 5.6. So, fuck my advice / hold off for now.
I made the mistake of purchasing Shin Megami Tensei IV as a weekend road-trip game, and wound up spending the last two weeks more or less exclusively employed in reaching the end of it. On the plus side, that, plus remembering that Cosmic Star Heroine exists, plus having the idea kicking around in my head for a game with a completely ridiculous elemental damage chart, plus also having a vague concept for the core of an RPG battle engine also knocking around there, has converged into spending about ten to fifteen hours this week (I lost track due to the code trance) knocking together what will be my third or fourth JRPG battle engine. Maybe I'll actually add graphics to this one once I'm done!
In any event, here's the central premise: all the abilities your characters can use are assigned to either Rock, Scissors, or Paper, and the moves interact with each other in the relationship those describe. Scissors moves consist of anything that causes direct damage. Rock moves comprise all those that redirect, weaken, and counter-attack against direct damage. Paper moves are the entire universe of abilities that don't cause direct damage, like DoTs, healing, and other status moves. The turn order is determined by whether an ability is Rock, Scissors, or Paper; Rock moves always go first and distribute their reaction effects, Scissors moves go after that and cause their damage (potentially triggering a reaction from the previous Rock move's effects), and Paper moves go last-- but fail if the user took any damage as a result of a Scissors move. So Rock beats Scissors because it retaliates with stronger counter-attacks, Scissors beats Paper because it makes Paper lose its turn, and Paper beats Rock because Rock doesn't react to indirect attacks.
There's more to it than that, but I think the nuances follow naturally from the premise and don't necessitate typing them all out.
What I will say is that this setup provides an easy way to make an intelligent-seeming AI opponent-- all it has to do is watch the history of what moves you selected and pick an appropriate counter-move from what the characters it controls can use. Your healer consistently throws Paper moves, so the AI knows to use a Scissors move on them, without needing to know much more than that. And the player can then know that their healer is building up some aggro over multiple turns, have them use a Rock move, and feel like they outsmarted the computer.
Of course, the pareto optimal strategy for Rock-Paper-Scissors is complete randomness in your decisions, so maybe it can't seem too intelligent in the long run. But that'll come out in play-testing, which I'm getting close to hitting. I'll let you know how it turns out next week.
Just to be clear, is that because arrows seem to have an actual physical arc? If so, I can't help with that.
Otherwise, my first instinct was to adapt Bresenham's line algorithm to three dimensions. You get the line of "pixels" (actually in-game tiles) from attacker to target, and if any of them read as "blocked", line-of-sight fails. It may not be a perfectly accurate simulacrum of FFT's physics, but whether that matters depends on whether you're aiming for absolutely 100% parity with FFT.
You can simulate floating point math with just integers pretty easily, you also don't accumulate floating point error as you do so either.
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.