Support NeoGAF

[liliththepale]

I think the issue I'm having is that in my head, I think there must be some kind of "mechanical" way of looking at this. Eg, I pick a shade of green, and then by following some kind of formula I can get appropriate other colors to use for shading In reality though it doesn't seem like that at all.

That's probably my programmer side coming out..

That said, are there any kinds of "rule of thumb" to go by? Like, is increasing the hue more in-line with highlights and decreasing it more in-line with shadows? I just end up feeling a bit lost because I can't envisage how two colors fit together when It's just two cubes. I kinda have to draw out the whole thing and then decide whether it looks good or not, but I know that definitely isn't the right approach.

I feel uncomfortable ascribing a mechanical process to art, but it's definitely true that in general you'll do cooler colors for shadows and warmer colors for highlights. So a little more blue, green or purple as it gets darker and less light/warmth is hitting it, and a little more red or yellow as more light and warmth is hitting it.

This of course is assuming the sun or a similar warm light as the primary source of light. Really what you're going for most is temperature description and contrast. So for example a light source like the moon wouldn't give a huge temperature differential, and also it would cast a cool blue light, so you might try bluer highlights and redder shadows.

All that said, please don't expect results overnight. Even if I could perfectly describe how to draw amazing it would still take you lots and lots of practice. But it's worth it!

 

[HandsomeCharles]

I feel uncomfortable ascribing a mechanical process to art, but it's definitely true that in general you'll do cooler colors for shadows and warmer colors for highlights. So a little more blue, green or purple as it gets darker and less light/warmth is hitting it, and a little more red or yellow as more light and warmth is hitting it.

This of course is assuming the sun or a similar warm light as the primary source of light. Really what you're going for most is temperature description and contrast. So for example a light source like the moon wouldn't give a huge temperature differential, and also it would cast a cool blue light, so you might try bluer highlights and redder shadows.

All that said, please don't expect results overnight. Even if I could perfectly describe how to draw amazing it would still take you lots and lots of practice. But it's worth it!

Haha, don't worry, I wasn't expecting some kind of miraculous turnaround after discovering the "hidden secret"! Im fine with this taking a while, this is a passion project and I want to get it done right Guess I've just got to keep experimenting until something clicks.

 

[Jacksinthe]

Just finished that article over some coffee. It was an eye opener for sure, especially the 3DO stuff. A lot of what was said about the industry is true, though. The race to the bottom, the press, the AAA side, etc.

Thanks for posting it up.

 

[Jumplion]

I think the issue I'm having is that in my head, I think there must be some kind of "mechanical" way of looking at this. Eg, I pick a shade of green, and then by following some kind of formula I can get appropriate other colors to use for shading In reality though it doesn't seem like that at all.

That's probably my programmer side coming out..

That said, are there any kinds of "rule of thumb" to go by? Like, is increasing the hue more in-line with highlights and decreasing it more in-line with shadows? I just end up feeling a bit lost because I can't envisage how two colors fit together when It's just two cubes. I kinda have to draw out the whole thing and then decide whether it looks good or not, but I know that definitely isn't the right approach.



I can't remember what the limits are for the Google play Store right now, but I think it's 100MB.

What this means is that if your app is larger than 100meg, users will have to connect to WiFi in order to download it. This can be a kiss of death for some apps. Mobile users are incredibly fickle. If they see something that looks appealing in the app store and go "Oh, I'll install that!", but then get a message saying that they need to be on WiFi, the vast, vast majority of them won't even bother.

Whilst still a huge issue, it is slightly less if your app is paid for, as if someone has paid money, chances are they are going to want to actually get something for it and will download it again later. Still, getting under 100MB is an absolute must.

This is why many games utilise DLC methods of getting additional assets after the initial install, simply so they can get the footfall from that first app-store glance. A user is way more likely to stick around for the DLC download if they've already installed.

But to put it into perspective, at work we have a fairly popular F2P mobile game, and each update we do we spend a lot of time trimming assets, compressing things where possible etc. to ensure that we hit that 100MB mark.

Oh, and just as a work of warning, aim for about 85MB, as for whatever reason the process of adding your app to a store will increase the bundle size by a random value that sometimes goes up to 10MB!

I should be good with my game, most of it being simple shapes, and as far as I've been able to test there have been no memory leaks, but I'll keep that in mind. Thanks!

(on the art stuff, you and me both brutha. For what it's worth, I've found analogous colors to be nice to look at for my game, that kind of colorscheme my help for some of your game)

 

[HP_Wuvcraft]

Any of you running Linux machines? Yes, this is my weekly call for help.

 

[Bollocks]

You know what would be cool?
A multiplayer survival game that uses geolocation and real heightmap data of the earth.
As you advance your tribe you get access to boats and one day players will be able to cross from Europe to America to see each other only after serveral people died because they didn't stock the right thing to make the journey.

So where do I get this heightmap data

 

[timetokill]

You know what would be cool?
A multiplayer survival game that uses geolocation and real heightmap data of the earth.
As you advance your tribe you get access to boats and one day players will be able to cross from Europe to America to see each other only after serveral people died because they didn't stock the right thing to make the journey.

So where do I get this heightmap data

There's a good chance you can get it from NASA if you search their site.

 

[Popstar]

You know what would be cool?
A multiplayer survival game that uses geolocation and real heightmap data of the earth.
As you advance your tribe you get access to boats and one day players will be able to cross from Europe to America to see each other only after serveral people died because they didn't stock the right thing to make the journey.

So where do I get this heightmap data

Virtual Terrain Project

 

[xir]

Are there Unity freelance cowboys? A place to find them? There's something I want to prototype, and am willing to pay. Super light modeling, grayboxing, too

 

[TheHollowNight]

So... this is kind of a really long read (it took me about an hour), but it's really interesting. It's a candid interview with Rebecca Heineman (who's been in the industry for 30+ years) about the harsh realities of game development both AAA and indie. Of particular interest is a sobering discussion regarding the theoretical limit of indie game marketshare and the ensuing race to the bottom, but really the whole thing is worth reading.

http://www.nodontdie.com/rebecca-heineman/

Thanks to Pehesse for linking to it on Twitter last night!

All the don't die interviews are fantastic, especially this one!
Disclaimer: I'm a little biased since I was featured in one a while back

 

[liliththepale]

All the don't die interviews are fantastic, especially this one!
Disclaimer: I'm a little biased since I was featured in one a while back

I feel kinda bad since scrolling through the next six or seven pages the only name I recognized was Peter Molyneux. I think it might help new audiences if there was a blurb next to the interviewee names. (I'm assuming the primary/Patreon audience reads them all regardless)

Which one is yours?

 

[timetokill]

So... this is kind of a really long read (it took me about an hour), but it's really interesting. It's a candid interview with Rebecca Heineman (who's been in the industry for 30+ years) about the harsh realities of game development both AAA and indie. Of particular interest is a sobering discussion regarding the theoretical limit of indie game marketshare and the ensuing race to the bottom, but really the whole thing is worth reading.

http://www.nodontdie.com/rebecca-heineman/

Thanks to Pehesse for linking to it on Twitter last night!

Great read, thanks for the link!

 

[HP_Wuvcraft]

So... this is kind of a really long read (it took me about an hour), but it's really interesting. It's a candid interview with Rebecca Heineman (who's been in the industry for 30+ years) about the harsh realities of game development both AAA and indie. Of particular interest is a sobering discussion regarding the theoretical limit of indie game marketshare and the ensuing race to the bottom, but really the whole thing is worth reading.

http://www.nodontdie.com/rebecca-heineman/

Thanks to Pehesse for linking to it on Twitter last night!

This is really quite excellent.

I like that they hit on Kickstarter, too.

 

[Cute Dragon Here]

You know, I'm not to sure about your start/stop issue. All the games I've worked on previously have either used physics pretty standard, or haven't used physics at all. What I would be tempted to try (in your case) would be sticking with Box2D, but set the drag on your rigidbodies to be really high. This should mean that when you stop applying force, it should come to rest almost instantaneously. (Note: You may have to do some stuff in your player script that sets the drag to zero whilst force is being applied, and then changes it back as soon as you stop applying force, otherwise you may find that you can't even get the damn thing to move!)

Another rule of thumb is when working within a physics environment, never set the XYZ of a rigidbody manually for the purposes of "movement". I.e, if you need something to "teleport" to a new location, it's fine, but if you just want to move your character "left", you should be doing it with forces. Setting XYZ can result in wild and unpredictable physics issues!

As for your manager, you should attach your manager script to a blank gameobect in your scene. You can prefab it if you want, but seeing as it shouldn't really ever be destroyed (Until the game exits) it may not be necessary.

As for your camera and UI being prefabs, I'm afraid I couldn't say. If you're going to need to reuse them often in different scenes, and don't want to have to set everything up manually each time, then yes. Make them prefabs. Otherwise, you probably don't need to. Unfortunately this is going to change on a per-project basis, so I couldn't give you a straight answer

Hmm, I guess I probably should put it off for now. I mean, the movement's satisfactory as it is right now, though it'd be nice if I could have it set up so that moving around at full tilt meant a rate of about exactly 2 units per second instead of having vague units. Guess that'll have to wait until I fix the important parts first, though.

For your manager class, on player instantiate have it update the manager to let it know it exists. You don't need the manager to look for the player (I try to avoid subscriptions whenever possible).

Example: at player instantiate I let it know I'm alive, what my GameObject is, several other initialized variables. Only when my health gets updated do I update the logic, same with position and anything else. I keep frame updates to a minimum and my logic always receives data, it never looks for it. Otherwise I'd be running

if (!exist)
//look for whatever

And I don't want to subscribe to something every frame.

All right. Player instantiate, let it know I'm alive... wait, who's telling who, the Player prefab/script, or the manager?

Hmm, I noticed that my PlayerScript appears to want the UI canvas' script when it starts in the "drag it into itself" way. Guess I'll have to rework the player script... should I have input handled in the script, or should I create a separate GameObject + script for input? (The UI doesn't really handle input in my project. It only has functions to update its contents and toggle display of windows. Perhaps I should change that?)

Just to recap, the PlayerScript as it is right now contains the player data, amount of steps to the next encounter, movement vector, last known input positions for animation use, and private animator and rigidbody components that are GetComponent<>()'d at start. The script is attached to a Player object/prefab that has the necessary Unity components, and will initialize missing values on start.

It's just the public "Dragged and dropped" UI script that is bothering me at this point. Like, well, if I move the input portion elsewhere, perhaps I should move that out, too.

And, perhaps, I should edit the save/load functions to make them reside on the PlayerManager?

(Sometimes I think I'm just bad at Unity. )

And, sorry for all the post-editing, but I'd also like to ask if it's OK to have the PlayerManager script to have two additional public variables storing the default X and Y positions for the player on a direct load?

 

[Jacksinthe]

Hmm, I guess I probably should put it off for now. I mean, the movement's satisfactory as it is right now, though it'd be nice if I could have it set up so that moving around at full tilt meant a rate of about exactly 2 units per second instead of having vague units. Guess that'll have to wait until I fix the important parts first, though.



All right.

Hmm, I noticed that my PlayerScript appears to want the UI canvas' script when it starts in the "drag it into itself" way. Guess I'll have to rework the player script... should I have input handled in the script, or should I create a separate GameObject + script for input? (The UI doesn't really handle input in my project. It only has functions to update its contents and toggle display of windows. Perhaps I should change that?)

Just to recap, the PlayerScript as it is right now contains the player data, amount of steps to the next encounter, movement vector, last known input positions for animation use, and private animator and rigidbody components that are GetComponent<>()'d at start. The script is attached to a Player object/prefab that has the necessary Unity components, and will initialize missing values on start.

It's just the public "Dragged and dropped" UI script that is bothering me at this point. Like, well, if I move the input portion elsewhere, perhaps I should move that out, too.

And, perhaps, I should edit the save/load functions to make them reside on the PlayerManager?

(Sometimes I think I'm just bad at Unity. )

I handle all of my inputs with their own class so I can use them across the entire project. I wrote my own libraries for custom keybinds, etc. You don't have to go that far but for input I always read the class before anything that requires it by using script execution order in project settings.

I set 2 bools for each key, down and held. Down obviously only returns true in the frame it was pressed and no subsequent frames until it is released and pressed again. Held bool always returns true every frame. I use this to count how long a player holds a button or key in case I ever need to use that.

Now I have a single class to handle inputs game-wide, depending on context - unpaused (player control), paused, menu navigation, etc.

My UI stuff is handled on its own. Info that it needs is always passed to it and only updated if it receives info.

Everything in every scene is compartmentalized to the point I can remove or add any object and nothing breaks, including the player. Saving is also compartmentalized. Nothing is dependent on anything else existing in any scene.

Doing this I have default scenes ready to go for levels, cinematics, the world map, etc. I can also modify any existing controller (camera, save, logic, effects, etc) and just apply the changes to their prefabs so they take effect game-wide without breaking anything unless I completely remove a function or change naming, in which case it would be replaced or other scripts modified to reflect any changes.

There's a lot of middlemen stuff to ensure it all works properly and the huge drawback is that you sometimes won't know if you broke something until you debug. Keep a road map tho. With everything existing in a vacuum it can be difficult to trace when shit hits the fan and you're not getting errors.

 

[Cute Dragon Here]

I handle all of my inputs with their own class so I can use them across the entire project. I wrote my own libraries for custom keybinds, etc. You don't have to go that far but for input I always read the class before anything that requires it by using script execution order in project settings.

I set 2 bools for each key, down and held. Down obviously only returns true in the frame it was pressed and no subsequent frames until it is released and pressed again. Held bool always returns true every frame. I use this to count how long a player holds a button or key in case I ever need to use that.

Now I have a single class to handle inputs game-wide, depending on context - unpaused (player control), paused, menu navigation, etc.

My UI stuff is handled on its own. Info that it needs is always passed to it and only updated if it receives info.

Everything in every scene is compartmentalized to the point I can remove or add any object and nothing breaks, including the player. Saving is also compartmentalized. Nothing is dependent on anything else existing in any scene.

Doing this I have default scenes ready to go for levels, cinematics, the world map, etc. I can also modify any existing controller (camera, save, logic, effects, etc) and just apply the changes to their prefabs so they take effect game-wide without breaking anything unless I completely remove a function or change naming, in which case it would be replaced or other scripts modified to reflect any changes.

There's a lot of middlemen stuff to ensure it all works properly and the huge drawback is that you sometimes won't know if you broke something until you debug. Keep a road map tho. With everything existing in a vacuum it can be difficult to trace when shit hits the fan and you're not getting errors.

Hmm... I guess I should start considering having a camera, save, UI, and input manager at this point if the project is of any indication, but for now, I have to implement the player manager first.

Was wondering about this, though: I probably should leave the player data within the player script itself instead of the player manager, or should I make the player script strictly function-only?

Either way, now that I'm instantiating player prefabs, now all the other code has their links broken. Time to make their scripts manager-y and/or "find the prefab"-ey. Good plan?

 

[Jacksinthe]

Hmm... I guess I should start considering having a camera, save, UI, and input manager at this point if the project is of any indication, but for now, I have to implement the player manager first.

Was wondering about this, though: I probably should leave the player data within the player script itself instead of the player manager, or should I make the player script strictly function-only?

Depends on how you want to set it up. I have 14+ scripts controlling my player. Weapon managers, health manager, collision, physics, casts, wallstick, animations, etc. I don't like a single player class handling everything. I have one main controller class for the player and it is tied to most of the rest. I do this simply because it would be too hard to debug if it was all in a single class. God classes have their use but I fucking hate them.

Edit: as for finding the player instantiated prefab, point them to your global manager, you don't need them to look for the player if your player lets the game manager know it exists on instantiation. Then your objects just need to look at GameManager.PlayerObject and not search through all objects in scene by tag or name. You just have the objects grab where it already knows to look.

 

[Cute Dragon Here]

Depends on how you want to set it up. I have 14+ scripts controlling my player. Weapon managers, health manager, collision, physics, casts, wallstick, animations, etc. I don't like a single player class handling everything. I have one main controller class for the player and it is tied to most of the rest. I do this simply because it would be too hard to debug if it was all in a single class. God classes have their use but I fucking hate them.

Edit: as for finding the player instantiated prefab, point them to your global manager, you don't need them to look for the player if your player lets the game manager know it exists on instantiation. Then your objects just need to look at GameManager.PlayerObject and not search through all objects in scene by tag or name. You just have the objects grab where it already knows to look.

Yeah, thinking of having a plan with the classes so that each class does its own things for the most part, with their functions invoked with public functions... going to guess they must be static or something? (Technically speaking, I have no camera code, saving code is part of the player script right now, no sound code, and separated UI code)

It's time for me to apply newly acquired knowledge. I'll check back in if I run into any issues. Wish me luck...

 

[Jacksinthe]

Yeah, thinking of having a plan with the classes so that each class does its own things for the most part, with their functions invoked with public functions... going to guess they must be static or something? (Technically speaking, I have no camera code, saving code is part of the player script right now, no sound code, and separated UI code)

It's time for me to apply newly acquired knowledge. I'll check back in if I run into any issues. Wish me luck...

My GameLogic class only handles a few statics. It acts as a session manager based on launching or continuing a game from the menu. Objects in scene don't do anything unless they need to and any routines for AI on enemies are broken into idle/combat states. The combat state only checks if the player is alive at their designated polling rate so it knows if it needs to go back to idle or perform some kind of a gloat if the player dies. From there, they can be reactivated when engaging with the player again.

 

[Cute Dragon Here]

My GameLogic class only handles a few statics. It acts as a session manager based on launching or continuing a game from the menu. Objects in scene don't do anything unless they need to and any routines for AI on enemies are broken into idle/combat states. The combat state only checks if the player is alive at their designated polling rate so it knows if it needs to go back to idle or perform some kind of a gloat if the player dies. From there, they can be reactivated when engaging with the player again.

All right.

Just one more thing... so I have something like this going on in my PlayerManager script:

using UnityEngine;
using System.Collections;

public class PlayerManager : MonoBehaviour {
    private static PlayerManager manager = null;
    public Transform player;
    
    public int defaultX = 0;
    public int defaultY = 0;
    public static PlayerManager Manager
    {
        get { return manager; }
    }

	void Awake()
    {
        GetThisManager();
    }

    void GetThisManager()
    {
        if (manager != null && manager != this)
        {
            Destroy(this.gameObject);
            return;
        }
        else
        {
            manager = this;

            Vector3 position = new Vector3(defaultX, defaultY, 0);
            Instantiate(player, position, Quaternion.identity);
        }
        DontDestroyOnLoad(this.gameObject);
    }
}

As it is, nothing outside can actually access the actual player prefab and all the things duct-taped to it. Hmm... should I make the Transform player thing also static? (And what about access to the scripting portion of the player prefab?)

(I guess I am doing badly )

 

[Lautaro]

Any of you running Linux machines? Yes, this is my weekly call for help.

This forum helped me with the Linux testing: https://www.gamingonlinux.com/forum/

 

[Turfster]

I guess it's still screenshot saturday somewhere, right?
Barebones import of Doom3's intro map in UE4 with HammUEr.

 

[Cute Dragon Here]

Right now I'm stuck resolving all the NullReference exceptions throwing out everywhere as I fix the broken links all over by making the scripts rely on the manager instead. This might take a while, as I do things a bit slow.

I guess game dev is hard work.

(Hmm, anyone has found a pixel font that is based on either a 8px or 16px height and variable width?)

Just to be sure... can you access scripts tied to a prefab stuffed in a Manager?

 

[LordRaptor]

I think the issue I'm having is that in my head, I think there must be some kind of "mechanical" way of looking at this. Eg, I pick a shade of green, and then by following some kind of formula I can get appropriate other colors to use for shading In reality though it doesn't seem like that at all.

Have you looked at Adobes colour wheel?
It will automatically pick contrasting / complimentary / shades of any particular 'input' colour, and by default (not messing with the sliders too much) does so from a hidden ruleset

As it is, nothing outside can actually access the actual player prefab and all the things duct-taped to it. Hmm... should I make the Transform player thing also static? (And what about access to the scripting portion of the player prefab?)

If I'm following your code correctly, then if you make "Player" a Gameobject instead of a Transform in that script, then explicity set it in your instantiation, you'd be able to access it from other scripts, eg

// in your other var declarations
Gameobject myPlayer;

// in your onload
myPlayer = (gameobject)instantiate (player, position, Quaternion.identity);

then you'd be able to gain access to it from other scripts using

Playermanager.myPlayer

getting reference to other scripts attached to it would be as simple as
Playermanager.myPlayer.getcomponent<scriptname>();
or getting its transform would just be
Playermanager.myPlayer.transform

I find storing gameobject references more useful in general than transforms, unless a transform is the only thing I need to reference on the object
e:
As a personal preference, I would also move your instantiate code into a new method, because "Get this manager" and "spawn a player object" are two seperate things, and long term you're asking for trouble trying to find where a player is spawned by putting it somewhere else - just make a

Void SpawnPlayerObject()
{
     myPlayer = (gameobject)instantiate (player, position, Quaternion.identity);
}

and call SpawnPlayerObject() in that block instead

e2:
And if you already know what components are going to be on that object, you can set those references up in the instantiate block as static references too

 

[Cute Dragon Here]

If I'm following your code correctly, then if you make "Player" a Gameobject instead of a Transform in that script, then explicity set it in your instantiation, you'd be able to access it from other scripts, eg

// in your other var declarations
Gameobject myPlayer;

// in your onload
myPlayer = (gameobject)instantiate (player, position, Quaternion.identity);

then you'd be able to gain access to it from other scripts using

Playermanager.myPlayer

getting reference to other scripts attached to it would be as simple as
Playermanager.myPlayer.getcomponent<scriptname>();
or getting its transform would just be
Playermanager.myPlayer.transform

I find storing gameobject references more useful in general than transforms, unless a transform is the only thing I need to reference on the object
e:
As a personal preference, I would also move your instantiate code into a new method, because "Get this manager" and "spawn a player object" are two seperate things, and long term you're asking for trouble trying to find where a player is spawned by putting it somewhere else - just make a

Void SpawnPlayerObject()
{
     myPlayer = (gameobject)instantiate (player, position, Quaternion.identity);
}

and call SpawnPlayerObject() in that block instead

e2:
And if you already know what components are going to be on that object, you can set those references up in the instantiate block as static references too

Got it! I actually already changed things from Transform into GameObjects, and all my managers are now initializing correctly and giving me the expected things. I also added in a new Camera Manager, Input Manager, and their associated scripts and holder GameObject prefabs.

I'll see what I can do with separate code for spawning. I'll probably chime in later with the latest status. If all goes well, I guess the next thing to do is probably implement the Sound Manager, associated scripts, and make music and sound effects work. For now I think I'll probably use placeholders, but what's a good tool to make music that would end up sounding kind of both retro and not retro at the same time? (Like a Game Boy Advance without audio quality issues. Or SNES. )

Also, the font thing is still unanswered. I'm using a 8x8 pixel font called Press Start, but I think it's an ill fit for a JRPG... Wouldn't it be nice if I could have had a variable-width pixel font that respects either a 8px or 16px line height at a setting of 1 for consistency?

 

[LordRaptor]

For now I think I'll probably use placeholders, but what's a good tool to make music that would end up sounding kind of both retro and not retro at the same time? (Like a Game Boy Advance without audio quality issues. Or SNES. )

Also, the font thing is still unanswered. I'm using a 8x8 pixel font called Press Start, but I think it's an ill fit for a JRPG... Wouldn't it be nice if I could have had a variable-width pixel font that respects either a 8px or 16px line height at a setting of 1 for consistency?

http://www.beepbox.co/ - online chiptune style music maker
http://www.bfxr.net/ - online SFX generator
http://kenney.nl/assets/kenney-fonts - some freeware CC-BY fonts

 

[HandsomeCharles]

Have you looked at Adobes colour wheel?
It will automatically pick contrasting / complimentary / shades of any particular 'input' colour, and by default (not messing with the sliders too much) does so from a hidden ruleset

Yea, thanks! I've been messing around with it but so far the results haven't been all that great. I think another issue I'm having is I don't really understand what all the different presets are "for". Like, for example, when I go to "Shades", I'd expect some kind of gradient going from one extreme to the other, but it doesn't seem to do that..unless it does, but they just aren't in any particular order?

I guess experimentation is the key!

 

[LordRaptor]

Like, for example, when I go to "Shades", I'd expect some kind of gradient going from one extreme to the other, but it doesn't seem to do that..unless it does, but they just aren't in any particular order?

I believe they are in base colour, shadowed, highlighted, super shadowed, super highlighted order.
I think its supposed to be used for Web Designers, but hey, free colour palette swatches

 

[Cute Dragon Here]

http://www.beepbox.co/ - online chiptune style music maker
http://www.bfxr.net/ - online SFX generator
http://kenney.nl/assets/kenney-fonts - some freeware CC-BY fonts

Looks like I'm going to spend some time with the first two, with the first one being a "music sketching" tool, so to speak, while the SFX generator will see a lot of use. I think I'm going to make menu sound effects first

As for the fonts, these fonts look a bit... well, I guess I'll plop them into my game and see if they fit first.

(Hmm, if you were trying to make things play music/sounds, I guess relevant script invoking the SoundManager's whatever it contains works? Haven't touched even one bit of the music code yet.)

 

[superNESjoe]

http://www.beepbox.co/ - online chiptune style music maker
http://www.bfxr.net/ - online SFX generator
http://kenney.nl/assets/kenney-fonts - some freeware CC-BY fonts

Beepbox is really awesome, I can have a lot of fun with that.

 

[Jacksinthe]

Looks like I'm going to spend some time with the first two, with the first one being a "music sketching" tool, so to speak, while the SFX generator will see a lot of use. I think I'm going to make menu sound effects first

As for the fonts, these fonts look a bit... well, I guess I'll plop them into my game and see if they fit first.

(Hmm, if you were trying to make things play music/sounds, I guess relevant script invoking the SoundManager's whatever it contains works? Haven't touched even one bit of the music code yet.)

SFXR is another useful tool for FX.

As for fonts - you are at the mercy of places like DaFont or creating your own. We use http://fontstruct.com/ to create our own fonts. We always use temp stuff, tho. No harm in it.

As for making stuff play music - there are a myriad of settings and ways you can play audio through unity - be sure to create your mixer channels for different audio types like music, fx, etc. Then you can route various audio through those channels in Unity and apply effects to any of the channels, use compression on other channels when certain sounds play (to simulate drowning out other sounds), etc.

Beepbox is really awesome, I can have a lot of fun with that.

Beepbox is great

 

[LordRaptor]

Theres actually a port of SFXR into Unity, so you can use it directly inside of the editor, but I can't remember where I picked it up

e: Google suggests it was probably here, lol

e2:

As for fonts - you are at the mercy of places like DaFont or creating your own. We use http://fontstruct.com/ to create our own fonts. We always use temp stuff, tho. No harm in it.

Thanks for this, I've been using custom fonts for UI icons as a workaround for a lack of native vectorial graphics support in Unity so UI icons look nice at varying resolutions, but I've been using Birdfont which is sort of crappy, so I'll give this one a go

 

[Cute Dragon Here]

SFXR is another useful tool for FX.

As for fonts - you are at the mercy of places like DaFont or creating your own. We use http://fontstruct.com/ to create our own fonts. We always use temp stuff, tho. No harm in it.

As for making stuff play music - there are a myriad of settings and ways you can play audio through unity - be sure to create your mixer channels for different audio types like music, fx, etc. Then you can route various audio through those channels in Unity and apply effects to any of the channels, use compression on other channels when certain sounds play (to simulate drowning out other sounds), etc.


Beepbox is great

All right, hopefully I won't need to ask anything here for sound!

Too bad the Kenney Fonts are unusable for my project. No lowercase :O I might look into font-making, but for now I think I'll live with an ill-suited font.

In the meantime, probably a good idea to ask about checking for nearby warps that I intend to use? I'm thinking of doing it like this:

A location warp would need to have the player be on top of it before the option to change location is shown

Player only needs to confirm by hitting the Submit button (Enter/controller A in my case as the default configuration) and then the scene loads the new location, with the player data preserved

I'm going to guess this involves the player script and an additional script on any involved warp points, no? (these warp points won't have any associated graphics, visible only in editor, if that makes sense)

And for random encounters, I guess it makes sense for me to do it like this?

When the player runs out of steps before an encounter is initiated, load relevant monster list, pick randomly a list of to-be-battled enemies, load battle scene keeping the player data intact. No?

 

[Jacksinthe]

All right, hopefully I won't need to ask anything here for sound!

Too bad the Kenney Fonts are unusable for my project. No lowercase :O I might look into font-making, but for now I think I'll live with an ill-suited font.

In the meantime, probably a good idea to ask about checking for nearby warps that I intend to use? I'm thinking of doing it like this:

A location warp would need to have the player be on top of it before the option to change location is shown

Player only needs to confirm by hitting the Submit button (Enter/controller A in my case as the default configuration) and then the scene loads the new location, with the player data preserved

I'm going to guess this involves the player script and an additional script on any involved warp points, no? (these warp points won't have any associated graphics, visible only in editor, if that makes sense)

And for random encounters, I guess it makes sense for me to do it like this?

When the player runs out of steps before an encounter is initiated, load relevant monster list, pick randomly a list of to-be-battled enemies, load battle scene keeping the player data intact. No?

If you are loading an entirely new scene you can simply ask that the player object not be unloaded from memory between scenes:
http://docs.unity3d.com/ScriptReference/Object.DontDestroyOnLoad.html

DontDestroyOnLoad(this);
DontDestroyOnLoad(this.gameObject);
DontDestroyOnLoad(transform.gameObject);

all work the same.

If you are not loading a new scene and need to transport the player to a different place in wold space just move the player's Vector.

So if you are at vector 0, 0 and need to move him to 20, 20 - just:
transform.position = new Vector2(newPosition);

You can then create a transition animation for the player, hide him while moving, add timings, etc.

For transitions to fight sequences you don't necessarily have to have a new scene setup with the player, you can if you want to but for a more seamless transition i would setup a dummy "view" of the battlefield and either move the camera there or use a second camera and switch views.

I would put this off-screen somewhere so during map play it's never seen.

The dummy view can have all the necessary elements setup and ready to roll. Let's take a look at simple FF fight scenes, for an example.

If you are on grassy land, you have a renderer ready to receive a texture or sprite of a grassy land for the backdrop. If you are in a mountain area, maybe a nice texture or sprite of a mountain area can be loaded into the renderer instead. In 3D space you can load or unload play areas you have at the ready or even have them all setup in scene and say location 10,10 is the mountain area, 30,30 is the swamp, etc. Then just move the camera to those locations where dummy objects are setup.

As for moving your player and the like during these battle scenes - I would probably not care about having any info stored on the actual player object. The player object would act more like a chess piece in that there is nothing actually ON the player's object other than the visuals - sprites, animations, etc. It's just there as a visual representation of the stats your player has. All the important info is stored in a player manager. This way you can use whatever object you want to represent your player in any way you like without being tied to a single object. There is no carry over, no info to move from one object to another - it just exists in a manager and the player object is just a representation of those stats.

I'd keep a battle room off to the side somewhere with all that stuff ready to go then pass control to the battle manager script or whatever you use, switch or move the camera and begin the fight.

 

[Cute Dragon Here]

If you are loading an entirely new scene you can simply ask that the player object not be unloaded from memory between scenes:
http://docs.unity3d.com/ScriptReference/Object.DontDestroyOnLoad.html

DontDestroyOnLoad(this);
DontDestroyOnLoad(this.gameObject);
DontDestroyOnLoad(transform.gameObject);

all work the same.

If you are not loading a new scene and need to transport the player to a different place in wold space just move the player's Vector.

So if you are at vector 0, 0 and need to move him to 20, 20 - just:
transform.position = new Vector2(newPosition);

You can then create a transition animation for the player, hide him while moving, add timings, etc.

For transitions to fight sequences you don't necessarily have to have a new scene setup with the player, you can if you want to but for a more seamless transition i would setup a dummy "view" of the battlefield and either move the camera there or use a second camera and switch views.

I would put this off-screen somewhere so during map play it's never seen.

The dummy view can have all the necessary elements setup and ready to roll. Let's take a look at simple FF fight scenes, for an example.

If you are on grassy land, you have a renderer ready to receive a texture or sprite of a grassy land for the backdrop. If you are in a mountain area, maybe a nice texture or sprite of a mountain area can be loaded into the renderer instead. In 3D space you can load or unload play areas you have at the ready or even have them all setup in scene and say location 10,10 is the mountain area, 30,30 is the swamp, etc. Then just move the camera to those locations where dummy objects are setup.

As for moving your player and the like during these battle scenes - I would probably not care about having any info stored on the actual player object. The player object would act more like a chess piece in that there is nothing actually ON the player's object other than the visuals - sprites, animations, etc. It's just there as a visual representation of the stats your player has. All the important info is stored in a player manager. This way you can use whatever object you want to represent your player in any way you like without being tied to a single object. There is no carry over, no info to move from one object to another - it just exists in a manager and the player object is just a representation of those stats.

I'd keep a battle room off to the side somewhere with all that stuff ready to go then pass control to the battle manager script or whatever you use, switch or move the camera and begin the fight.

Ah, yes. I guess that is probably simple enough. Use the DontDestroyOnLoad on the PlayerManager itself, or on the PlayerScript (duct taped to the actual Player prefab), or on the PlayerData blob contained in the PlayerScript?

As for warps, I guess a collider check is more than enough, no?

(I probably should also start thinking about implementing collider checks for interactable objects that aren't warps.)

I think I prefer the idea of a separated battle scene, to be honest. Trip an encounter, do the fight whoosh while fading into black, load battle scene and do things there, and end going back to the field map or the title screen (if you lose). All the work would be done in the dedicated scene... I guess that's another way!

(Maybe I should start learning about shader effects? I mean, I probably might want to do something to the screen to make it... well, fight wooshy! Camera variable changes can only do so much.)

 

[Jacksinthe]

Ah, yes. I guess that is probably simple enough. Use the DontDestroyOnLoad on the PlayerManager itself, or on the PlayerScript (duct taped to the actual Player prefab), or on the PlayerData blob contained in the PlayerScript?

As for warps, I guess a collider check is more than enough, no?

(I probably should also start thinking about implementing collider checks for interactable objects that aren't warps.)

I think I prefer the idea of a separated battle scene, to be honest. Trip an encounter, do the fight whoosh while fading into black, load battle scene and do things there, and end going back to the field map or the title screen (if you lose). All the work would be done in the dedicated scene... I guess that's another way!

(Maybe I should start learning about shader effects? I mean, I probably might want to do something to the screen to make it... well, fight wooshy! Camera variable changes can only do so much.)

Triggers are just fine for entering/exiting zones.

As for the player stuff, you can have a class/object that is persistent across all scenes where on game start, all saved variables are loaded in. This doesn't need to be attached to any player object. The player object for something like this if I were making it would just have all the basics: movement control, animations, collision. The player manager can be persistent. This way you can just have your player chess piece ready to go in any scene while the important stuff like stats and the like are stored in the manager. This way your player object isn't tied to anything important from its manager.

Think of it like D&D - that sheet of paper with all your stats is your player. Those gloriously painted pewter figurines are the player object, both can exist in a vacuum while the pewter figurine is just a representation of your stat sheet. You can change your figurine any time you like and it won't affect the stats. Forget to bring him to a game at the DM's house, cry a little, but still play without it while your friends give you shit because back then it was serious business.

Figure everything that is important happens in the background, nothing in scene should be needed to play the systems of the game: visual maps, collision, etc notwithstanding.

In short: the player's stats and the object don't have to be tied to one another.

 

[justsomeguy]

Oh I agree with this and do the same, only info that may be used more than a few times per scene makes it to the logic class. I have separate classes for save game handling, menu systems (platform specific), game settings, control settings, etc.

My logic class is the way I gather the most important bits from the ones that are important to run a scene. The logic class also handles querying other classes to pass info to, run functions, etc.

It's more current state focused and only about 250 lines of code, so it's relatively tiny.

When I started with gamedev I made the mistake of making it a god class on our first project XD no fucking way, man! Shit was unruly hahahaha.

Still, just a few of my classes do tend to run slightly large but I wrote those specific classes with that in mind. But yeah, I even go as far as compartmentalizing things like my camera both by script and nested gameObjects from its individual systems to keep my sanity when adding new camera tricks related to camera movement.

Check out the SOLID principles. Will take you a long way towards a clean class design.

 

[justsomeguy]

All right!

I think I'm missing something, though. As it is right now, all three classes are actually C# scripts; PlayerScript contains PlayerData which contains Stats. I intend to serialize PlayerData, but for some reason I keep running into the problem that the automatically-inherited Transform thingy from MonoBehavior is making it fail.

Apparently the data-only stuff should not inherit MonoBehavior, but as soon as I remove the inheritance, Unity throws a fit and won't recognize these data scripts. What should I do?

Apologies, I'm not a unity dev so I'm not sure on the restrictions/issues here or the best way to work around it.

 

[justsomeguy]

Not much to show for today. Still have a lot of work and ideas to go through before getting where I want.



Changed my data structure handling movement into a Dictionary so I can do things more easily later on. Took a bit longer that I thought it would but having a position based key makes it really nice for accessing platforms. I've been trying to come up with cool puzzle ideas that rely on camera rotation. So far "escher platforms" and "stationary platforms"(where you rotate and the platforms stay in the exact same position with respect of the camera) are the main ones I've come up with. Once I get both of those fully working then I want to put in some moving platforms as well as obstacles that you'll have to time and move around. Need to give reason for single block movement.

Love this so much. How about blocks that change behaviour/state depending on what type of block or how many other blocks they're touching?

 

[Jacksinthe]

Check out the SOLID principles. Will take you a long way towards a clean class design.

That acronym went over my head. I never went to school for programming so a lot of what I do

Spoiler

everything

is from the hip and never learned right or wrong ways to do stuff. I only know I like compartmentalizing stuff because its easier for me to debug and fix things when I inevitably break them.

I'm an incredibly dumb programmer, tbh.

 

[Cute Dragon Here]

Triggers are just fine for entering/exiting zones.

As for the player stuff, you can have a class/object that is persistent across all scenes where on game start, all saved variables are loaded in. This doesn't need to be attached to any player object. The player object for something like this if I were making it would just have all the basics: movement control, animations, collision. The player manager can be persistent. This way you can just have your player chess piece ready to go in any scene while the important stuff like stats and the like are stored in the manager. This way your player object isn't tied to anything important from its manager.

Think of it like D&D - that sheet of paper with all your stats is your player. Those gloriously painted pewter figurines are the player object, both can exist in a vacuum while the pewter figurine is just a representation of your stat sheet. You can change your figurine any time you like and it won't affect the stats. Forget to bring him to a game at the DM's house, cry a little, but still play without it while your friends give you shit because back then it was serious business.

Figure everything that is important happens in the background, nothing in scene should be needed to play the systems of the game: visual maps, collision, etc notwithstanding.

In short: the player's stats and the object don't have to be tied to one another.

All right! Perhaps I should think about separating the stats and the objects, but for now they're probably staying together for a bit more while I think the thing through. Perhaps the Player prefab will contain just the visual and collision things and things needed for movement (and, by necessity, step-counting), while the PlayerManager handles the stats?

In the meantime, how does this sound? Was messing around and seeing if I could indeed make music properly.

Apologies, I'm not a unity dev so I'm not sure on the restrictions/issues here or the best way to work around it.

No worries there, I already fixed the things. My game project is now happily Manager-based.

 

[Jumplion]

That acronym went over my head. I never went to school for programming so a lot of what I do

Spoiler

everything

is from the hip and never learned right or wrong ways to do stuff. I only know I like compartmentalizing stuff because its easier for me to debug and fix things when I inevitably break them.

I'm an incredibly dumb programmer, tbh.

In my experience as an equally dumb programmer, there are no good programmers, only programmers that are paid more than other programmers. And i'm in college dual majoring CS and game design.

To the best of my understanding, SOLID basically means;

• Have each class/script be used for one thing instead of a dozen things. For example, player movement is one script while player stats is another, and have the two interact rather than stuffing it all into one script.
• Keep your code stable and open for extension rather than modifying it's guts all the time. So, say you have an enemy, if other scripts are accessing it then that means it shouldn't be modified anymore because it's "stable". If you need to add behaviors to it, you can add more functions and data to it, rather than renaming and rejiggering the previous code.
• Have parent objects be replaceable by child objects. So, if you have an overall "enemy" object with a child "super enemy", if something goes wrong they should both be usable in, say, a spawner script.
• Interfaces are better when they're specialized to the object rather than generalized to everything. A "game object" interface isn't as useful to an enemy when it has a dozen functions it's never going to use. The example Wikipedia gives is an ATM that has a broad interfacing dealing with withdrawl, deposit, and security, when it should be more specified for each interface
• Finally, decoupling is separating your high-level/low-level modules (complex, involved code vs. smaller code) into relying on abstraction. Keeping the enemy movement and player movement separate and have them take their calls from an abstract movement.

I could be wrong in this interpretation, and by all means these are just recommendations on how to build your code. I tend to be more fly by the stea of my pants kind of coder, but I generally follow some of these ideas.

 

[JulianImp]

Question to anyone using Unity for a mobile game (particularly android), what should I aim for in terms of APK size? Right now my latest build is about 22MB, and I remember reading from one of you that 100MB is the absolute max you tend to want to aim for, right?

I can't remember what the limits are for the Google play Store right now, but I think it's 100MB.

What this means is that if your app is larger than 100meg, users will have to connect to WiFi in order to download it. This can be a kiss of death for some apps. Mobile users are incredibly fickle. If they see something that looks appealing in the app store and go "Oh, I'll install that!", but then get a message saying that they need to be on WiFi, the vast, vast majority of them won't even bother.

Whilst still a huge issue, it is slightly less if your app is paid for, as if someone has paid money, chances are they are going to want to actually get something for it and will download it again later. Still, getting under 100MB is an absolute must.

This is why many games utilise DLC methods of getting additional assets after the initial install, simply so they can get the footfall from that first app-store glance. A user is way more likely to stick around for the DLC download if they've already installed.

But to put it into perspective, at work we have a fairly popular F2P mobile game, and each update we do we spend a lot of time trimming assets, compressing things where possible etc. to ensure that we hit that 100MB mark.

Oh, and just as a work of warning, aim for about 85MB, as for whatever reason the process of adding your app to a store will increase the bundle size by a random value that sometimes goes up to 10MB!

Something you should know is that you can build .unity3d asset bundles and host them separately from the main game. Then there's also a WWW request that lets you compare a version number and has Unity load the file from cache if the local file is up to date, and downloads it if it isn't. Using both features together you can make your store app smaller in case you end up going over 100MBs, and implementing an asset bundle handler would allow you to also use it for additional content such as DLC later on.

 

[Jacksinthe]

In my experience as an equally dumb programmer, there are no good programmers, only programmers that are paid more than other programmers. And i'm in college dual majoring CS and game design.

To the best of my understanding, SOLID basically means;

• Have each class/script be used for one thing instead of a dozen things. For example, player movement is one script while player stats is another, and have the two interact rather than stuffing it all into one script.
• Keep your code stable and open for extension rather than modifying it's guts all the time. So, say you have an enemy, if other scripts are accessing it then that means it shouldn't be modified anymore because it's "stable". If you need to add behaviors to it, you can add more functions and data to it, rather than renaming and rejiggering the previous code.
• Have parent objects be replaceable by child objects. So, if you have an overall "enemy" object with a child "super enemy", if something goes wrong they should both be usable in, say, a spawner script.
• Interfaces are better when they're specialized to the object rather than generalized to everything. A "game object" interface isn't as useful to an enemy when it has a dozen functions it's never going to use. The example Wikipedia gives is an ATM that has a broad interfacing dealing with withdrawl, deposit, and security, when it should be more specified for each interface
• Finally, decoupling is separating your high-level/low-level modules (complex, involved code vs. smaller code) into relying on abstraction. Keeping the enemy movement and player movement separate and have them take their calls from an abstract movement.

I could be wrong in this interpretation, and by all means these are just recommendations on how to build your code. I tend to be more fly by the stea of my pants kind of coder, but I generally follow some of these ideas.

I get it now

I do follow a good portion of this although some dirtyness does get thrown on from time to time as I expect it to be the norm with a lot of programming. Sometimes dirty gets the job done if kept to a bare minimum.

I do compartmentalize a majority of what I do. Even for my camera actions they are all nested prefabs in children of children with their own scripts and functions so it's easier for me to create multiple movement paths using local positions of children like if I need to offset, I just move the child and not have to rewrite my "follow" script to maths the offsets, lerps, etc to allow proper vector follow and offset at the same time. Easier to just have the following keep following while the child moves smoothly.

I suppose that's the kind of stuff SOLID is getting at, keeping stuff in their own corners of the room and only moving toward the center when necessary.

 

[bad guy]

I quickly chewed and spat out a crazy game.

download​

 

[Exuro]

Love this so much. How about blocks that change behaviour/state depending on what type of block or how many other blocks they're touching?

So right now I'm focusing on getting the escher blocks prettied up ie movement transitions and shadow transitions. Here's a gif of my escher test level. You can see the shadows aren't quite convincing/smooth, and for some reason shadows are casting through the blocks. Need to figure out whats up with that.

Once that's finished up I do need to come up with more ideas. Right now one of them I have is having a block type that doesn't move relative to the camera, so when you rotate it could bridge a gap you need to cross. Do you have any examples of what you mean by changing behavior/state? I'm all ears.

 

[Bollocks]

There's a good chance you can get it from NASA if you search their site.

Virtual Terrain Project

haha thanks.
It kinda started out as a joke but the more I think about it, it would actually be a really cool experiment.
Base the survival aspect around the users actual geolocation -> query real weather information and time.
Trying to play on a stormy winter day at night? Good Luck.

Since I need a server anyway to persist the game world, why not make it run in the browser as well with webGL, no compile step, quick and easy iteration. For the multiplayer I'll use a db with realtime update capabilities(After all some market it specifically for realtime multiplayer games, lets see).

 

[HandsomeCharles]

Something you should know is that you can build .unity3d asset bundles and host them separately from the main game. Then there's also a WWW request that lets you compare a version number and has Unity load the file from cache if the local file is up to date, and downloads it if it isn't. Using both features together you can make your store app smaller in case you end up going over 100MBs, and implementing an asset bundle handler would allow you to also use it for additional content such as DLC later on.

Cheers, that's useful info! Unfortunately we don't use Unity at work, but Im sure it'll help someone nonetheless

 

[HP_Wuvcraft]

This forum helped me with the Linux testing: https://www.gamingonlinux.com/forum/

Thank you.

The Linux build uploads to the server, but when people try to download it to their Steam account.... they get a blank folder.

 

[Blizzard]

Thank you.

The Linux build uploads to the server, but when people try to download it to their Steam account.... they get a blank folder.

If you don't have any machine you can dual-boot, try downloading VirtualBox (open-source, commercial use allowed last I checked) and installing Ubuntu (or Debian or whatever) on it. That might let you run Steam and check it yourself, and it'll also provide you very useful experience for Linux debugging, plus a simple platform for Linux testing.

It might not provide the performance your game needs, but it might help you fix install issues like missing files.