I have inside my game 20+ character that are all the same thing with diffrent mesh, same animations, same blueprints etc…
But in every update i will add 8 more characters, and i’m forced to do every change i’m doing in 20+ characters and that takes time.
I know that i can retarget some animations with a base skeleton and then just creating the animations for all characters, but this does not solve the problem with the character logic & code and does not redusing the final game size.
I was wonder how epic games manage to do that in fortnite with so many skins…
I’m sure that there is a solution to this problem that i can’t find.
Epic games has mastered the art of reskinning.
The secret is dynamic loading/binding to a common framework.
Each Fortnight skin is unique in appearence and common in skeletal structure, allowing it to fill a generic slot in the engine.
Your builds have no generics applied to them, so every animation must be baked separately.
Related
For my exam project in coding class I have to recreate a game in Unity where I can also show off my OOP knowledge. Some of the requirements of the project are encapsylation, inheritance and polymorphism.
What are some good ideas for a game that can show all these things? The ideas I had was Candy Crush, Street Fighter, Hearthstone or some tower defense, though I'm not sure if I'll be able to make good use of OOP in these games.
All games you're listing aren't really fit for an exam project. I don't know how much time you have to finish this project, but I'd go with something a lot easier, especially if you're going to do it youself. If the main objective is to use your OOP knowledge, any simple game with maybe different kind of enemies or items will do.
For instance, asteorid, but with other kind of objects and weapons beside the asteroids and the main gun themeselves. Asteorids, bombs, fire balls, you name them. All of them must have some degree of common behavior and that's where OOP can be used. Weapons too. Rayguns, double barrels, radial shots, shockwaves...
This is just an idea. You can do something different like Pac-Man and implement diver kinds of ghosts, for instance. Or different main characters with different abilities.
Although, be aware that Unity (and most other game engines) although built on topo of OO languages prefer a Component-driven approach and true OOP is used in very little quantities in very specific parts of the game. Usually data structures more than game objects.
I had a client ask me to build a Tamagotchi type of game and characters are a place where you can use a lot of inheritance to build some base character types then branch off into specific character types. The classic base "animal" and then "bear"/"wolf" etc or biped/quadruped etc some lay eggs, others are mammals you could come up with some good inheritance trees.
In Unity, the different types would need to implement their different ways of triggering animations via the Animator controllers possibly. Most of the systems in Unity won't need any inheritance though, your plain C# classes would implement these and I don't recommend that you build off of Monobehavior. Instead, you have a ScriptableObject and it will instantiance the necessary C# class possibly based on an enum you have that represents all the different types.
Basically it was a 3D Unity Project (nothing used 2D components) and had a simple plane as the ground, and then the camera was above - pointing down at the "ground". The character had 2D art that was perpendicular to the overhead camera, but they were correctly upright with the normal Z world direction so their "feet" were on the ground plane and normal physics/rigidbody can be turned on. This way you can add a Navmesh to the ground and Nav Agents to your characters making movement really simple. They move around like normal, but their art is facing upwards towards the camera. You can give them colliders and rigidbodies. Setting this up took barely any time and saves you from having to work in pure 2D mode with all the problems it comes with for implementing your own movement and control systems, collision detection, etc. If you go pure 2D you lose a lot of systems and it's not necessary. This way you can just use simple 2D art assets.
Your tower defense is also not a bad idea because towers can have inheritance too. Again, design your own classes and you shouldn't be inheriting from Monobehavior in your base class. You aren't expanding on Monobehavior, you are building your own classes.
So I was working on a proto where I want to implement a character swap functionality in the game.
I'm not talking about swapping the camera component from one character to another or changing the material used in a mesh, but rather changing the whole skeletal mesh so that the player can use the new character to complete the mission/Level.
(Note: The swapped character will have different animations, attacks and everything).
I Saw some Bp tutorial in youtube but they use "Set Skeletal Mesh" which can easily change the skeletal mesh using some conditions... but I want to implement this in c++.
Can anyone Help me to understand the logic...The Logic I have in mind is to use an array to store the Uskeletal component and choose the meshes available but I don't know if this is possible or optimised.. !! Valid Suggestions will be Greatly appreciated (Sry for the spelling and Grammer)
You can keep an array of skeletal meshes as UPROPERTY on your character class. Just keeping them around does not automatically visualize or use them in any way.
To do that you need to create and attach a USkeletalMeshComponent to the character. If you look at component's interface, you will see a SetSkeletalMesh(class USkeletalMesh* NewMesh) method you can use to actually set the mesh used and rendered by the component.
Imagine a large free-roam game in Unity,
The yellow size indicates about the largest you can make a typical Terrain in Unity.
Art dept. will completely build, meter by meter, the entire scene.
Please note, this has absolutely no connection to repeating scenery (as in runners) or procedural scenery (as in say some race games).
Really, what is the correct and good way to do this in Unity?
use say 50 or so terrains, each perhaps 100m x 100m ?
can you even have or use that many terrains?
or what?
For anyone googling here.
The correct solution is indeed
Terrain stitching
that's it.
In practice you must use one of the tools available to do this (eg, TerrainFormer) or, your team will write from scratch a terrain stitcher.
Yes, you just use "many terrains".
The best approach to the exact problem posed,
is in fact to just:
"use lots of Terrains".
It seems to be perfectly viable in Unity to have many (dozens) of Terrain units, basically "sitting next to each other".
In practice, you'll need TerrainFormer
https://assetstore.unity.com/packages/tools/terrain/terrain-former-20052
or one of the similar tools.
(Or, I suppose, from scratch write your own tool to stitch terrains, and allow you manipulate them all at once, join the edge-heights perfectly, etc etc.)
It's not realistically possible to just perfectly sit many Terrains together (by hand), matching all the edges, etc etc. So you're going to need a "stitcher" package for putting many Terrain squares together.
So, this huge area ..
has about 12 Terrain.
So that's the answer, you can indeed have "many, many" Terrain in a Unity project, you do indeed essentially just "sit them next to each other". In practice it's not achievable unless you use one of the editor tools such as TerrainFormer.
The proper way to do this would have been with procedural mesh generation with MeshFilter and Mesh API but you mentioned that this not at all random or generative so that one is eliminated.
It's just simply a very long, thin, hand-made environment
The best way in this case would be a Modular Level Design. You need to create Modular Assets. With this you can have a long road in pieces which can be tileable. A good modeling artist should be able to create and texture modular assets with 3D modeling packages like Blender, Maya or 3ds Max.
All the programmer has to do is make each asset a prefab then use the Instantiate function to instantiate them to create any distance of environment. You can also create a static environment in the scene from the Editor. Almost anything can be made into a modular Asset especially buildings and roads.
After assembling them in Unity, you can do static batch on all the instantiated modular parts with Unity's StaticBatchingUtility.Combine to improve performance of the game since they are not being moved.
Below is an example of a modular road asset that can be used to create almost any amount of road:
You already answered your question
in this case would it be better to not bother with Unity's otherwise excellent Terrain, and the modellers would just outright build the long course/scenery? (Obviously you'd have to chunk it so it all occludes fine)
I think it's the way to go. If the performance is an issue, try putting each chunk in different scenes and then have a master scene to load them async and additively. And of course you want to unload each scene as it becomes invisible in the camera.
I personally go with your own solution which is letting the Unity Occlusion Culling system to take care of the hiding and showing chunks. I only go with the separate scenes approach if I'm not getting enough performance this way.
I recently had the same problem. We build a tilebased infinite runner with road crossings. The camera was positioned behind and over the car looking down on the street and the player car. So the setup is quite comparable.
We used Curvy from the Asset store to create paths for moving the player and also for creating the geometry of the streets and the surroundings among the streets.
https://assetstore.unity.com/packages/tools/level-design/curvy-splines-7038
It is also easy to spawn tiles with curvy paths and combine them at runtime. So you can separate long distances into smaller segments and spawn them randomly.
We also used QuickBrush from ProCore to quickly paint environment detail to the geometry like trees, bushes or stones. I think procore tools are now implemented in the new Unity 2018 version.
Worked quite well.
I am creating a game in Unity3D.
My character animation is in the form of stickman animation files but can be either Maya or Cinema4D.
Is it possible to have multiple 3D characters and swap between them in game - however, use the same stickman animation as their movement underneath?
Would the characters need to have the exact same skeleton?
Basically you can use the same animation for more than one model according to the book Creating 3D Game Art for the Iphone with Unity by Wes McDermott (some excerpts available at Google Books.
Citing page 143: Another aspect worth mentioning is that you can reuse animations on different characters as long as their hierarchies are the same based on how the Animation Component references objects.
I tested it some time ago with a 2nd rig being synchronised in parallel and it worked.
So the skeleton should be identical at least the bone names need to be present. Swapping characters is possible and mainly used for death animations. In this situation you have a kinematic rigidbody whose physics components are then transformed into ragdoll. I see no problem to extend this to the whole character.
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.