-
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.
Indie Game Development Discussion Thread | Of Being Professionally Poor
- Thread starter chubigans
- Start date
- Status
I love those character portraits, and that breakdancing move looked beast.
Heart of Black
Member
THANKS!
The PERFECT word.Is this a turn-based beat-em-up RPG?
YEP! Although real time movement and striking is very important
Thanks! I kinda slave over those, they can take 3+ hours, each at times, especially with drawing them in sketchpad first, then fix a lot of things later and my wife helps me with that quite a bit.
Rad is definitely a good word for this. I would love to check it out sometime.
Quick look reveals a child trigger box approach. Platform collision is toggled by enter & exit of child trigger box: http://answers.unity3d.com/questions/362021/eficient-one-way-collider.html
Seems pretty good! Might have to be careful with jump speeds and trigger box sizes, but should work okay.
SlipperySlope
Banned
First in-game screenshot.
I tried this approach for a while before abandoning it, the problem is it sort of works but can result in the collision suddenly resolving and popping all the way through. Since it was so close to working I tooled around with it for a while before abandoning it and checking for the characters position and switching colliders on and off based on where they were.
Using trigger volumes is also a strong way to do it, but in my case I was making a platformer with platforms you could jump through from underneath, so knowing the character was above or below the platform was all I needed. (in the end I ended up having to retrofit co-op gameplay, and toggled layers a lot - when one player was above the platform but the other wasn't, I had to switch the platforms layer to one that collided with the first player but not the second. Had a fun little matrix going. Good thing no one was asking for four player...)
I've been making progress on my game! Added the last of the unique basic enemy types! It's a skeleton guy who can teleport around and fires lasers at your current position.
he ended up working pretty well since he'll just jump around and try to snipe you whenever he gets the chance. I also want to do a variant who still teleports but will spam bullets instead. They should be a fun pair.
Which mimics an index addressing scheme on the PDP-11, yet is was used in B.
The PDP-11 had a special index addressing mode, i.e. <operand> n(rx), with rx
a register and n a displacement, i.e. the register is added to the
displacement to produce the address of the operand, for example; add 2(r1),r2
adds the the content of address r1+2 to r2. So whenever a constant is used
either as the base or as an index, index addressing could be used making
execution times faster while additionally saving some instructions giving C
sort of a boost on the platform.
I decided I didn't really like my network rigidbody stuff so I spent another day reprogramming it.
Figured I'd give interpolation another try. Whatever it is, I can't seem to get it down properly. The problem I have is when I run out of fresh data to interpolate to, it causes some ugly stuttering as the server feeds it new info.
So, I looked into getting extrapolation going. I found that if I just take the last 4 packets of data, and work out the logical next packet, everything runs pretty darn smooth. I knocked down the Unity sendrate to 20, and made it so the extrapolate stuff would only refresh a new goal position once every few frames.
This solution works pretty well with around 200ms of latency between two players. It gets a little gross when more players join.
I'm gonna play around with the sendrate and how many points to pay attention to for the extrapolation, try and see what's gonna get me smooth results.
I think I'm still sending too much data across the network, though. Players moving around eats up about 1kBps of bandwidth, and manipulating objects can bump it to 5kBps per player doing that. The worst it gets is 60kBps which might be causing some noticeable delay, though it could also be the extra debug calls.
Ideally I'd like to have it dynamically switch between interpolation and extrapolation, but when I try it just seems to cause crazy inconsistencies and stutter. But to be honest at this point I'm going to take the "good enough" approach and focus on getting the last few features of my build bug free before jumping back into network optimisation.
Figured I'd give interpolation another try. Whatever it is, I can't seem to get it down properly. The problem I have is when I run out of fresh data to interpolate to, it causes some ugly stuttering as the server feeds it new info.
So, I looked into getting extrapolation going. I found that if I just take the last 4 packets of data, and work out the logical next packet, everything runs pretty darn smooth. I knocked down the Unity sendrate to 20, and made it so the extrapolate stuff would only refresh a new goal position once every few frames.
This solution works pretty well with around 200ms of latency between two players. It gets a little gross when more players join.
I'm gonna play around with the sendrate and how many points to pay attention to for the extrapolation, try and see what's gonna get me smooth results.
I think I'm still sending too much data across the network, though. Players moving around eats up about 1kBps of bandwidth, and manipulating objects can bump it to 5kBps per player doing that. The worst it gets is 60kBps which might be causing some noticeable delay, though it could also be the extra debug calls.
Ideally I'd like to have it dynamically switch between interpolation and extrapolation, but when I try it just seems to cause crazy inconsistencies and stutter. But to be honest at this point I'm going to take the "good enough" approach and focus on getting the last few features of my build bug free before jumping back into network optimisation.
Thanks for the input guys! I think I'll give the trigger box approach a shot.
Loving the progress on Android Cactus Assault, Sycle! It's quite inspiring seeing that game come along.
"Hey why is my navmesh generation making mistakes here?"
Because adding boxcolliders in Unity keeps the boxcollider as an AABB, and there's no way to programmatically change it.
Apparently the only way is to generate your mesh as axis aligned, add the boxcollider and then rotate the mesh to what it's supposed to be... or in my case, rotate to axis aligned, move to origin, add the collider, then invert the rotation again and move it back to where it's supposed to be. Sigh.
How hard would it have been to expose local rotation for the collider?
Because adding boxcolliders in Unity keeps the boxcollider as an AABB, and there's no way to programmatically change it.
Apparently the only way is to generate your mesh as axis aligned, add the boxcollider and then rotate the mesh to what it's supposed to be... or in my case, rotate to axis aligned, move to origin, add the collider, then invert the rotation again and move it back to where it's supposed to be. Sigh.
How hard would it have been to expose local rotation for the collider?
I've been making progress on my game! Added the last of the unique basic enemy types! It's a skeleton guy who can teleport around and fires lasers at your current position.
he ended up working pretty well since he'll just jump around and try to snipe you whenever he gets the chance. I also want to do a variant who still teleports but will spam bullets instead. They should be a fun pair.
The remnants from the giant laser beam are supercool
No need for extra colliders. Just check to see where the player is in relation to the platform collider and switch it on/off as you need. If other objects are needing to use the platform to stand on just exclude the player from collision until the player is above the object. Ideally, you want to have it on at all times until the player gets close enough from underneath, switch it off, then when the player gets Y distance above the object, switch it on. No extra collider's needed.
Ideally you would just check distance with a raycast for the easiest approach and only allow the player's collider to pass thru until the raycast leaves the platform collider.
Edit: I should note we use raycasting for all checks instead of colliders to make stuff like this easy for us and add and remove functionality as needed. We like Unity's collider's but raycasts are still a must, IMO.
I'm also intrigued by one-way platforms, since computing which objects can go through it on a case-by-case basis is way too resource-intensive, but using layers would become a nightmare as things would go out of hand quickly with each added actor that interacts with them.
I've been thinking about giving the platform a trigger collider that begins just below the platform's surface (so objects that are standing on it don't touch the trigger), and using the OnTriggerEnter and OnTriggerExit events to, somehow, add the colliding object to a list of objects that can be allowed through, and remove it from the list when it's no longer touching the trigger. Taking a look at the Physics system just now, I see a Physics.IgnoreCollision method which'd probably work, but there doesn't appear to be an UnignoreCollision one to make the player hit the platform again...
I've been making progress on my game! Added the last of the unique basic enemy types! It's a skeleton guy who can teleport around and fires lasers at your current position.
he ended up working pretty well since he'll just jump around and try to snipe you whenever he gets the chance. I also want to do a variant who still teleports but will spam bullets instead. They should be a fun pair.
Amazing! I had a blast playing AAC with my cousin a while ago, since I'd rather not play it alone as it's infinitely more fun in multiplayer. It's the first game I've ever bought Early Access on, and it's great to see it coming along so nicely. Can't wait for the full game!
Does player raycats above the player intersect with collider tag ?
If yes, allow object with player tag to pass thru.
Does the player raycast below the player intersect with collider tag?
If yes, allow object with player tag to collide.
No extra anything. Just use tags and raycasts and include/exclude collision by tag "player" or whatever you call him
Does player raycats above the player intersect with collider tag ?
If yes, allow object with player tag to pass thru.
Does the player raycast below the player intersect with collider tag?
If yes, allow object with player tag to collide.
No extra anything. Just use tags and raycasts and include/exclude collision by tag "player" or whatever you call him
Oh, that'd certainly work, but since the player would be doing the collision checks, you'd have to do some wacky stuff if you ever wated to make one-sided platforms that can't be passed through from below, or from either side. Moving the checks to the platforms themselves to make sure each object controls itself only would increase the order of complexity from <number of objects that can go through one-way platforms> to <number of one-way platforms>, and mere raycasts wouldn't be enough since a platform's dimensions would require checking against a cube instead.
I'm just trying to think of an implementation that's as versatile as possible here, but I'd say your algorithm works perfectly fine for most cases.
Talking about platforms, does anyone know what's the best algorithm to use for making an object move alongside one? Unity's default FPSController appears to do it on its own, even keeping the platform's momentum when the player jumps off of it, but I haven't checked it out much since it's written in JS.
RelentlessRolento
Member
Hey guys, I just released the first public alpha for Another Castle, including a free web version. You can check it out at http://www.AnotherCastleTheGame.com and let me know what you think!
Also, here's a baby fire dragon
looks nice!
plus looks like someone is paying attention to GAF:
http://indiegames.com/2014/02/another_castle_is_still_coming.html
You dont need to do anything wacky for collisions with walls. If you are raycasting from the player in multiple directions then the only thing you can allow is movement along vertical raycasts and intersections with walls stop the player as they should. Its just what's under the player's feet we are looking for.
Its probably more difficult to implement with Unity's controller and collision but we write our own controller, physics and collision to offset these issues in the event we need to add or change functionality we have the ability to do so late in development without breaking the rest of the game. So if you are using built in controller and such it will be a bit more of a workaround to add functionality. Rolling your own methods is preferred, IMO.
I mean, each implementation for one-sided platforms would have to be different, since the ones we've talked about so far only use collisions when the player is above them, but perhaps you might want to make platforms that the player can't move through from below or the sides. What I was getting at was that having the player object handle those colissions could lead to sloppier and less modular code, as opposed to letting the platforms themselves tell each actor whether they're solid for them or not.
Still, I'm asking this more for research's sake than anything else, because I'm still trying to wrap my head around implementing these kind of physics systems I've let Unity handle for me so far.
Its not messy. This is what tags are for. If you raycast to check for collisions in various directions you can simply tell the player and physics to behave a certain way based on what it collides with and distance to/from collision. There's nothing to implement on individual gameobjects other than a TAG and far easier to control from a single object that just does checks for specific tags then switches a bool or performs a method depending on the check.
Tag FromBelow - one way UP
Tag FromTop - one way down
Etc.
The player is the only place you need to do checks. You dont have to create multiple platforms. I can take the same prefab platform and place it 20 times in my level and just change the tag and poof, the character's behavior acts accordingly to whatever I have him do depending on raycast intersection with Tag A, B, C, D, etc. This is what I mean about having flexibility to add or remove gameplay elements at will without breaking your game. At most when removing or adding a feature you just Click, change tag from the drop down since all methods are bound to the player and not individual objects. Tags are powerful as hell. No extra colliders, no custom code for every object you need to perform a certain way, just tags and the player script that looks for specific tags to do specific things. All your important code is in one place and you can edit to effect any way you like. I love me some tags, yo.
I guess I'm just not used enough to working with tags and layers in Unity. I only recently realized the kinds of things I could do with object layers, and didn't know what kinds of things tags were actually supposed to be used for.
BlastProcessing
Member
So our game, Ephemerid, has been nominated for the SXSW Gamer's Voice Award.
Which means that we get to have a booth at SXSW's "Indie Corner".
Which is cray.
I alluded to this earlier, but does anyone who has showed at a super-crowded venue have any tips/advice? The Games portion of SXSW is free and open to the public, so it's always packed. The current plan is to get some Ikea armchairs, footrests, and decent noise-cancelling headphones and set up some comfy stations where people can chill and play.
I have also been working on some marketing material, which has been a fun side project.
This would be the front:
And the back:
Which means that we get to have a booth at SXSW's "Indie Corner".
Which is cray.
I alluded to this earlier, but does anyone who has showed at a super-crowded venue have any tips/advice? The Games portion of SXSW is free and open to the public, so it's always packed. The current plan is to get some Ikea armchairs, footrests, and decent noise-cancelling headphones and set up some comfy stations where people can chill and play.
I have also been working on some marketing material, which has been a fun side project.
This would be the front:
And the back:
It's just IgnoreCollision itself. The third parameter is the bool to set ignore/unignore.
SlipperySlope
Banned
Ihateyouchris
Member
Ha cool! I was actually just about to email them earlier today and I then I saw the article.
As a tidbit, this function was forgotten about in Physics2D
I think it's more of a factor of "our totally different physics engine for 2D doesn't have that option"
I think you can do it if you create a custom editor. Of course, making a custom inspector editor for everything is kinda... eh.
Then make it. Define "physics". Force and rotation. In other words, accelerated movement, decelerated movement (drag) and rotation.
If you know how to move a character along an axis and rotate it by pressing buttons - you just made 99% of your physics engine. Now make movement and rotation when not pressing buttons. Now make it work against pressing buttons. POOF: http://www.youtube.com/watch?v=IS7Og1zvdy8
Now we can set bools to change how that movement works for or against you based on states for even greater control of the character and really tweak it. Now we can create even more dynamics to our game by altering the player's "physics" without having to create external forces that act upon the player. We just control the player, itself. We can adapt this for enemies, too. We can even use this for multiple projects! Increase/decrease complexity as we see fit for dynamics without being tied to Unity's built in stuff.
Collision vs physics. Did you collide? No. Keep moving. Did you collide? Yes. How far is your raycast entering the object? Do we need to move the object back out of an overlap before drawing and if so, by how much of the raycast? POOF - collision. So if our bottom raycast is touching a ground tag, object or layer, we stop downwards movement. Are we not touching? !grounded
I'm going to get every damn Unity user to stop using Unity's built in physics, collision and player controller if it's the last thing I do!
Good luck with that
I put up with PhysX because, well, PhysX and I don't want to fall into the trap of rebuilding systems for everything from scratch again.
That's how most of my other projects died on the cutting room floor.
Edit: The fact that they added 2 totally different black box physics systems is still crazy, of course.
AxiomVerge
Neo Member
What do you guys think of this? (Ignoring the fact that it's playing at 16 fps).
I was contemplating adding some dust, rain, or other weather effects. Too much? Not enough? It's likely to be the first "cinematic" shot after starting a new game, so if I take a bit longer making it look better, that's okay.
Hm... Looks good, but I'd add something in the grey area. Dust or a forest or things that flesh it out more. It seems a bit... bare at the moment.
Even rain would work to break up the monotony.
Your game looks cool. Enjoy the venue!
AxiomVerge
Neo Member
Hmm, in my head a forest looks good, or some smaller hills, in typical NES repeating tile fashion, of course.
Yeah, you would think there was an easier way. Custom Editor is way to cumbersome for something like a simple name change.
Ihateyouchris
Member
What do you guys think of this? (Ignoring the fact that it's playing at 16 fps).
I was contemplating adding some dust, rain, or other weather effects. Too much? Not enough? It's likely to be the first "cinematic" shot after starting a new game, so if I take a bit longer making it look better, that's okay.
Looks great! I agree that a forest or hills in the grey area would look nicer, and I think rain would look pretty sweet as well.
Absolutely beautiful. What kind of game is this going to be for? Action RPG?
Damn that would be amazing, but no, these are just for me; they are for some sort of book I think! Probably a graphic novel of some sort
However, working on a ARPG, or CAG would be awesome. I want to!
Every time people have asked Unity to stop nicifying variable names in the inspector, they get a ton of other people jumping down their throat about how "it's fine like this" and "stop being so annoying", so... yeah.
You'd think they'd make it a toggle, tho.
taku
Member
So.. I made a "flappy bird" game yesterday.
Actually, I guess it's more of a helicopter game (hold mouse button to ascend, release to descend).
Either way, It didn't turn out the way I wanted, I just had to get it out of my system what with all the flappy talk.
Did anyone else make a flappy game?
Flappy flappy flappy.
Actually, I guess it's more of a helicopter game (hold mouse button to ascend, release to descend).
Either way, It didn't turn out the way I wanted, I just had to get it out of my system what with all the flappy talk.
Did anyone else make a flappy game?
Flappy flappy flappy.
Don't know why but this reminds me of an old game called Rush n' Attack (This looks better though).
Damn that would be amazing, but no, these are just for me; they are for some sort of book I think! Probably a graphic novel of some sort
However, working on a ARPG, or CAG would be awesome. I want to!
Well color me interested in that book!
don't know if I am doing it correcly, but at times it seems as if the whole way is blocked...
But I like the graphics. Would you like to share some insights on how the lighting is implemented?
Wow, this looks and sounds great... but is it me, or do you have to be really lucky not to have an impossible gap at the start?
Man, I hate how I'm staring at this generated triangle mesh with redundant vertices and polygons I want to simplify, and I know I've implemented this before, but I can't find it anymore... Time to start from scratch!
The guys I work with, Team Junkfish, did an announcement trailer for our survival horror game Monstrum yesterday.
Have a looky here and let us know what you think.
Have a looky here and let us know what you think
.The guys I work with, Team Junkfish, did an announcement trailer for our survival horror game Monstrum yesterday.
Have a looky here and let us know what you think
Looks cool! Survival horror is not my thing, but I like the aesthetic you guys have going.
Nicely polished trailer too.
- Status