• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

GAF Indie Game Development Thread 2: High Res Work for Low Res Pay

Status
Not open for further replies.
Thanks for the info, I see they have a trial version which I'll give a go.

Also in your example project I saw that the blockbox is not removed if you get hurt while blocking. (it stays there floating)

Oh, that'd be an oversight. Good catch.

edit: I updated the project file (same link). You just need to add with (myBlockbox) instance_destroy() to the damage event. It'll respawn if blocking is retriggered.
 
Well, it looks like you figured it out anyway - I'd have just suggested using the Material Transform or the Bitmap to Material Light nodes as 'converters' at the start of your graph.

Depending on how much load you want to offset onto your material rather than your workflow, the Bitmap to Material node is super useful for generating materials for different purposes, as it will auto generate all relevant PBR nodes from just a diffuse and a metal texture - obviously manually baking your own AO etc per object yields better results, but auto-generation is definitely faster...
EDIT:
Basically, I've got pretty good results just using a diffuse and normal texture (ie 'last gen workflow') combined with a base template material within Designer

Thanks, I kind of took your advice and deleted some of the input map nodes and replaced them with PBR material nodes. Now it only needs AO, Curve, WorldSpace, and Normal (all optional). I was setting it up in painter first, then exported the maps into Designer, but I now realize how unnecessary that was. I used to hate making textures, but I actually really like working with Designer/Painter and making procedural materials is actually fun. What great software!
 
So, having started a visual novel project earlier this year, I've had interesting developments but, my luck be damned, bloody AX Con came and everything kind of halted until it's over. It's an endless cycle of waiting, lol.

At least one of the sprite artists replied with finished art so that's my new avatar from this day on, heh.

Anyway, I've been also doing plenty of photographic studies with a camera I bought in Japan, then experimenting a lot with photo filters for the creation of generic/common backgrounds as drawn ones are not only expensive but take a fair bit to get done so, in the meantime, they serve as good placeholders.

I'm hoping to nail down a lot of details in the coming week(s) so I can finally throw some dev-progress that isn't just text. (This is the most depressing part for a writer/programmer, not having much to show other than text sucks...)

But text is a key component in VNs, and I'm debating between using NVL mode (think Higurashi), a traditional ADV (think most visual novels and dating sims) or a combination of both, with narrative passages in NVL and dialogue as ADV (something I used for my first experimental VN project). It's a question I've been ponering for a while. NVL allows me to go nuts with the writing and add more descriptions but it obscures sprites and effects. Meanwhile, ADV is great and all but having to use a smaller textbox forces for a more dialogue-driven game.

Just the daily dramas of VN development. I got in touch with the programmer of Sound of Drops so he may be able to lend me a hand while I focus on writing and making BGs.
 

Jumplion

Member
I have to recommend for people using Unity, if you haven't picked up an alternative Input manager for the engine you really should. I've been trying out the trial version of ReWired and it's caused the headache I had to make double-tapping work to literally just be a function I call when I need to.

Make, like, 70 lines of code into 2. Man it feels good.
 
I have to recommend for people using Unity, if you haven't picked up an alternative Input manager for the engine you really should. I've been trying out the trial version of ReWired and it's caused the headache I had to make double-tapping work to literally just be a function I call when I need to.

Make, like, 70 lines of code into 2. Man it feels good.

I plugged Rewired a while back (right around the time it launched) and I can absolutely agree. Rewired is fantastic, easy to use, well-thought-out, and is what Unity's default input model should've been from the get-go.

It's one of the best-engineered plugins I've seen. I can't recommend it enough for when Unity people run into issues with Unity's input management. (Which should happen right around the time you start using Unity's default input manager...)
 

bkw

Member
We use Rewired in our game right now as well. It works pretty well and is pretty robust. I do think the API and setup is more complicated than it needs to be, but maybe that's because I don't need all the features that it provides. Not a huge fan of closed source stuff though.

For my next project, I'll probably give InControl another shot. Since it's gone paid, it looks to be getting better.
What kind of problems does the default input manager present?
For us, it was the fact that you couldn't uniquely identify the controllers. If we used four Xbox 360 controllers, we can only identify them from an array of controller names (which would all be the same). If one controller gets disconnected, we wouldn't know which one, and for the remaining controllers, their joystick ids could/would switch. I believe Rewired gets around this by having native input support for each platform, bypassing the input manager.

There was a post on the Unity forums about them revamping their input system, but like all Unity features, who know when that'll be coming...
 
I wish I had known about Rewired before writing my own input system. Although I may switch to it in the future as it does a LOT more than mine currently does. I support controllers natively but there's a lot it does that mine doesn't so it would be nice to open up that end without grunting out the work when I already have a lot to do and run out of hours every day. I'm running behind with the game a metric ton. If I had vacation time lined up I would definitely be able to play catch-up but I need to save mine in case I need it.

Might be something I buy in the future, for sure.
 

Dynamite Shikoku

Congratulations, you really deserve it!
We use Rewired in our game right now as well. It works pretty well and is pretty robust. I do think the API and setup is more complicated than it needs to be, but maybe that's because I don't need all the features that it provides. Not a huge fan of closed source stuff though.

For my next project, I'll probably give InControl another shot. Since it's gone paid, it looks to be getting better.

For us, it was the fact that you couldn't uniquely identify the controllers. If we used four Xbox 360 controllers, we can only identify them from an array of controller names (which would all be the same). If one controller gets disconnected, we wouldn't know which one, and for the remaining controllers, their joystick ids could/would switch. I believe Rewired gets around this by having native input support for each platform, bypassing the input manager.

There was a post on the Unity forums about them revamping their input system, but like all Unity features, who know when that'll be coming...

Ah that sucks.
 

Jobbs

Banned
Trying to do some new logic and having a
the-best-of-the-and-quot-i-don-t-know-what-i-m-doing-and-quot-meme.jpg
kind of day. Okay, time to go out. Maybe I'll have better luck later.
 
Ah that sucks.

Not to mention that Unity, by default (unless this has changed recently) does the whole "game triggers count as opposite ends of the same axis" thing.

Basically, both triggers end up mapped to the same axis (I'll call it TriggerAxis here), which really screws you up if you want to check for both triggers at the same time.
For example, if you were making an FPS with iron sights you'd run through something like this:
  1. To enable your "iron sights" mode you need to check for the left trigger for input.
  2. Now you need to shoot baddies, right? So you need to check your right trigger for input to decide whether you want to shoot or not. Here's where the problem lies.

Each trigger is the mirror-image of the other one on your TriggerAxis. For the sake of this explanation, your left trigger reads from 0 (not pulled) to -1 (fully pulled), while your right trigger reads from 0 (not pulled) to 1 (fully pulled).

If you have both triggers pulled at the same time, one of two things can happen. 1.) Unity completely ignores the second trigger pull, or 2.) Unity detects the second trigger pull, but because the triggers are mapped to -1 and 1 at this point they cancel each other out. The net effect is that either one trigger isn't detected or both triggers deactivate.

That's terrible, and really, really bad for games that make use of the triggers. If I remember correctly, Unity's implementation may not even have the triggers on a true axis, it may just read as a binary "pressed" or "not pressed", which means that you can't even check if a trigger is partially pulled or not.

Rewired fixes this with its native plugins, thankfully, but it's one of the huge, glaring issues I discovered when I tried Unity's default input.
 

JulianImp

Member
Not to mention that Unity, by default (unless this has changed recently) does the whole "game triggers count as opposite ends of the same axis" thing.

Basically, both triggers end up mapped to the same axis (I'll call it TriggerAxis here), which really screws you up if you want to check for both triggers at the same time.
For example, if you were making an FPS with iron sights you'd run through something like this:
  1. To enable your "iron sights" mode you need to check for the left trigger for input.
  2. Now you need to shoot baddies, right? So you need to check your right trigger for input to decide whether you want to shoot or not. Here's where the problem lies.

Each trigger is the mirror-image of the other one on your TriggerAxis. For the sake of this explanation, your left trigger reads from 0 (not pulled) to -1 (fully pulled), while your right trigger reads from 0 (not pulled) to 1 (fully pulled).

If you have both triggers pulled at the same time, one of two things can happen. 1.) Unity completely ignores the second trigger pull, or 2.) Unity detects the second trigger pull, but because the triggers are mapped to -1 and 1 at this point they cancel each other out. The net effect is that either one trigger isn't detected or both triggers deactivate.

That's terrible, and really, really bad for games that make use of the triggers. If I remember correctly, Unity's implementation may not even have the triggers on a true axis, it may just read as a binary "pressed" or "not pressed", which means that you can't even check if a trigger is partially pulled or not.

Rewired fixes this with its native plugins, thankfully, but it's one of the huge, glaring issues I discovered when I tried Unity's default input.

Wow. It's really good to know that before I've ever had to run into that sort of problem, since it seems to be of the kind that'd have me bashing my head against a wall and debugging for hours only to realize the problem happened to be on Unity's end.

Seriously, Unity's input system is one of the things I wish they tweaked more. Not allowing you to change axes during execution is really annoying, since it's something most games that want customizable controls would have to do. For all the things Unity simplifies for developers and players, asking the latter to exit the game and set their controls up in the launcher is awfully clunky.
 
Not to mention that Unity, by default (unless this has changed recently) does the whole "game triggers count as opposite ends of the same axis" thing.

Basically, both triggers end up mapped to the same axis (I'll call it TriggerAxis here), which really screws you up if you want to check for both triggers at the same time.
For example, if you were making an FPS with iron sights you'd run through something like this:
  1. To enable your "iron sights" mode you need to check for the left trigger for input.
  2. Now you need to shoot baddies, right? So you need to check your right trigger for input to decide whether you want to shoot or not. Here's where the problem lies.

Each trigger is the mirror-image of the other one on your TriggerAxis. For the sake of this explanation, your left trigger reads from 0 (not pulled) to -1 (fully pulled), while your right trigger reads from 0 (not pulled) to 1 (fully pulled).

If you have both triggers pulled at the same time, one of two things can happen. 1.) Unity completely ignores the second trigger pull, or 2.) Unity detects the second trigger pull, but because the triggers are mapped to -1 and 1 at this point they cancel each other out. The net effect is that either one trigger isn't detected or both triggers deactivate.

That's terrible, and really, really bad for games that make use of the triggers. If I remember correctly, Unity's implementation may not even have the triggers on a true axis, it may just read as a binary "pressed" or "not pressed", which means that you can't even check if a trigger is partially pulled or not.

Rewired fixes this with its native plugins, thankfully, but it's one of the huge, glaring issues I discovered when I tried Unity's default input.

That's dependent on the controller type and if it uses xinput or generic to drive it.

360/x1 controllers operate on a -1-0 and 0-1 scale while every other controller I've tried operates both triggers independently of one another from -1 to 1 each on their own axis.

I wrote my own custom input manager and the only controllers i needed to make special cases for were for the 360 and Xbox One controllers (technically one exception since they are identical inputs). Everything else was assigned as it should be without needing some special magic.

I wrote it a long time ago but it still works the same in 5.x

I'm not sure how it works outside of Unity with UE or other tools as I have never tried it - but within Unity it seems to be controller-specific, leading me to believe its not Unity, it's xinput or some generic driver.

I should actually try a generic driver with my XO controller and see if it makes a difference, tbh. Haven't tried yet :O
 

EDarkness

Member
I have to recommend for people using Unity, if you haven't picked up an alternative Input manager for the engine you really should. I've been trying out the trial version of ReWired and it's caused the headache I had to make double-tapping work to literally just be a function I call when I need to.

Make, like, 70 lines of code into 2. Man it feels good.

I was having some trouble with getting controllers to work on PC (development system is a Mac), the damn d-pad on the 360 controller for PC is a crazy beast. So I switched to InControl and everything works now. It's awesome. Trying to add in Wii U controls now, but I'm happy. It cut out tons of code since calls can be broken down to one statement. It's awesome. I recommend checking this stuff out if you're using Unity.
 

Dynamite Shikoku

Congratulations, you really deserve it!
Not to mention that Unity, by default (unless this has changed recently) does the whole "game triggers count as opposite ends of the same axis" thing.

Basically, both triggers end up mapped to the same axis (I'll call it TriggerAxis here), which really screws you up if you want to check for both triggers at the same time.
For example, if you were making an FPS with iron sights you'd run through something like this:
  1. To enable your "iron sights" mode you need to check for the left trigger for input.
  2. Now you need to shoot baddies, right? So you need to check your right trigger for input to decide whether you want to shoot or not. Here's where the problem lies.

Each trigger is the mirror-image of the other one on your TriggerAxis. For the sake of this explanation, your left trigger reads from 0 (not pulled) to -1 (fully pulled), while your right trigger reads from 0 (not pulled) to 1 (fully pulled).

If you have both triggers pulled at the same time, one of two things can happen. 1.) Unity completely ignores the second trigger pull, or 2.) Unity detects the second trigger pull, but because the triggers are mapped to -1 and 1 at this point they cancel each other out. The net effect is that either one trigger isn't detected or both triggers deactivate.

That's terrible, and really, really bad for games that make use of the triggers. If I remember correctly, Unity's implementation may not even have the triggers on a true axis, it may just read as a binary "pressed" or "not pressed", which means that you can't even check if a trigger is partially pulled or not.

Rewired fixes this with its native plugins, thankfully, but it's one of the huge, glaring issues I discovered when I tried Unity's default input.

Wow. Thanks for that. Good to know.
 

Popstar

Member
I'm not sure how it works outside of Unity with UE or other tools as I have never tried it - but within Unity it seems to be controller-specific, leading me to believe its not Unity, it's xinput or some generic driver.
Yeah, it's the driver Microsoft ships for the Xbox controller that's the problem. Not Unity or any other software.

There's two main ways to get controller input on Windows. Generic USB HID and XInput.

XInput only works Xbox / Xbox-compatible controllers but you get proper triggers. HID works for pretty much anything, but the triggers are messed up on Xbox controllers. It's just Microsoft being jerks.
 
Wow. It's really good to know that before I've ever had to run into that sort of problem, since it seems to be of the kind that'd have me bashing my head against a wall and debugging for hours only to realize the problem happened to be on Unity's end.

Seriously, Unity's input system is one of the things I wish they tweaked more. Not allowing you to change axes during execution is really annoying, since it's something most games that want customizable controls would have to do. For all the things Unity simplifies for developers and players, asking the latter to exit the game and set their controls up in the launcher is awfully clunky.

I'd completely forgotten about that, but no runtime remapping is another aspect of default Unity input that's a first-class ticket to Frown Town.

That's dependent on the controller type and if it uses xinput or generic to drive it.

360/x1 controllers operate on a -1-0 and 0-1 scale while every other controller I've tried operates both triggers independently of one another from -1 to 1 each on their own axis.

I wrote my own custom input manager and the only controllers i needed to make special cases for were for the 360 and Xbox One controllers (technically one exception since they are identical inputs). Everything else was assigned as it should be without needing some special magic.

I seem to remember trying a PS3 controller as well and it giving me issues, but that was probably due to the driver.

Either way, the 360 pad is still very popular, so having messed up support for it is kind of...uh, really bad.

Wow. Thanks for that. Good to know.
No problem!
OvaUiN3m.jpg
 

Jobbs

Banned
Awesome webm! Can't wait for the release of your game (when are you gonna release it? next year?)

What software you guys use for gifs? I usually do webms but I don't have a good convertor for gifs =(

Great art!

To answer your question, I'm working hard to release it late this year, but it all depends on whether I can do it. I'm trying.

To answer your other question, I record gameplay with fraps then use gifcam to capture a gif from it. This lets me easily record exactly what I want and also size the whole image to whatever I want for the purposes of the gif.
 

Lork

Member
Not to mention that Unity, by default (unless this has changed recently) does the whole "game triggers count as opposite ends of the same axis" thing.

Basically, both triggers end up mapped to the same axis (I'll call it TriggerAxis here), which really screws you up if you want to check for both triggers at the same time.
For example, if you were making an FPS with iron sights you'd run through something like this:
  1. To enable your "iron sights" mode you need to check for the left trigger for input.
  2. Now you need to shoot baddies, right? So you need to check your right trigger for input to decide whether you want to shoot or not. Here's where the problem lies.

Each trigger is the mirror-image of the other one on your TriggerAxis. For the sake of this explanation, your left trigger reads from 0 (not pulled) to -1 (fully pulled), while your right trigger reads from 0 (not pulled) to 1 (fully pulled).

If you have both triggers pulled at the same time, one of two things can happen. 1.) Unity completely ignores the second trigger pull, or 2.) Unity detects the second trigger pull, but because the triggers are mapped to -1 and 1 at this point they cancel each other out. The net effect is that either one trigger isn't detected or both triggers deactivate.

That's terrible, and really, really bad for games that make use of the triggers. If I remember correctly, Unity's implementation may not even have the triggers on a true axis, it may just read as a binary "pressed" or "not pressed", which means that you can't even check if a trigger is partially pulled or not.

Rewired fixes this with its native plugins, thankfully, but it's one of the huge, glaring issues I discovered when I tried Unity's default input.
While that may have been the case at some point in the past, if you load up Unity today with the default input manager, it sees the triggers on a 360 controller as separate axes (the 9th and 10th ones, specifically) and has no trouble distinguishing between them.
 
Yep. ^^^ I just checked and apparently I refactored my input at some point.

I'd completely forgotten about that, but no runtime remapping is another aspect of default Unity input that's a first-class ticket to Frown Town.



I seem to remember trying a PS3 controller as well and it giving me issues, but that was probably due to the driver.

Either way, the 360 pad is still very popular, so having messed up support for it is kind of...uh, really bad.


No problem!
OvaUiN3m.jpg
Ehhhh - Unity leaves a lot open to the developer and for good reason. There are a myriad of ways to do the things you are looking for that don't take much effort to build. I personally would not want to have any of that as a permanent solution. Maybe it's OK to test - similar to rigging and testing new objects using Rigidbodies which I do frequently before applying my own physics as a final solution.

Many solutions to the same problem and having YOU be the one to create those solutions leaves a LOT more wiggle room than dedicated systems. This goes for any tool.
 
Oops. So I made this skill that applies three stacks of "Shield Block Up" to a target. The status condition increases block rate to 100% and doubles the strength of a block. The status calls an onBlock() method, which removes the condition from the target. The intent was that an actor could block twice as well for the next three blocks. However, that block rate/value increase was applied for each condition, so it was doubling it three times, such that the first block absorbed 24 damage, the second 12, the third 6, and then returned to normal. It was also increasing block rate by 300 and not 100--though that's less important because because anything over 100 has no practical effectiveness. Still, it's a lesson that I can't use stacks for that, and have made the skill apply a single stack of "Block Up" that contains 3 charges before it removes itself.
 
I got him hopping around. There was temptation to do it lazily, but I hooked up the animation frames so he's actually jumping so it'll look good even if the ground isn't flat.

http://www.gfycat.com/SickEverlastingGalapagoshawk

I'm now thinking I'll make the particle effect increase as he takes damage.

I'm not entirely sure what the physiology of the particles coming off is, but I like the amount of particles you're spawning right now. The first one you showed was way over the top.

Though, if you want it to be more dynamic, maybe spawn a cluster around shot impacts, and have it shed more while it's moving fast/flying through the air. Maybe that doesn't make sense with the physiology though — before, when you were painting it, I thought it was a sort of stone creature.
 

Jobbs

Banned
I'm not entirely sure what the physiology of the particles coming off is, but I like the amount of particles you're spawning right now. The first one you showed was way over the top.

Though, if you want it to be more dynamic, maybe spawn a cluster around shot impacts, and have it shed more while it's moving fast/flying through the air. Maybe that doesn't make sense with the physiology though — before, when you were painting it, I thought it was a sort of stone creature.

The idea is that it's more like a crusty growth -- perhaps some form of fungus -- And it's kind of "living", it regenerates -- the particles are intended to look sort of like.. flakes flaking off, I guess.
 

Jobbs

Banned
The way I had it, any enemies of this "fungal" type would not stay dead unless you killed them with an active "gas" effect on your weapon, which is inhaled from a certain plant thingy.

I was experimenting around and decided it might make for more possibilities if the gas also came from downed enemies before/as they regenerate.

http://www.gfycat.com/ScalyEarlyAuklet

So, in other words, kill it with conventional weapons, get gas from it, then kill it (or kill other things) with the gas.
 
The way I had it, any enemies of this "fungal" type would not stay dead unless you killed them with an active "gas" effect on your weapon, which is inhaled from a certain plant thingy.

I was experimenting around and decided it might make for more possibilities if the gas also came from downed enemies before/as they regenerate.

http://www.gfycat.com/ScalyEarlyAuklet

So, in other words, kill it with conventional weapons, get gas from it, then kill it (or kill other things) with the gas.

How about the gas regenerates the baddie, but if you get rid of the gas then it dies. Additionally, the gas that you vacuum away is useful against other enemies.
 
Ive been struggling to choose an artstyle for my game, i have a pretty good collection of art but nothing that really gels for everything i need.

Probably spent wayyy too much on unused assets. Last week i was trying out voxels (which i shall use for something .....) but this week i am trying something more abstract and colorful.

oVRpXMI.gif
 

_machine

Member
Does machine still post ITT?
I'm here!

Been super busy these few weeks and we have a few visible errors in the game and the menus so I haven't gotten around showing that much stuff lately, just lurking daily. Bit of a tease since I don't have much to show yet, but we have just started on working on a whole different level environment, which is a sort of a desert environment that mixes mayan and egyptian mythologies. I'll be back with some concept art tomorrow though :)
 

WanderingWind

Mecklemore Is My Favorite Wrapper
I'm here!

Been super busy these few weeks and we have a few visible errors in the game and the menus so I haven't gotten around showing that much stuff lately, just lurking daily. Bit of a tease since I don't have much to show yet, but we have just started on working on a whole different level environment, which is a sort of a desert environment that mixes mayan and egyptian mythologies. I'll be back with some concept art tomorrow though :)

Sweet. I'll check the thread tomorrow. And you know, feel free to PM when you're ready for some coverage.
 

_machine

Member
Sweet. I'll check the thread tomorrow. And you know, feel free to PM when you're ready for some coverage.
Thanks, though it'll still be a while since we decided that game should get some additional polish and will be releasing probably after August. Should be worth the wait though :)

Aside from doing some personal work this weekend, I've always been getting my hands dirty again, this time with UMG and updating pretty much all of our gameplay UI. I both love and hate the tools; they are very powerful and I was pretty quickly able to add a little feature to the UI with a bit of help from one of the programmers, but at the same time it provides little tools to help with getting each element just in the right place, aligning and scaling them together etc. Luckily it's priority for Epic too and we should be seeing some notable workflow improvements.

To give a bit of a teaser, here's a wip shot inside the engine:
Not that much to see there, but I think it's a massive improvement over the previous designs. It has taken us multiple different designs and polish passes to get here though, but for me it's more than worth it.
 
The way I had it, any enemies of this "fungal" type would not stay dead unless you killed them with an active "gas" effect on your weapon, which is inhaled from a certain plant thingy.

I was experimenting around and decided it might make for more possibilities if the gas also came from downed enemies before/as they regenerate.

http://www.gfycat.com/ScalyEarlyAuklet

So, in other words, kill it with conventional weapons, get gas from it, then kill it (or kill other things) with the gas.
This is a nice gameplay element. Will it only be particular to these enemies or will there be more that use this or similar mechanics?
 

WanderingWind

Mecklemore Is My Favorite Wrapper
Thanks, though it'll still be a while since we decided that game should get some additional polish and will be releasing probably after August. Should be worth the wait though :)

Aside from doing some personal work this weekend, I've always been getting my hands dirty again, this time with UMG and updating pretty much all of our gameplay UI. I both love and hate the tools; they are very powerful and I was pretty quickly able to add a little feature to the UI with a bit of help from one of the programmers, but at the same time it provides little tools to help with getting each element just in the right place, aligning and scaling them together etc. Luckily it's priority for Epic too and we should be seeing some notable workflow improvements.

To give a bit of a teaser, here's a wip shot inside the engine:

Not that much to see there, but I think it's a massive improvement over the previous designs. It has taken us multiple different designs and polish passes to get here though, but for me it's more than worth it.

I'd love to see a larger shot of the bottom left UI element, if you're so inclined during tomorrow's screen dump. The icons look vastly different than last time I saw them.
 
Not entirely sure how useful this will be except for absolute beginners at Unity, because I sort of expect everyone here working on games already has their own equivalent version of this because it's just that damn useful, but anyway;

This is a generic-ass "game manager" script that you can stick on a gameobject to keep it always there across levels and access its functions from any script. If you're doing the Unity Tutorials, this should be fine to drop into any of them if you're expanding them.

entire code snippet: replace _____ with your scriptname.
I'm using block commenting in addition to forum tags, so you should be able to c+p directly into a script without problems.

Code:
using UnityEngine;
using System.Collections;
/*
add any other libraries relevant to what you want this manager doing here - for example a UI Manager would probably want UnityEngine.UI. An achievements manager porbably want UnityEngine.SocialPlatforms. etc 
*/
/*
As above - make these _____ match your script filename or Unity will throw up errors.
*/
public class _____: MonoBehaviour
{
    private static _____manager = null;
    public static _____Manager
    {
        get { return manager; }
    }

    void Awake()
    {
        GetThisManager();
    }
/*
This is a singleton design pattern, so on script awake we need to make sure there are no other instances of this object
*/
    void GetThisManager()
    {
/*
This checks; if there is already a manager of this type (if not null) and if it isn't this one. If that's the case, delete this object.
*/
        if (manager != null && manager != this)
        {
            Destroy(this.gameObject);
            return;
        }
/*
Otherwise, make this object the manager
*/
        else
        {
            manager = this;
        }
        DontDestroyOnLoad(this.gameObject);
    }
}

The benefit of this script is that you can access it - and therefore any methods, functions or data stored within it - from any other script by calling [scriptname].Manager

Okay, so whats the point of this?

Well, let's use a simple real world example - a Highscore manager that will show a players current score, their highest score, will persist with the same values across levels, and will automatically load those values on game start and save them on game end.

Code:
using UnityEngine;
using UnityEngine.UI;
using System.Collections;

public class Score: MonoBehaviour
{
    private static Score manager = null;
    public static Score Manager
    {
        get { return manager; }
    }
    public Text scoreText;
    public int currentScore;
    public int highScore;

Above, I've added Unitys UI functions, named the class and filename Score (for ease of use) and created some new variables to track score - the Unity UI Text object I want to update (just add a UI Text component to your scene, and drag and drop its reference onto this field) the players current score and the players highest score.

I'll add some new methods to the Score script as well; I want a Start() method to load data, and some generic methods for updating my score and saving my score.

Code:
    void Start()
    {
        // call a Load method on start
        Load();
    }

    // Made a seperate method so we can call it from other places if needed
    void Load()
    {
        highScore = PlayerPrefs.GetInt("highScore");
    }

    // Again, seperate for use elsewhere
    void Save()
    {
        PlayerPrefs.SetInt ("highScore",highScore);
    }

    // add whatever int sent here to current score, update highscore if necessary
    void Add (int change)
    {
        currentScore += change;
        if (currentScore>highScore)
        {
            highScore = currentScore;
        }
        // if I've called this, I should probably update the UI
        UpdateUI();
    }

    // This UI component only needs updating when the score does, so this is its own method rather than OnGui()
    void UpdateUI()
    {
        scoreText.text = "Current: "+currentScore+"\n"+"Highest: "+highScore;
    }

So with a Score.cs script attached to a gameobject in the scene, I can update the players score by putting
Code:
Score.Manager.Add(#####);
anywhere I want to add to a players score - like a pickup script for a coin, or the deathscript for an enemy, replacing ##### with the amount of score I want to add.

As I don't need to continously write score to the players savegame, I can call
Code:
Score.Manager.Save();
anywhere that's convenient - like at the start of a level change, or on a gameover screen.
 

mooooose

Member
^^^ I was literally doing this to add high scores to the shooter tutorial last night, and had to figure it out on my own. I'm sure a lot of beginners will benefit!
 
So let me tell you a story that I'm sure we all know quite well:

Me: "Oh hey everything works."
Code: "That's awesome."
Me: "Except this one thing. It's a real easy fix, though."
Code: "Great!"
Me: "I know exactly what numbers to change, and I can see on the same page what they correspond to, so I know exactly what I will be changing, and how it will affect the game."
Code: "WHAT THE FUCK ARE YOU DOING????"
Me: "I'm just - "
Code: "WHO AUTHORIZED YOU DO THIS??? WHAT MAKES YOU THINK YOU CAN DO THAT?!?! OMG OMG OMG WHAT THE FUCK, MAN?"
Me: "Holy fuck, dude. Chill the hell out. Okay, look. I'm pressing undo."
Code: "AND WHAT DO YOU THINK THAT WILL POSSIBLY ACCOMPLISH?"
Me: "... uh... undo the bad code I apparently just did? Look, I put everything back the way it was before."
Code: "DON'T TALK ME. YOUR GAME IS FUCKING BROKEN NOW."
Me: "But all I did was change one numerical value. Which I already put back the way it was before all of this."
Code: "NO."
Me: "... I'm trying to fix this. I don't know what you want, since I put everything back literally where it was before."
Code: "NO."
Me: "Okay. How about if I copy the same code from an earlier build and I paste it - "
Code: "NO."
Me: *starts over with a new file, spends the morning importing all the code from the previous build*
 
So let me tell you a story that I'm sure we all know quite well:

Me: "Oh hey everything works."
Code: "That's awesome."
Me: "Except this one thing. It's a real easy fix, though."
Code: "Great!"
Me: "I know exactly what numbers to change, and I can see on the same page what they correspond to, so I know exactly what I will be changing, and how it will affect the game."
Code: "WHAT THE FUCK ARE YOU DOING????"
Me: "I'm just - "
Code: "WHO AUTHORIZED YOU DO THIS??? WHAT MAKES YOU THINK YOU CAN DO THAT?!?! OMG OMG OMG WHAT THE FUCK, MAN?"
Me: "Holy fuck, dude. Chill the hell out. Okay, look. I'm pressing undo."
Code: "AND WHAT DO YOU THINK THAT WILL POSSIBLY ACCOMPLISH?"
Me: "... uh... undo the bad code I apparently just did? Look, I put everything back the way it was before."
Code: "DON'T TALK ME. YOUR GAME IS FUCKING BROKEN NOW."
Me: "But all I did was change one numerical value. Which I already put back the way it was before all of this."
Code: "NO."
Me: "... I'm trying to fix this. I don't know what you want, since I put everything back literally where it was before."
Code: "NO."
Me: "Okay. How about if I copy the same code from an earlier build and I paste it - "
Code: "NO."
Me: *starts over with a new file, spends the morning importing all the code from the previous build*

Two words: source control. :)
 
This is a generic-ass "game manager" script that you can stick on a gameobject to keep it always there across levels and access its functions from any script. If you're doing the Unity Tutorials, this should be fine to drop into any of them if you're expanding them.

Good stuff. This is something everyone will run into at some point, and then you'll have to figure out whether to use the Singleton pattern or try abusing PlayerPrefs or whatever. So good job on posting this.
 

Jumplion

Member
I've been using Perforce for source control with the current project I'm working on. Not the most user friendly UI or implementation, but it works and is fairly powerful from what I can tell.
 
Status
Not open for further replies.
Top Bottom