I have a "design pattern" problem. I want to enable for a player to change his state. Lets say I have three states or super powers if you will. Each of them have different abilities. If this abilities were just based on some attributes (lets say mass or speed) I could just change that on the player and everything would work fine.
But what if there are some other functionalities changed. Lets say if the player is in the state 2 and he jumps the animation is different and some other thing changes. Now I know I could make this with a lot of checking in update loop for states but I want to make this elegant.
My idea until now is to make generalPlayer object and the each special player inherits from it and adds special abilities, and when player change state I would kind of change instance of player to that instance.
Is there any better way? I am using c# as scripting language
The problem I have with that approach is that you are using multiple different objects for one player. There could be some mess involved with passing data every time the player changes states which would be better avoided. Since C# has delegates, which, for our purposes, behave much like first class functions, it is possible to change the behavior of your player by changing out certain routines and field values on every change of state. This allows you to keep your data in one object and change behavior on the fly without relying solely on conditionals. There is a pithy phrase I have heard many times, that an object encapsulates state and behavior. In C#, you can change state by manipulating field values, and change behavior by relying on delegates. That should cover your problem.
I have found the best suiting sollution thanks to friend. What I use was an Strategy pattern and then put different instances to the interface I used to controll the player. It works like charm. Thanks all for help.
Related
I've been trying to use a mixture of Unity's Animators and Playables in my game, and for the most part it works well, but there's two issues that I've been having for a long time, and I've at best worked around them. Today I bashed my head against them again, and after finding no solution online I decided to get my lazy ass to finally ask for help.
The basic setup is that my characters have:
An Animator with its controller, state machine, etc. that is used mostly for movement, jumping, climbing, etc. In case this is relevant, each character has an override controller of a generic one.
A very simple playable graph with just an output (wrapping the animator) and an input (wrapping the specific clip I want to play at the time). This is used for actions and attacks.
The problems I have are:
1- I can't seem to figure out an elegant, clean way to know when the clip fed to the graph (second part above) is finished. Currently I circumvent this by simply calculating how long the clip is and dividing by the current animation speed factor; I also have to account for when the animation is paused (e.g. hitstop). This gets the job done but is quite unelegant, and I'm sure there must be a better way.
2- Most importantly, when I'm done with the graph and standalone animation, the values of all of the properties the clip touches become locked at their last value. They stay locked even during any animation played by the regular animator; even if any of these later animations change its value, it snaps back to that locked "last frame" value when they end.
I've tried several things to solve this:
2.1- Set the default / desired value of the properties in the idle / default animation (to "mark" them as animatable properties in the normal animator's animation). This only fixes the issue for whatever animation is touched; any other animation played after that instantly reverts to the value locked by the last frame of the animation played by the graph.
2.2- Destroy the playable wrapping the animation (I do this anyway for cleanup since I need to recreate it each time a new animation plays).
2.3- Destroy the graph and recreate it each time (surprisingly, even this keeps the values locked).
2.4- Disabling the animator and enabling it again.
I'm frankly starting to lose my mind with the second problem, so any help would be exceedingly appreciated. Thanks in advance for any help!
Although this question is pretty old, I'm adding answer (along with my related follow up question) just in case there's more people that end up here from a search engine.
Animations (both "legacy" and non-legacy) can fire off events at some frame - just pick point (frame on dopesheet, place in graph on curves) and click "add event"...
There's some difference on how to specify which object/script & function to call between legacy and non-legacy - but in both cases it's basically a callback so you can know for sure when some animation started/finished (or any point in between).
Instead of trying to change values of those properties that are "locked by animations" from void Update() you seem to need to do those from within void LateUpdate().
From my testing - using/doing "legacy" animations (that also means "animation" component instead of "animator controller") allows you to use Update() - at least once the animation is finished.
And also worth keeping in mind that "animator controller" (component) doesn't accept importing "legacy" animations for any of it's states.
And animation (component) doesn't seem to play (at least not auto-play) non-legacy animations.
As of my question, well it's basically same as OPs question - is it possible to somehow "unlock" these properties (obviously without any states/animations playing) while using "newer" animator controller?
Although - based on things I've read while trying to find what's going on. Those "legacy" animations are not really "legacy" - and seem to be there to stay for reasons like being better for performance.
Unity's new "Prefab Variant" feature, introduced in 2018.3, is pretty sweet; you can learn more about it here.
I made some changes to an imported 3D model, preparing it for usage in my game, and then dragged the changed GameObject into the file area to save the prefab, when I was asked whether to save it as an original prefab or a prefab variant.
The first (original prefab) option basically removes ties to the source prefab (the 3D model), applying all overrides and setting it in stone. The latter (prefab variant) option still uses the 3D model prefab as it's imported, and applies all of the changes I've made as overrides atop that, meaning if I re-import the model, its new changes will propagate and the changes I'd made on the prefab variant would also still exist.
That sounds great! In fact, I can't think of any circumstance where I wouldn't want that. If I was changing the source prefab so much that the overrides became invalidated, then I'd need to redo work whether or not I used the prefab variant feature - no difference there.
Thus I can only think of benefits to using the prefab variant... Perhaps it's an overhead thing, but I don't know anything about that. I even get the feeling that there could be some performance benefits to using variants (deduplication of prefabs or something like that), but that's me just speculating.
Hence my question: when and why shouldn't I use the new prefab variant feature, and opt for original prefabs instead?
Variants are great if you want several versions of the same base object. if you have more than one type of the same object you should always use them. the overhead is practically the same, but its a great orginizational feature! since its mainly to improve ease of use, for multiple objects as well as workflow, there is a major caveat to using it.
Dont use this feature if your disorganized. but wait, your going to use it, its just to great, having all those different prefabs ready at a moments notice! so heres the thing...
if your making a new version of your base object, replace the base object... you dont want some to be a variant of the bas, and others the variant of a variant, keep it organized, and you will reap the rewards in the time-management are of your project!
I am trying to code an end for a level in a simple game. A lot of things need to happen at slightly different times. The character needs to do a celebration. Text needs to pop up on screen. The camera needs to move to show off the win, and finally there needs to be a scene transition.
This all seems like a great thing to solve with an animation. All these things could come in and act on specific key-frames, at the end raising an event and ending the scene.
The problem is it looks like animations have to be attached to specific objects. My camera, player, and the static global GameController are completely unrelated. In fact the global controller can't be related to anything. Because of that my animations don't see all the objects and can't control them. I am instead stuck writing synchronized animations, and code with a lot of yield return new WaitForSeconds(...);. I find this very difficult to manage, and seems like a lot of waste. Is there any way I can use animations, or some other frame based tool to globally animate my game?
Look into Unity's Timeline system. I believe this is exactly the sort of thing it was made for.
I'm making a level based game using SpriteKit. I would like to know the best practice for making level changes. I was originally using one Scene as my gameplay scene and when a level is completed, it removes all nodes in the scene and then adds the ones for the next level. I am using a background node that is persistent throughout the entire course of the game. I'm worried about memory because I don't think ARC will deallocate the nodes removed because the scene is persistent. Is this method ok or should I instantiate a new scene for when a level is changing?
The best practice is to separate game data and assets from game code. This way, you can make changes to stuff without having to recompile (and is handy if you are working with another person who doesn't code).
Here is what apple has to say about it at WWDC 2014:
When you transition between scenes, ARC will deallocate the prior scene, assuming you made no strong references to it. Since you're starting out it's unlikely you need to worry about this right now... it's mostly done with globals and closures, and you should be able to fix it if it becomes a problem (but likely won't).
You can use things like unowned self and weak var etc to ensure this doesn't happen when needed. Again this is a more advanced topic but it's good to be aware of them.
Really, making level changes is entirely up to you... if you want to make a state manager that swaps out stuff to one scene, you can certainly do that... or, you could make a bunch of scenes and transition to that. Again, the best practice here is separating game content from game code, not necessarily how you switch scenes.
Personally, I would used separate SKScenes-- because it's already built in with transitions, memory management--and you have the option of using the editor, and you get to give each scene it's own file if desired.
There is also GameplayKit which has a statemanager, in which case you could use one scene and have different states be the level.
here are some resources, buried in there are some nuggets pertaining to what you want.
https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/SpriteKit_PG/DesigningGameswithSpriteKit/DesigningGameswithSpriteKit.html
https://developer.apple.com/videos/play/wwdc2014/608/
https://developer.apple.com/library/content/samplecode/DemoBots/Listings/DemoBots_SceneManager_swift.html
I'm looking to make an RPG with Cocos2D on the iPhone. I've done a fair bit of research, and I really like the model Cocos2D uses for scenes. I can instantiate a scene, set up my characters etc. and it all works really nicely... what I have problems with is structuring a game loop and separating the code from the scenes.
For example, where do I put my code that will maintain the state of the game across multiple scenes? and do I put the code for events that get fired in a scene in that scene's class? or do I have some other class that separates the init code from the logic?
Also, I've read a lot of tutorials that mention changing scenes, but I've read none that talk about updating a scene - taking input from the user and updating the display based on that. Does that happen in the scene object, or in a separate display engine type class.
Thanks in advance!
It sounds like you might do well to read up on the Model-View-Controller pattern. You don't have to adhere slavishly to it (for example, in some contexts it makes sense to allow some overlap between Model and View), but having a good understanding of it will help you to build any program that has lots of graphical objects and logic controlling them, and the need to broadcast state or persist it to disc (game save), etc.
You also have to realize that cocos2d provides a good system for structuring the graphical scene graph and rendering it efficiently, but it doesn't provide a complete infrastructure for programming games. In that sense it's more of a graphics engine than a game engine. If you try to fit your game's architecture into the structure of cocos2d, you might not end up with the most maintainable result. Instead, you should treat cocos2d as what it is: a great tool to take care of your display and animation needs.
You should definitely have an object other than the scenes that maintain the game state, because otherwise where will all the state go when you switch between scenes? And within scenes/levels, you should simply try to use good Object Oriented design to have state distributed over objects of various classes. Each character object remembers its own state etc. Here you can see where MVC becomes useful: when you save the game to disc, you want to remember each character's health level, but probably not which exact frame index the sprite animation was showing. So you need to distinguish between the sprite and the character (model) itself. That said, as I mentioned before, for game objects that don't have a lot of logic attached to them, or which don't need to be saved, it might be ok to just fuse the Model and View together into one class (basically by subclassing CCSprite).
To pull off MVC the way it's supposed to be, you should also learn the basics of Key-Value Observing. (And you'd do well to use this replacement for Apple's interface.) In more intensely real-time games, techniques like this might be too slow, but since you're making a RPG (good choice for starting out) you could probably sacrifice performance for a more maintainable architecture.
The game scene (which is just another cocos2d sprite) plays the role of Controller, in terms of the MVC pattern. It doesn't draw anything itself, but tells everything else to draw itself based on inputs and state. It's tempting to put all kinds of logic and functionality into the game scene, but when you notice that it swells, you should ask yourself how you could separate that functionality into other classes. Analyze which type of functionality you're implementing. Is it to do with data and state (Model)? Or is it about animation and rendering (View)? Or is it about connecting logic with rendering (in which case you should try to make the View observe the Model directly)?
The game scene/Controller is basically a dispatch center, which takes input events (from the user or from sprites reporting that they've hit something, for example) and decides what to do with them: it might tell one or several of the Model objects to update themselves in some way, or it might just trigger an animation in some other sprites, for example.
In a real-time game, you'd have a "tick" or "step" method in the scene which tells all objects to update themselves. This method (the game loop) is the heart of the program and is run every time a new frame is drawn. (In modern game engines there's a lot of multi-threading but let's not think about that.) But in your case, you might want to create a module that can "play the game" completely separate from the game scene. Imagine creating a program that can play chess through the terminal, using only text input. If you create the whole game system in that manner, and then connect it to the graphics engine through a small and clean interface, you'll have a really maintainable app with lots of reusable code for future projects!
Some good rules of thumb: the model (data) shouldn't know anything about sprites or display states; the view (sprites) shouldn't contain any of the game's actual logic (the game rules) but only know how to do simple things like moving and bouncing and reporting to the scene if something complicated happens. Whenever possible, the view should react to changes in the model directly, without the controller having to interfere.