TheHollowNight
Member
Working on a store type thing for my game. Instead of having a traditional store I'm thinking about making 80's/90's style magazine type ads
I am super into this
-
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
- Thread starter Jacksinthe
- Start date
- Status
I am super into this
Cute Dragon Here
Member
Once you remove inheritance from MonoBehavior, you wont be able to attach the file as a script to your gameobjects anymore. Instead, you will want to make instances of the class within the relevant scripts that you do attach.
Check here for more information on how to make instances of Classes in C#
C# isn't my strongest language (I'm much more comfortable in C++) but classes can be a tricky thing to get your head around if you haven't encountered them before. If there's anything you don't understand, feel free to give me a shout
Nice! The entire thing saves properly now. I think I probably should whip up a title screen to test New Game and Continue. New Game should load defaults, and Continue does what you expect it to.
Single save file until I get the rest of the code working... Also, I guess I should plan on the initial player name/class name/stat swinging...
Finally got this thing to work:
I've adapted the lighting to be more cel-shaded in general, by introducing a ramp approach in Unity's deferred lighting shader. Next to that, as evident in the .gif, I've set up an object to shoot out blood drops by means of a trail renderer, which on collision with objects, creates a point light. This point light emits a very intense red light which fades out of existance.
Thanks to the cel-shaded ramp, the red light forms a nice clean circle instead of the usual, gradual light. The blood trails and lights are also set up to avoid and ignore certain objects that are not on the same layer. This way I can have them only affect the actual environment while ignoring the Player or other moving objects (or in the .gif, a random cube to test it).
The lighting and shaders are also set up so that a white/colorless light brightens up the area, as it should, while colored lights will force their color and somewhat override the basic color of the object it's hitting.
I've adapted the lighting to be more cel-shaded in general, by introducing a ramp approach in Unity's deferred lighting shader. Next to that, as evident in the .gif, I've set up an object to shoot out blood drops by means of a trail renderer, which on collision with objects, creates a point light. This point light emits a very intense red light which fades out of existance.
Thanks to the cel-shaded ramp, the red light forms a nice clean circle instead of the usual, gradual light. The blood trails and lights are also set up to avoid and ignore certain objects that are not on the same layer. This way I can have them only affect the actual environment while ignoring the Player or other moving objects (or in the .gif, a random cube to test it).
The lighting and shaders are also set up so that a white/colorless light brightens up the area, as it should, while colored lights will force their color and somewhat override the basic color of the object it's hitting.
Cute Dragon Here
Member
Hmm, is there a pixel font that I can use in Unity where the font is optimized for a 16 pixel height and is variable width?
If you're serious about localization, YUP.
For me, any time I want to display a string...anywhere...I use a static method. LM.translate(string s)...LM stands for "Localization Manager"...which references a static database I build on program launch from a giant excel spreadsheet (.tsv). I have a few helper scripts that automatically comb through commonly used other components that might have strings pre-defined in the editor and auto-replaces them on scene start-up.
As long I always use LM.translate, everything will always work. And there are some benefits, too...LM.translate will add "***" to the beginning and end of a string if it couldn't find a relevant entry in the database, clearly marking something in the game that doesn't have an appropriate entry (otherwise, it might just look like normal English to me). In addition, localization editing just means working in a nice Excel spreadsheet, with all the benefits that come from working in Excel.
Strings in general are not very large, and it isn't a very big deal to keep a database containing around two hundred thousand words long in memory (which is about where TCAE reached).
A slight challenge is finding a font that supports *EVERYTHING*, from Cyrillic to Korean to allllll the Chinese and Japanese symbols. Your best option here is probably the free Google Noto, which I dynamically switch to for non-standard character sets...that way I get to keep my beautifully chosen fonts for all Roman character languages. ^^
tamaster92
Member
Well, we're finally live with Into the Stars on Steam & GoG - It has been a CRAZY couple years and I just wanted to thank Indie GAF for the sane voices of support and encouragement!
Launch Trailer
Website
Our first review is in and we can't wait to see what the rest of the day brings...
im a bit late but grats!
Cute Dragon Here
Member
Sorry for going to this thread and asking even more questions as I work with my game! Seeing as this kind of "I always wanted to do this" project is quite different from what I've handled during my CompSci course... (mostly to do with the larger scope, and different requirements)
Once I'm done with the world map, I think I'd like to be able to effortlessly reuse the code for the player handling (for gameplay) camera, and the UI. All are already prefabs, but right now they're also separate Unity prefabs. If I instate them in a new scene for a new map, the links will break. Is there a way to reduce my work even further by making sure the Unity editor somehow "knows" that they all should be automatically linked together, in any method you know of? (Maybe it involves an "everything of the above" prefab?)
Also, how would you handle event flags for quest/game progress in a JRPG?
(Also would be nice is a way to keep the important data in memory while the game changes the scene, be it to another map or to a battle... DontDestroyOnLoad seems to be the ticket. Just want to make sure I'm not doing things wrong.)
Once I'm done with the world map, I think I'd like to be able to effortlessly reuse the code for the player handling (for gameplay) camera, and the UI. All are already prefabs, but right now they're also separate Unity prefabs. If I instate them in a new scene for a new map, the links will break. Is there a way to reduce my work even further by making sure the Unity editor somehow "knows" that they all should be automatically linked together, in any method you know of? (Maybe it involves an "everything of the above" prefab?)
Also, how would you handle event flags for quest/game progress in a JRPG?
(Also would be nice is a way to keep the important data in memory while the game changes the scene, be it to another map or to a battle... DontDestroyOnLoad seems to be the ticket. Just want to make sure I'm not doing things wrong.)
Jacksinthe
Banned
Nick change, BTW.
LordRaptor
Member
#screenshotsaturday
draggable + resizable UI panels with custom cursors
draggable + resizable UI panels with custom cursors
HandsomeCharles
Member
I think you're coming to the point where you need to start thinking about Managers.
What I'm assuming you have at the moment, is a scene where you have manually dragged the prefabs in, attached scripts, linked these scripts up yourself and then hit "play". If that is the case, then unfortunately this isn't going to cut it for the rest of the project
One of the things that can be a bit bewildering with Unity is trying to figure out how different game objects interact with each other. How does one object (script) "know" about another? This is where managers come into play.
(This is going be a very basic example, so sorry if it doesn't apply directly to your project. Also sorry if this is stuff you already know about!).
So let's take a look at a "Player Manager". The PM is a class that should be responsible for creating the player, destroying the player and providing a reference to the player to any other class that needs it. This means that (ideally) you want to make a single instance of your PM, and have it be accessible by any other class that may need to access information about the player. (You might want to look up "Singletons" in unity for an example of how to make a class like this). Oh, and yes, we would probably want to make this class "don't destroy on load" or whatever that function is called
We want it to persist between scenes.But how should the PM actually make a player? I'd say the most sensible way would be to have a public method named something like "CreatePlayer()". The reason we would want to do this is because then we have more direct control over when the player is created. Since the PM is going to persist over all our scenes, we can't rely on its "start" or "awake" functions to do this. What would be more sensible is to have a unique script for each "level", that calls the "CreatePlayer()" method in the Player Manager when the level starts. (Apologies for the platform game example here, but hopefully you'll be able to adapt it to your own game)
Now, the "CreatePlayer()" method would have to maintain a reference to the player that it instantiates. This is pretty simple, you just do something like "GameObject MyPlayer = Instantiate(PlayerPrefab) as GameObject" (Can't remember the exact syntax, sorry!). Then, in any other class (such as the UI), when we needed to know information about the player (like health) we can do something like "PlayerManager.Instance.MyPlayer" in order to grab the player, and then we can use GetComponent to get the player script which would likely be holding all of it's data.
So know we've got an overview of what it does, let's talk about how you can use this to avoid setting up all the links in your prefabs. To put it quite simply, you just need to set those links via code. Again, I don't know what you're doing, but I assume you have something like a reference to your player in your camera, that you have dragged in via the editor. Well, that's pretty simple! In your camera's Update function, check if the reference to the player is NULL, and if it is, then get the player from the player manager! This way you can ensure that your camera will start "knowing about" the player as soon as the player is spawned, even if you aren't going to spawn your player for 30 seconds after the scene starts!
Now, one thing that you absolutely, 100% need to be aware of, is that when you use systems like these, you must always check that your references are valid before attempting to call any methods on them!
For example, if above in our camera we simply went:
Code:
if(MyPlayerReference == null)
{
MyPlayerReference = PlayerManager.Instance.MyPlayer;
MyPlayerReference.DoSomething();
}This would more likely than not crash. This is because we didn't check whether the player manager actually gave us back a valid reference or not. A simple way to fix this would be:
Code:
if(MyPlayerReference == null)
{
MyPlayerReference = PlayerManager.Instance.MyPlayer;
if(MyPlayerReference != null)
{
MyPlayerReference.DoSomething();
}
}That is a much safer way to do it, as you ensure that the player is valid before you call a method on it. Basically, whenever you need to grab a reference to something from a manager, you need to do a check like this before you do anything with that reference.
(Just make sure whenever you delete/destroy the player, you set the PlayerManager's reference to the player to be null, otherwise you run the risk of passing back a junk reference that won't be picked up by these safety checks.)
Phew, that was a bit of a long one... Anyway, I hope that has helped and not compounded your confusion
Let me know if you need anything else!
Cute Dragon Here
Member
I think you're coming to the point where you need to start thinking about Managers.
What I'm assuming you have at the moment, is a scene where you have manually dragged the prefabs in, attached scripts, linked these scripts up yourself and then hit "play". If that is the case, then unfortunately this isn't going to cut it for the rest of the project
One of the things that can be a bit bewildering with Unity is trying to figure out how different game objects interact with each other. How does one object (script) "know" about another? This is where managers come into play.
(This is going be a very basic example, so sorry if it doesn't apply directly to your project. Also sorry if this is stuff you already know about!).
So let's take a look at a "Player Manager". The PM is a class that should be responsible for creating the player, destroying the player and providing a reference to the player to any other class that needs it. This means that (ideally) you want to make a single instance of your PM, and have it be accessible by any other class that may need to access information about the player. (You might want to look up "Singletons" in unity for an example of how to make a class like this). Oh, and yes, we would probably want to make this class "don't destroy on load" or whatever that function is called
But how should the PM actually make a player? I'd say the most sensible way would be to have a public method named something like "CreatePlayer()". The reason we would want to do this is because then we have more direct control over when the player is created. Since the PM is going to persist over all our scenes, we can't rely on its "start" or "awake" functions to do this. What would be more sensible is to have a unique script for each "level", that calls the "CreatePlayer()" method in the Player Manager when the level starts. (Apologies for the platform game example here, but hopefully you'll be able to adapt it to your own game)
Now, the "CreatePlayer()" method would have to maintain a reference to the player that it instantiates. This is pretty simple, you just do something like "GameObject MyPlayer = Instantiate(PlayerPrefab) as GameObject" (Can't remember the exact syntax, sorry!). Then, in any other class (such as the UI), when we needed to know information about the player (like health) we can do something like "PlayerManager.Instance.MyPlayer" in order to grab the player, and then we can use GetComponent to get the player script which would likely be holding all of it's data.
So know we've got an overview of what it does, let's talk about how you can use this to avoid setting up all the links in your prefabs. To put it quite simply, you just need to set those links via code. Again, I don't know what you're doing, but I assume you have something like a reference to your player in your camera, that you have dragged in via the editor. Well, that's pretty simple! In your camera's Update function, check if the reference to the player is NULL, and if it is, then get the player from the player manager! This way you can ensure that your camera will start "knowing about" the player as soon as the player is spawned, even if you aren't going to spawn your player for 30 seconds after the scene starts!
Now, one thing that you absolutely, 100% need to be aware of, is that when you use systems like these, you must always check that your references are valid before attempting to call any methods on them!
For example, if above in our camera we simply went:
Code:if(MyPlayerReference == null) { MyPlayerReference = PlayerManager.Instance.MyPlayer; MyPlayerReference.DoSomething(); }
This would more likely than not crash. This is because we didn't check whether the player manager actually gave us back a valid reference or not. A simple way to fix this would be:
Code:if(MyPlayerReference == null) { MyPlayerReference = PlayerManager.Instance.MyPlayer; if(MyPlayerReference != null) { MyPlayerReference.DoSomething(); } }
That is a much safer way to do it, as you ensure that the player is valid before you call a method on it. Basically, whenever you need to grab a reference to something from a manager, you need to do a check like this before you do anything with that reference.
(Just make sure whenever you delete/destroy the player, you set the PlayerManager's reference to the player to be null, otherwise you run the risk of passing back a junk reference that won't be picked up by these safety checks.)
Phew, that was a bit of a long one... Anyway, I hope that has helped and not compounded your confusion
Hmm, to see if I get it:
Create a PlayerManager class that will persist across different scenes, and it should handle the instantiation of the Player prefab.
As the project is right now, my Player prefab/object contains the PlayerScript script which then contains the data that will be used for gameplay and saved/loaded as necessary. Also seen: a Camera and UI prefab/object. Right now, they're all separate objects, and the camera is directly a child to the Player object in the scene.
So, if I'm not getting things wrong, I should create a new GameObject containing just the PlayerManager script thingy, and let it create the Player when the time is right?
As for the camera and the UI, I guess they only need to have their scripts updated to keep checking if the Player eventually gets created, then grab that instance? And they also have to find a PlayerManager first?
Sorry for all the questions, but yeah, this thing's scope a lot bigger than any projects I've done in uni, AND I'm doing it alone.
LordRaptor
Member
Just FYI, theres a Unity game manager code snippet linked in the OP
HandsomeCharles
Member
Yep, that's pretty much it. In theory the camera and UI shouldn't have to "find" the PlayerManager, as it should be a global static instance. This means it can be accessed from anywhere within the project. (Note that isn't necessarily the best way to do it, but it probably is the simplest)
Cute Dragon Here
Member
All right, will see if I can adapt it to my needs.
Mmm hmm. One more thing: the functions that the PlayerScript originally did probably should go somewhere else.
I'm thinking of something like below...
PlayerManager creates and keeps the Player prefab
Player prefab contains the PlayerScript for gameplay use
Camera and UI finds the PlayerManager static object, waits until the Player shows up, then grabs the instance and do things.
Should I leave the PlayerScript as is, or should I move the non-data code out of it, or move everything out of it?
LordRaptor
Member
I tend to just have an empty gameobject called "managers" in my initial scene and any manager scripts that I need I just attach them all to that gameobject - although thats for games where the fundamental things being managed don't actually change; UI, score, player values, etc.
for a game where, I dunno, in level 1 its an on foot platformer, level 2 is a racing game or whatever, that might not be the best way
for a game where, I dunno, in level 1 its an on foot platformer, level 2 is a racing game or whatever, that might not be the best way
Jacksinthe
Banned
I have a logic class that handles stuff like this so I can query if the player is alive, dead, his position, his object, etc. This way I don't need to constantly find the player with multiple objects - when I need to I just look at my GameLogic to find out where to aim, where he's standing, the closest respawn point in relation to the player, etc. At the end of every frame I update pertinent player information from the player's controller to the game's logic. I also use it to initialize on state change, new game, etc. Basically an overall manager. Other classes update and initialize various variables in the logic class on a need to basis.
I'm quite fond of management being done this way. Its a single class that can be accessed by anything in the game. If you don't abuse them they work very well, IMO.
HandsomeCharles
Member
Seems like you're almost there now!
Your playerscript should handle everything about how the player actually functions within the game. For example, things like Movement, attacking, receiving damage, triggering animations. That kind of stuff.
As a rule of thumb, if it affects your player directly, then it should be done in the player script. As a little example, here's a potential flow for how an enemy may attack.(Again, maybe not 100% relevant to your project)
- The enemy gets the reference to the player from the PM
- The enemy calculates the distance between it and the player
- The resulting ditance is within range, so the enemy calls an "Apply Damage" function on thePlayerscript, and passes in a value of 100
- The Playerscript, within it's ApplyDamage, does calculations based on the stats/gear currently equipped
- The playerscript then decreases its health by the appropriate value
So in that example we can see how the different scripts (enemy and player) have different responsibilities. Enemy does all the distance calculations, Player does the resulting damage calculation.
Hope that makes it a bit clearer
Cute Dragon Here
Member
Well, the game I'm trying to make would be a console-style RPG. I think I probably just need to find a way to make sure I can create new scenes (the way I'm storing different maps) easily without all the links breaking, as well as making the player data preserved across map loads.
Seems like you're almost there now!
Your playerscript should handle everything about how the player actually functions within the game. For example, things like Movement, attacking, receiving damage, triggering animations. That kind of stuff.
As a rule of thumb, if it affects your player directly, then it should be done in the player script. As a little example, here's a potential flow for how an enemy may attack.(Again, maybe not 100% relevant to your project)
- The enemy gets the reference to the player from the PM
- The enemy calculates the distance between it and the player
- The resulting ditance is within range, so the enemy calls an "Apply Damage" function on thePlayerscript, and passes in a value of 100
- The Playerscript, within it's ApplyDamage, does calculations based on the stats/gear currently equipped
- The playerscript then decreases its health by the appropriate value
So in that example we can see how the different scripts (enemy and player) have different responsibilities. Enemy does all the distance calculations, Player does the resulting damage calculation.
Hope that makes it a bit clearer
Ah! Since it's a turn-based console-style RPG, the battles take place on an entirely different scene. I still haven't gotten the battle code in at all yet - no battle code at all! Right now, I do have functional movement and UI code for the most part. Gotta fix the loading sloppiness, non-functional Exit Game, and... testing out warps and interactable objects.
(Oh, and it also has a working "loop the world map" code without visual issues, and a working stat/level formula.)
HandsomeCharles
Member
It's means to an end really. The underlying functionality is the same, it's just abstracted to different levels. However, I'm of the opposite opinion when it comes to management. I like to separate everything up as much as possible. The main reason for this is organisation.
If, for example, we put all of the various manager operations into a single global for the stuff I do at work, that file would probably end up being tens of thousands of lines long. Probably hundred thousands actually...It'd make me want to shoot myself in the face
The other advantage (IMO) of separating everything out as much as possible means that it's harder to make silly mistakes (Like accidentally calling the wrong function or setting the wrong value) as you need to be a fair bit more explicit in what you're actually doing in order to get results.
But really, in terms of execution the difference is just a few function calls. Like, if I was querying whether the player was alive or not, I'd do something like this:
Code:
if(g_PlayerManager->GetPlayer())
{
if(g_PlayerManager->GetPlayer()->GetPlayerState() == ePlayerState_Dead)
{
//DoStuff. Reset level and shizzle.
}
}But as I said, just means to an end really!
Cool, keep at it! And don't be disheartened when you inevitably have to rewrite a massive section. It happens to everyone
Jacksinthe
Banned
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.It's means to an end really. The underlying functionality is the same, it's just abstracted to different levels. However, I'm of the opposite opinion when it comes to management. I like to separate everything up as much as possible. The main reason for this is organisation.
If, for example, we put all of the various manager operations into a single global for the stuff I do at work, that file would probably end up being tens of thousands of lines long. Probably hundred thousands actually...It'd make me want to shoot myself in the face
The other advantage (IMO) of separating everything out as much as possible means that it's harder to make silly mistakes (Like accidentally calling the wrong function or setting the wrong value) as you need to be a fair bit more explicit in what you're actually doing in order to get results.
But really, in terms of execution the difference is just a few function calls. Like, if I was querying whether the player was alive or not, I'd do something like this:
Code:if(g_PlayerManager->GetPlayer()) { if(g_PlayerManager->GetPlayer()->GetPlayerState() == ePlayerState_Dead) { //DoStuff. Reset level and shizzle. } }
But as I said, just means to an end really!
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.
Cute Dragon Here
Member
Cool, keep at it! And don't be disheartened when you inevitably have to rewrite a massive section. It happens to everyone
I actually dumped an entire tile set and two test maps because I thought they looked off.
This world map is actually my first keeper, really... and it's weird to see the first "finalized" level being the world map.
Also, right now I'm using Box2D-based movement by applying force. It does work well enough with some tweaking (disabling unwanted gravity and making it almost start and stop on a dime), but I was thinking if I could do better by making it truly start/stop movement. Doesn't have to be fixed to a grid, mind you - my intent is to allow free analogue movement where possible. (The mapping tool I use, Tiled + Tiled2Unity automatically generates appropriate collision, layers, and animations, so I'm set on mapping.)
Just to be sure, for my needs, I probably only need one static manager class for now, no? And it'll just "work" if I prefab the GameObject having the script for said manager? (And just asking, should the camer and UI canvas be also prefabs?)
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.
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.
rhophiehalul78
Member
And here we have the blood effect in action:
Love the look, but the ribbon on the weapon being red kinda distracts and masks the blood effects.
http://gfycat.com/TotalMildEyelashpitviper
Taking a break from writing events to record a little bit of the latest progress! It's a big'un, so I'm only posting the gfycat link, but inside you'll see:
-DYNAMIC variable text display action (per character at first, instant display switch a couple text boxes in, before reverting to per character display for the last few)
-GROUNDBREAKING wordwrapping, that totally works with all fonts ever (actually, I'm not entirely sure)
-an INTENSE transition to a beat'em all battle through a loading screen that may, or may not, be longer than it should because of the laginess of preview mode+youtube music blaring in parallel to the recording, and also it's still not correctly aligned dammit I thought I had fixed that
-VISCERAL beat'em all action with new low stance animations and a movement speed that's way too fast because I forgot I had set Honey to have 150+ speed (fat chance of that ever happening in game, though you're very welcome to try)
(this bulletpoint list in reference to the "how to contact games media" post from earlier, which is obviously something I'm working on in parallel - what, you mean to say that's not how we should do it?)
Taking a break from writing events to record a little bit of the latest progress! It's a big'un, so I'm only posting the gfycat link, but inside you'll see:
-DYNAMIC variable text display action (per character at first, instant display switch a couple text boxes in, before reverting to per character display for the last few)
-GROUNDBREAKING wordwrapping, that totally works with all fonts ever (actually, I'm not entirely sure)
-an INTENSE transition to a beat'em all battle through a loading screen that may, or may not, be longer than it should because of the laginess of preview mode+youtube music blaring in parallel to the recording, and also it's still not correctly aligned dammit I thought I had fixed that
-VISCERAL beat'em all action with new low stance animations and a movement speed that's way too fast because I forgot I had set Honey to have 150+ speed (fat chance of that ever happening in game, though you're very welcome to try)
(this bulletpoint list in reference to the "how to contact games media" post from earlier, which is obviously something I'm working on in parallel - what, you mean to say that's not how we should do it?)
Cute Dragon Here
Member
Stuffed in the generic manager code from the linked post in the OP.
Now that I have a PlayerManager, well, I guess I'll have to put code somewhere in it so that once it asserts its existence and confirms that it's the only one out there, get a Player prefab out there, and initialize if needed?
Also would be good to answer to.
(Man, I really am "fresh" with Unity.)
Now that I have a PlayerManager, well, I guess I'll have to put code somewhere in it so that once it asserts its existence and confirms that it's the only one out there, get a Player prefab out there, and initialize if needed?
Also would be good to answer to.
(Man, I really am "fresh" with Unity.)
HandsomeCharles
Member
Ah right, I think I understand you now
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
Oh man, that crouch/hop! Looking nice!
Btw, I may have missed that post from before, was it in this thread? And do you happen to have a link handy?
Yeah, noticed the same. Not sure yet what I would do, I guess the most sensible answer would be to adjust the color of the ribbon.
Oh man, that crouch/hop! Looking nice!
Btw, I may have missed that post from before, was it in this thread? And do you happen to have a link handy?
Thanks!
And no, I meant someone asked how to properly contact games media earlier... not sure there's any definite good answer about that, the only good reference I have on the topic is the one everyone has probably seen already: http://www.pixelprospector.com/how-to-contact-press/
Kinda dreading the whole process, myself, but everyone needs to go through the wringer at some point. That's why I appreciate the lengths to which people like timetokill right here are willing to go to try out and give feedback/exposure. I feel we all need every bit of help we can get with coverage, especially if/when we can't get to indie gatherings and conventions (take me, being in France and living off basically what I need to make it through each month, it's absolutely not something I can even remotely consider)... so I sincerely thank people who go out of their way to do so!
HandsomeCharles
Member
Thanks for the info! The guys that made CrashLands did an AMA on reddit a little while ago, which had some useful tips. I asked them about their marketing stragegy, and one of the things they did was make their emails "sassy"...not really sure what they meant by that but it worked
I think your game definitely has potential to get good coverage, just as long as it gets in-front of the right eyes! I'm very, very early on the "promotion" road myself, but I'm also dreading having to take the plunge and fire my screenshots/videos out to as many people as possible
Jacksinthe
Banned
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.
As for movement - ditch addforce and set the velocity directly if you want instant start/stop. Set all drag coefficients to zero. If you want accel/decel just write your own. Waaaaaaay easier than working with forces.
Or you could translate the vector for movement and write your own collision using raycasts. Either or will work fine. For something like your game I don't think vector translation is needed, tbh.
Thanks for the info! The guys that made CrashLands did an AMA on reddit a little while ago, which had some useful tips. I asked them about their marketing stragegy, and one of the things they did was make their emails "sassy"...not really sure what they meant by that but it worked
I think your game definitely has potential to get good coverage, just as long as it gets in-front of the right eyes! I'm very, very early on the "promotion" road myself, but I'm also dreading having to take the plunge and fire my screenshots/videos out to as many people as possible
Ooh, thanks for the link! The more material on the subject, the better :-D
A few shots from our current project, Magnetta:
And a couple gifs of some of the platforming in action:
https://gfycat.com/FixedPaltryDodobird
https://gfycat.com/VillainousHardtofindJerboa
And a couple gifs of some of the platforming in action:
https://gfycat.com/FixedPaltryDodobird
https://gfycat.com/VillainousHardtofindJerboa
tamaster92
Member
Game is now remade up to adding weapons and i've now started on that.
Going mostly smoother so far as the gif shows. Watch the top left and you can see it IDs what weapon is currently equipped in the primary slot
Need to just make it extend from there and change anim states etc like before
Going mostly smoother so far as the gif shows. Watch the top left and you can see it IDs what weapon is currently equipped in the primary slot
Need to just make it extend from there and change anim states etc like before
"oh cool, iTween has a shake animation huh? let's see what this does..."
https://www.youtube.com/watch?v=ZxTvWXKYwUc
oh
......oh
I... I want to use this
https://www.youtube.com/watch?v=ZxTvWXKYwUc
oh
......oh
I... I want to use this
#screenshotsaturday I s'pose
http://gfycat.com/OrnateWickedAmericanbittern
Decided to change the control method to be direct 1:1 of the accelerometer, rather than the old method of the player moving towards the inputed destination. Still have to tweak things, smooth out the accelerometer data. I might make the circle arena smaller as the player doesn't seem to have enough time to react to the enemies because the arena is so big and covers most of the screen, especially when they're going fast and there's a bunch of them being thrown at you at once.
http://gfycat.com/OrnateWickedAmericanbittern
Decided to change the control method to be direct 1:1 of the accelerometer, rather than the old method of the player moving towards the inputed destination. Still have to tweak things, smooth out the accelerometer data. I might make the circle arena smaller as the player doesn't seem to have enough time to react to the enemies because the arena is so big and covers most of the screen, especially when they're going fast and there's a bunch of them being thrown at you at once.
HandsomeCharles
Member
And now it's my turn to have critical eyes cast upon me!
This is what I knocked up today. The floor tiles and a building. It's still very much a WIP. (There should really be a WIP Wednesday or something...)
Anyway, things I'm happy with:
Thing's I'm not happy with:
So yea, help me plz.. Anyone with experience on colouring, how to pick things that are vivid without being garish? I'm gonna try and make that thing a bit less lime now...
This is what I knocked up today. The floor tiles and a building. It's still very much a WIP. (There should really be a WIP Wednesday or something...)
Anyway, things I'm happy with:
- The line art
- Shading...maybe?
- The steel-colour
Thing's I'm not happy with:
- All other colours
- Details (More to be added though)
So yea, help me plz.. Anyone with experience on colouring, how to pick things that are vivid without being garish? I'm gonna try and make that thing a bit less lime now...
tamaster92
Member
Very quickly I got it working at a basic level
http://gph.is/1U2owwK
Unfortunately the new skeleton won't work with those nice anims I had before so back to really shitty for a while when it comes to holstering and drawing weapons D:
http://gph.is/1U2owwK
Unfortunately the new skeleton won't work with those nice anims I had before so back to really shitty for a while when it comes to holstering and drawing weapons D:
liliththepale
Banned
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!
A quick tip is don't be afraid to adjust the hue as you shade and highlight things. Something looking colorful is more about diverse hues than it is about high saturation.
http://www.nodontdie.com/rebecca-heineman/
Thanks to Pehesse for linking to it on Twitter last night!
A quick tip is don't be afraid to adjust the hue as you shade and highlight things. Something looking colorful is more about diverse hues than it is about high saturation.
Jacksinthe
Banned
Have this booked to read this evening thanks to you and Pehesse!
HandsomeCharles
Member
A quick tip is don't be afraid to adjust the hue as you shade and highlight things. Something looking colorful is more about diverse hues than it is about high saturation.
Thanks,I'll give that a go and see what I can come up with!
Yeah, it's a tough, but fair assessment! (and that Doom 3DO story...). There was a thread about it here earlier, but I'm glad it gets as much exposure as it can, and probably should!
(oh, and very cool color advice and examples!)
liliththepale
Banned
My first instinct was actually to share some of your designs because I think you've mastered the art of picking different hues for shading, but I thought pixel art was a little more apt for what HandsomeCharles is doing. The principle is universal though.
That's too nice of you to say
That pixel art is sure sweet, indeed!
In other news, I'm beyond excited since I've talked to Morusque about my next project (jumping the gun much?) and he agreed to try out some melody experiments... and listening to how it's shaping up, this is going to be hot fire! Too bad it's going to be years before it all sees the light of day ;;
HandsomeCharles
Member
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!
- Status