I'd like users to be able to design their own GameObjects in unity, and somehow import them at runtime into a game I'm making.
That means maintaining the hierarchy (there may be child objects), and any scripts, components, models, and materials used.
After looking around, I haven't seen any cookie-cutter solutions to this problem, but I also have a hard time believing I'm the first person to attempt to write a moddable game with Unity's engine. Are there any best practices for adding prefabs/assets at runtime?
AssetBundles are the way to go.
Basically you can create one or multiple assetbundle files from scenes or specific objects which pack everything into them.
Assetbundles contain everything you want, except new scripts. You can reference scripts but not create them per default.
If you want to bundle new scripts you need to create a ddl file and load that during runtime.
Related
So I did a lot of research, and long story short decided to go with making a game manager with dontdestroyonload for persistence.
There are many tutorials, but I'm new and I have many questions in my head when it comes to actually implementing this. It's easy when you just have one player character, but my game has a party of players, their prefabs only need to be spawned in battle, then when the battle is over, I don't need their models...just their stats.
So if I attach all my party members to the game manager, it will keep their stats but also keep everything else:model, battle scripts, etc. I just need to keep their stats. So how do others do it in practice?
I was thinking of adding code to destroy the scripts and components I don't need, then reattach them when a battle is triggered, but I just feel like it's hacky and I'm missing a better established solution out there. I've looked at professional packages and never saw anyone do that, it's like they store the stats somewhere else and just spawn a prefab in battle.
Why does this code need to be attached to a game object at all?
There is no reason to extend MonoBehaviour for things that "store data" and attach it to a GameObject (which is then never destroyed). This is the result of being new to Unity and every time you create a script, Unity automatically has it extend MonoBehaviour and you get into the thinking that EVERYTHING has to be attached to a game object and treated like one. You don't have to do this. Here's a class that doesn't extend anything (it implements ISerializable, but that's not relevant here).
Instead, you might want to look into scriptable objects, or have some other method of storing the player data (e.g. your GameManager class could be a singleton with a static instance reference). What works best for your project is mostly up to you: you know the most about your goals, you need to evaluate your options and figure out what works for you.
my first question on here and I cant seem to find a similar question so sorry if this has been asked before.
This is Unity related by the way, and yes I have also posted on Unity3D answers but thought I might also be able to get help from knowledgeable individuals on stack overflow also.
Basically I am wondering if there is a way to make platform dependent objects or components. I know I can wrap code in pre-processor directive commands which I have been doing, but I tend to use a ton of plugins, many of which only function on specific platforms.
However, I have just one project for all my platform dependent versions of the game and wish to continue working this way. So I was wondering if somehow I can make say an object that has the compatible plugin components, that will only be created if a certain platform is being built for.
If not, is there a way to make an object use say a specific plugins component if say on WP8, but then another entirely different component in its place if building for Android?
If these are not possible, how do you guys get around having platform dependant plugins? Do you simply just make separate projects for each platform? (feels like that defeats the point of unity's cross platform-ness though...)
Thanks guys, any help will be greatly appreciated!
Unfortunately, you will be forced to rely on pre-processor directives if you need to run unique code per platform.
However, this can be a lot easier to manage if you apply a facade-based design pattern. Instead of peppering platform-specific details in myriad scripts throughout your project, you can create one or more facade components that expose a more generic, abstract interface. The facades can internally manage prefabs, APIs, or whatever other platform-specific details you need.
As an example, you could write a SaveManager class that manages player save data. On platforms where direct file access is available, the SaveManager instantiates and controls an internal FileSaveManager that uses direct file access. On other platforms such as web builds, the SaveManager instantiates and controls a PlayerPrefsSaveManager that uses Unity's PlayerPrefs system instead. That way, each of those classes contains only the code that it needs, and other classes can just call SaveManager without worrying about those details.
I am messing around in a Unity3D, making a 2D project. I want to create my own code architecture for Unity's component based system.
As I don't want to create God-Controller scripts, and being more into code resposibilities separation solutions ( having MVC, MVVM in mind ), I am trying to find some good solution.
My first take looks like this:
GameObject is created from:
Unity Components - for ex. SpriteRenderer, Animator, Rigidbody2D
Controller - The only resposibility of this component is to handle Unity functions ( like
Update, FixedUpdate, OnCollision ), and executes functions from model.
Models|Proxies - this components contains data, functions to manipulate game object unity components, and dispatching events to outer world.
I am wondering what do you think about this aproach, what are your code habbits in Unity3D projects, and what solutions worked for you.
While I have learned and taught MVC and similar approaches, I find that when designing game architectures one usually has to be a bit more flexible. In unity I generally take the following approach.
I will create a few GameObjects to hold the necessary global logic. This would be things like the overarching state machine, networking, and sometimes control input. If anything needs to persist between scenes it will go here. Each object typically has one component script for game logic and one for temp/debugging functions that gets turned off or removed when not needed.
If the project has fixed levels I will make each level a scene and I will store level layout and other level specific information in the scene. If I am doing a more procedural project I will create a "LevelGenerator" object with component scripts that build and populate the level at runtime.
If I am building a system that has lots of mostly independent agents (e.g. enemy creatures) I try to keep the game logic and necessary state information for each agent as close to it in the hierarchy as possible. For example, the agent's position and rotation would be stored in it's transform. I might store the agents health, ammunition, speed, and current status effects along with the functions for moving, shooting, healing, and death in a component script on the agent's GameObject.
While there are countless other approaches that could work, I like this approach for a few reasons:
It saves me from having to manually manage tons of data access in a central script. If I need to know where all the monsters are, I can just keep a list of game objects rather than using custom data types.
When the agent gets destroyed all the local data goes with it. (No complex functions to clean up dead agents.)
From a game logic perspective (on the projects I typically work on) it usually makes sense that each agent would "know" about itself and not about everyone else.
I can still use all the OO goodies like polymorphism etc. when necessary.
This response likely says more about how I approach game design and software architecture than general best practices but it might be useful.
One note on encapsulation in Unity. Every component script you add to a game object has a bit of overhead. If your scene has a couple of dozen agents in it, than this is not a big deal and I would recommend trying to keep things as OO and modular as possible. If you are building a system with hundreds or thousands of active agents, cutting the components per agent from two to one can mean quite a bit of saved frame time.
I use another approach.
I don't use many controllers attached to game objects. I just have some kind of GameController which creates other structures.
I have separate project shared between other games. This project contain design patterns and is built before main project did. I widely use State, Observer, Builder, ObjectPool etc. patterns to make my code clear and simple.
Another reason I use such approach is performance optimization. I create objects once and then reuse them. Also I do once such things as gameObject.GetComponent etc. When I need to create many objects using the same prefab I use ObjectPool to avoid CreateInstance/Destroy.
My logical game objects (actors) communicate each other using Observer pattern. My only one GameController just send events like Awake, Update to actors. Some objects have StateController which retranslate events like Awake and Update to current object state. This is useful to separate behavior of each object state.
I have component system architecture similar to Unity. And I also have services like InputService that can be accessed via ServiceLocator in any object.
I have also points, but the idea is clear and easy maintainable code. This is difficult with standard Unity controllers and SendMessage approach.
I'm making a simple cocos2d adventure game, but have no clue how to implement any sort of levels. I've searched for tutorials, but can't find any.
Is there anything I can use to figure out levels in cocos2D?
Thanks
There are so many ways to implement levels in a cocos2d game. I think a straightforward way is to:
Modeling your levels first. Decide what should be stored in a level's data model. I think typically you will have at least two kinds of data:
Player data (Run-time generated, e.g. score, character's current location, etc.)
Level data (e.g. what's on the screen in this level, the rule to pass this level, etc.) This data could be either fixed or dynamic. If the levels are designed by developer, like Angry Birds, you can store this part of data in external configuration files and load them on demand; if the levels are dynamically generated according to some rules, then the rules should be stored in the data model.)
Design a general game-play layer which can be initialized according to an instance of the data model above. The layer class controls the presentation of the level, and is responsible for user input handling.
If your levels shares some global data, you can make another shared data model to manage these things (e.g. total score, achievements, player's name, etc.). Create a shared instance of this class and manage the data in it via your game-play layer.
You could also consider more advanced way like using scripts (such as Lua) to implement the levels.
You mentioned not being about to find any tutorials. I agree that finding free online tutorials for cocos2d can be challenging. I ran into the same problem when I started learning it. I recommend grabbing a book on cocos2d such as Learning cocos2d. There is so much to the API that you will have a very hard time creating even a rudimentary game without any tutorials or guidance, unless you have a lot of prior programming experience.
I'm trying to learn OpenGL ES quickly (I know, I know, but these are the pressures that have been thrusted upon me) and I have been read around a fair bit, which lots of success at rendering basic models, some basic lighting and 'some' texturing success too.
But this is CONSTANTLY the point at which all OpenGL ES tutorials end, they never say more of what a real life app may need. So I have a few questions that Im hoping arent too difficult.
How do people get 3d models from their favorite 3d modeling tool into the iPhone/iPad application? I have seen a couple of blog posts where people have written some python scripts for tools like Blender which create .h files that you can use, is this what people seem to do everytime? Or do the "big" tooling suites (3DS, Maya, etc...) have exporting features?
Say I have my model in a nice .h file, all the vertexes, texture points, etc.. are lined up, how to I make my model (say of a basic person) walk? Or to be more general, how do you animate "part" of a model (legs only, turn head, etc...)? Do they need to be a massive mash-up of many different tiny models, or can you pre-bake animations these days "into" models (somehow)
Truely great 3D games for the iPhone are (im sure) unbelievably complex, but how do people (game dev firms) seem to manage that designer/developer workflow? Surely not all the animations, textures, etc... are done programatically.
I hope these are not stupid questions, and in actual fact, my app that Im trying to investigate how to make is really quite simple, just a basic 3D model that I want to be able to pan/tilt around using touch. Has anyone ever done/seen anything like this that I might be able to read up on?
Thanks for any help you can give, I appreciate all types of response big or small :)
Cheers,
Mark
Trying to explain why the answer to this question always will be vague.
OpenGLES is very low level. Its all about pushing triangles to the screen and filling pixels and nothing else basicly.
What you need to create a game is, as you've realised, a lot of code for managing assets, loading objects and worlds, managing animations, textures, sound, maybe network, physics, etc.
These parts is the "game engine".
Development firms have their own preferences. Some buy their game engine, other like to develop their own. Most use some combination of bought tech, open source and inhouse built tech and tools. There are many engines on the market, and everyone have their own opinion on which is best...
Workflow and tools used vary a lot from large firms with strict roles and big budgets to small indie teams of a couple of guys and gals that do whatever is needed to get the game done :-)
For the hobbyist, and indie dev, there are several cheap and open source engines you can use of different maturity, and amount of documentation/support. Same there, you have to look around until you find one you like.
on top of the game engine, you write your game code that uses the game engine (and any other libraries you might need) to create whatever game it is you want to make.
something many people are surprised with when starting OpenGL development is that there's no such thing as a "OpenGL file format" for models, let alone animated ones. (DirectX for example comes with a .x file format supported right away). This is because OpenGL acts somewhat at a lower level. Of course, as tm1rbrt mentioned, there are plenty of libraries available. You can easily create your own file format though if you only need geometry. Things get more complex when you want to take also animation and shading into account. Take a look at Collada for that sort of things.
again, animation can be done in several ways. Characters are often animated with skeletal animation. Have a look at the cal3d library as a starting point for this.
you definitely want to spend some time creating a good pipeline for your content creation. Artist must have a set of tools to create their models and animations and to test them in the game engine. Artist must also be instructed about the limits of the engine, both in terms of polygons and of shading. Sometimes complex custom editors are coded to create levels, worlds, etc. in a way compatible with your specific needs.
Write or use a model loading library. Or use an existing graphics library; this will have routines to load models/textures already.
Animating models is done with bones in the 3d model editor. Graphics library will take care of moving the vertices etc for you.
No, artists create art and programmers create engines.
This is a link to my favourite graphics engine.
Hope that helps