|
Mine's an ARPG in a simulator-powered living world, so it tends to be 15-30 NPCs spawned in your immediate area, and hundreds more being driven by a simulator. Right now the simulator moves people around and massages their stats in large batches for efficiency's sake, and when you load a chunk the simulator spawns every NPC in that chunk and stops simulating them. Actual NPC objects come with their own, much more intelligent AI that drives them around while they're in sight, then the moment you get far enough away they despawn and go back to being run by the simulator. I was thinking about running everything through a single manager mainly as a way to avoid the constant handing an NPC back and forth between simulator and rendered level, and because it would theoretically let me add more detail to the simulated NPCs by having everyone follow the exact same rules and only spawn models as a visual indicator of what the simulator was already doing. The only problem is that by definition, spawned entities are going to want much more intelligent AI that updates faster than a simulated guy, so I'm arguing with myself over how the cost-benefit for each approach.
|
# ? Jan 23, 2015 05:40 |
|
|
# ? May 26, 2024 05:24 |
|
Nition posted:My AI code is per-vehicle but with a central manager that vehicles register to so they can also get information on each other if needed. But I also have no idea what I'm doing. Next Game, I'm thinking about adding a layer above that designed to create "interesting group dynamics" that are patterned instead of random. The primary use case is the kung fu circle concept, to avoid mobbing the player, but it'll probably extend from there. Still no gigantic over-AI controlling everything, though - the individual actors will just get some extra hinting/data from the group AIs. ... and if I were so inclined, I'd layer ANOTHER AI over that, which controls the really gross scale stuff, like "this town" or "that group of bandits walking down the street", but it wouldn't really control the individual AIs, it would just simulate that over-state. The second the individual bandits came into being near the player, they'd be independent actors again with minimal grouping AI. EDIT: Omi no Kami posted:I was thinking about running everything through a single manager mainly as a way to avoid the constant handing an NPC back and forth between simulator and rendered level, and because it would theoretically let me add more detail to the simulated NPCs by having everyone follow the exact same rules and only spawn models as a visual indicator of what the simulator was already doing. Otherwise, you're going to miss out on all the fun emergent stuff that players might do when interacting with your AI in unexpected ways. Or you'll go crazy trying to hard-code reactions to all of those states in your giant controls-everything AI. Shalinor fucked around with this message at 05:49 on Jan 23, 2015 |
# ? Jan 23, 2015 05:44 |
|
That makes a lot of sense... it also goes a long way toward unconfusing tickrates for AI updates, as the spawned AI need to be pretty expensive to head off delayed reactions- I've been finding that a state update every 0.3s or so looks about right. Speaking of states, am I right that an extremely simple FSM is probably the way to go for the intelligent, spawned NPCs? I store every category of interaction as a queue of steps, e.g. Action.MakeBurrito.stepQueue.Enqueue (gatherIngredients, prepareIngredients, assembleBurrito,eatBurrito), and I have no idea how to iterate through the queue without holding up other processes, so I was thinking it might make sense to build a barebones FSM, assign each step to a state when the action started, and just let my FSM take care of yielding to the main thread when needed.
|
# ? Jan 23, 2015 06:11 |
|
Omi no Kami posted:This might be an obvious question, but does game AI tend to be asynchronous, as in each NPC running their own logic internally, or synchronous, as in a manager class iterating through every active NPC and tinkering with their state machine? I've been doing the former, but it occurred to me that the latter would let me draw significantly fewer distinctions between on-screen NPCs and inactive ones that stray too far from the PC. In both of the game AIs that I've written (one grid based, one arbitrary) I've run them both off the global 'update' method. In the simpler, grid-based system, I did all of the thinking in a single class, which I called the 'director-' I was foolish and the game was way smaller in scope than my current project, but the result worked (took hours to find all of the bugs, though). In the new system I'm using a strategy pattern where each creature has its own copy of a "brain" class that makes decisions for it- these strategies can swap themselves out whenever they need to. My 'swarm' brain has a method called 'goPassive' which it runs if the player is too far away, which swaps the creature's brain out for a 'wander' brain. The wander brain has a corresponding 'goAggro' method that swaps in a swarm brain if the player is close enough. I'm finding the second to be way, way easier to play with, mostly because I've started to use a lot of interfaces and abstract classes like a good little coder. E: I suppose the other question to ask is how smart they need to be. A lot of fun player strategies in ARPG games rely on the enemy being obligingly dumb, and that can be extremely fun- circle strafing enemies into a tight group and then dumping a giant AOE fireball on them is the sort of thing I love doing and it's impossible to do that if the enemies are working in coordinated flanking groups. Making enemies tactical and cover-friendly made Bulletstorm a lot less fun than it should have been. Somfin fucked around with this message at 10:10 on Jan 23, 2015 |
# ? Jan 23, 2015 10:03 |
|
That's really useful feedback, thank you! I'm curious, how did you handle switching between the brain and the state it decided on? I tried a similar approach a while back, and the problem I had was that jumping back to brain every so often would effectively restart whatever task the NPC was on, and creating checks to remember where the AI was and resume from that point if the brain decided it should keep at its current behavior turned into a schizophrenic, impossible-to-manage mess.
|
# ? Jan 23, 2015 10:20 |
|
Omi no Kami posted:That's really useful feedback, thank you! I'm curious, how did you handle switching between the brain and the state it decided on? I tried a similar approach a while back, and the problem I had was that jumping back to brain every so often would effectively restart whatever task the NPC was on, and creating checks to remember where the AI was and resume from that point if the brain decided it should keep at its current behavior turned into a schizophrenic, impossible-to-manage mess. I'm working with a custom-coded engine at the moment, and I'm yet to try to do anything fancy with it, so take all of this with a grain of salt. But basically, my AI brains are nearly static- none of them know anything about the creature they're attached to on their own. For all methods, they are passed the creature they're attached to and think from there. Any information about the world is pulled from the creature's link to the world it is part of. The creature's actual state, and chosen actions are handled separately from the brain. If a creature is in an attacking state and suddenly switches to a peaceful brain, he'll finish the attack which was in progress (because that executes on the creature's body), but he won't start another one, because the new brain won't return true when asked if the creature is ready to attack. All brains follow an interface that lets them pick direction and speed and detect where to shoot, but movement is handled by the creature's body. Creatures have a method to replace their brains with any other brain at any time, and movement and attacking is handled by creatures submitting action objects to a queue which then processes them in order. So, to give a live-fire example, my basic green swarm dudes start out with a 'swarm' brain. As creatures, they are called on to submit an action every tick. That action is drawn from their brain. They have a move method that makes them fan out slightly- their brains have a relative direction option that randomly makes them veer a bit left or a bit right for a few ticks before going back to direct charge. If they are close enough, they'll detect the player's direction from themselves and issue a command to attack in that direction, as well as issuing move commands. If they get far enough away, though, during the 'detect best direction to move' step the swarm brain will detect that it is too far from the player. At that point, it'll tell the creature that its brain is now a brand new 'wander' brain, and issue a final command to not do anything (since the action submission method still needs to return something). If the creature is in the middle of an attack action or something, that will still resolve, because that is handled by a timer which is attached to the creature, rather than its brain. On the next update when it is free to act, the green guy will ask his brain what its action is, and the brain- which is now a 'wander' brain- will pick a direction to wander in for the next few ticks and then return actions which are 'go in that direction' for a while, then pick another direction. Each update, that brain will check the distance to the player, and if the distance is short enough, it'll tell the creature that its brain is now a brand new 'swarm' brain and issue a command to do nothing. The new swarm brain will take over in the next update step and most likely issue a command to charge the player. E: I don't know if this is actually a good solution, but it works for the way I've set things up and the general dopeyness levels of the enemies I'm putting together. Once I start making smarter guys who can do pathfinding and actual ranged attacks, it's gonna get quite interesting. Somfin fucked around with this message at 11:09 on Jan 23, 2015 |
# ? Jan 23, 2015 11:00 |
|
Animation clean-up process video in Toon Boom, if anyone's interested. Also the result gif:
|
# ? Jan 23, 2015 12:08 |
|
Mr Underhill posted:'grats dude! Oh how I envy you Americans with your fancy conventions and publishing deals and... seriously, that's great news. Good to see goon devs getting recognition! He's not American Which is why I'm extra stoked to see Guild Of Dungeoneering doing so well!
|
# ? Jan 23, 2015 12:46 |
|
Whoops, my bad! Congrats either way!
|
# ? Jan 23, 2015 13:43 |
|
Shoehead posted:He's not American Yep I'm from Ireland. There's 5 people working on the game now: 3 Irish, one English and one Australian. This publishing deal was done entirely over Skype. I just met the VS Evil guys in person today for the first time (I'm in Texas now, just about to head into 1st day of PAX). Where you are based is NOT as big a deal as it once was!
|
# ? Jan 23, 2015 14:17 |
|
Shalinor posted:I'm not seeing a dev comment, did it go private somewhere? Is it someone you can send (polite) messages or emails to, now? If so, you REALLY need to get on top of things, be super nice, and communicate you weren't thinking you'd get quite THIS many people / things got out of hand quickly. This is a good idea, definitely reply to that Valve comment you got with something along the lines of what Shalinor says above. We did a giveaway w/ the same group last April (though I'm concerned to hear they now CHARGE for the service, so I won't be recommending them anymore). You can see the effect they had on our votes graph here, the spike at day 20 or so:
|
# ? Jan 23, 2015 14:25 |
|
Also there are Valve goons that probably read this place, so you should be wary of openly posting about buying your way to the top.
|
# ? Jan 23, 2015 17:17 |
|
Pfft, everyone knows Valve employees do nothing but crack "valve time" jokes and wait for the next Steam sale to keep their paychecks coming.
|
# ? Jan 23, 2015 17:38 |
|
It's soon screenshot saturday:
|
# ? Jan 23, 2015 21:03 |
|
Somfin posted:I'm working with a custom-coded engine at the moment... This is incredibly helpful, I really appreciate your taking the time to describe your process
|
# ? Jan 23, 2015 22:56 |
|
Omi no Kami posted:This is incredibly helpful, I really appreciate your taking the time to describe your process Glad to be of assistance! Assuming, of course, that major problems don't show up later that I'm just blissfully unaware of.
|
# ? Jan 23, 2015 23:16 |
|
Anyone else doing the GGJ this weekend?
|
# ? Jan 24, 2015 00:51 |
Superrodan posted:Anyone else doing the GGJ this weekend? Sort of. I'm working remotely with a bunch of guys halfway across the country.
|
|
# ? Jan 24, 2015 01:05 |
|
That's what I'm doing too, actually. In past years I've done the "get little to no sleep and spend all my waking hours with a bunch of local friends/strangers" thing but this year I decided to basically jam part time over skype with a group who lives in a different city. I told them I'd give them about 20 hours of work on whatever miscellaneous tasks come up. I think it will be a good balance of participation and being able to see loved ones.
|
# ? Jan 24, 2015 01:24 |
|
Superrodan posted:That's what I'm doing too, actually. In past years I've done the "get little to no sleep and spend all my waking hours with a bunch of local friends/strangers" thing but this year I decided to basically jam part time over skype with a group who lives in a different city. I told them I'd give them about 20 hours of work on whatever miscellaneous tasks come up. I think it will be a good balance of participation and being able to see loved ones.
|
# ? Jan 24, 2015 04:37 |
|
Cool well, just spent 3 hours first finding weird behavior issues cross build, tracking it down to assets not saving, beating my head in a troubleshooting hunt until I figured out unity was just not saving anything at all, failing totally silently on the asset save process, and eventually finding this: http://forum.unity3d.com/threads/please-help-totally-blocked-cannot-save.286566/ FYI
|
# ? Jan 24, 2015 05:34 |
|
God, what a loving nightmare. Also great is when you update to a new unity version, and all of a sudden it crashes immediately without any error messages when loading a scene that was completely fine and still works in the previous version. Becomes a real fun game of painstakingly deleting and reinserting objects until the one thing the new version doesn't like is found.
|
# ? Jan 24, 2015 07:32 |
|
Well, I made the player lay bombs. ...but I accidently made them all controlled by the player controller. So they each lay a bomb when you hit the button, and all move under the same controls. It all works properly over the network though
|
# ? Jan 24, 2015 20:37 |
|
Screenshot Saturday - so one of the projects we're working on now is a multiplayer typing party game. It's getting very close to finished! There are 8 minigames, here are gifs of four. Crosstyper: This looks strangely familiar but I assure you the idea is 100% original! Type letters to make cannons fire, which knocks pucks into the other player's goal. Typing Tennis: It's basically like Pong, whoops, I meant to say that the idea is 100% original! Type the word before the ball reaches your side! The ball goes faster and faster with time! Blimp Buddies: Each player controls one captain. You must use cannons to fend off enemies and refuel your engine once every minute or so! Keyboard Critters: If you're the pink player, press a pink key when a critter hops on! Make sure you don't press keys of the other player's color, or else you'll score a point for the other person! Making minigames is fun but wow, you know how they always say the last 5% is the hardest? That's especially true when you're essentially making 8 separate games at once (even a game like Sportsfriends only had 4 games, and a much larger team). Each of these games took maybe 1 or 2 full days to "get working," but finishing them - totally polishing each one up, making sure it's fun and bug free, has sounds, has music, has a tutorial, doesn't leak memory, etc - takes a while when you're dealing with 8 games. I think I'll have another coffee now. Polo-Rican fucked around with this message at 21:54 on Jan 24, 2015 |
# ? Jan 24, 2015 21:45 |
|
All of those animations look great Polo-Rican.
|
# ? Jan 24, 2015 21:55 |
|
Hey everyone! Have been reading the thread for a while but never really knew what to say here. Might as well start today, because I had a pretty funny experience. I'm sure there was a better way of doing this, but I ended up doing something really silly to get a background to animated the way I wanted to. It's still not even close to being perfect, but at least it's moving the way I want it to. Now I just have to decide which curtains I want to get moving and work from there. I couldn't get Unity's cloth system to work right. The cloth system doesn't take Wind Zones as input and external acceleration had a few bugs I couldn't work around, so instead I just went down a very silly route and made a small sphere, turned off the mesh renderer and animated it going back and forth pushing the curtain aside. Now it's really like the place is haunted!
|
# ? Jan 24, 2015 22:39 |
|
Playing with shaders Needs more tweaking on the leading edge of the glow.
|
# ? Jan 24, 2015 23:19 |
|
Hello world This is a spaceships simulator, I'm calling it I wonder what you guys think of the style? We're just two fools, neither of us a good artist. We can model but are absolutely terrible at anything else so we came up with... untextured models. I'm starting to feel like it looks kinda decent so I thought I should post to see if maybe it looks terrible instead. It just happens to be saturday as well.
|
# ? Jan 25, 2015 00:28 |
|
It looks fine. I don't think it's an issue that they're untextured, just makes it look sort of like sleek Star Trek-esque minimalism.
|
# ? Jan 25, 2015 00:56 |
|
Man, too much awesome in this thread this weekend. Keep it up!
|
# ? Jan 25, 2015 00:56 |
|
shimmy posted:Hello world Something I'd like to see (if this is based on a Star Trek aesthetic?) is something more streamlined in the 'rooms', and the real meaty machinery technical stuff behind the wall in a sort of hidden engineering passage. The rooms look interesting, but they look a lot like empty rooms with some furniture put in. That'd be fine if this was an office building or something, but for a highly designed and no-wasted-space starship, it looks sort of odd. It should be either more wall panel type interactive displays, OR my previously suggested behind wall hidden (but still accessible) tech guts. Or you could try increasing the size of your tech bits. There's some larger things I see which is great, but the smaller ones let it all down. It makes huge wasted areas. Hope I'm not being too harsh. It does look cool, but it needs a bit of design tweaking. edit: oh and something else you could do that a few games have done is assign room types to each room, and have corresponding wall texture and details that tie in and match the theme of the furnishings. edit 2: ok last thing, would curved or 45 degree angled walls be too much to ask? KiddieGrinder fucked around with this message at 01:14 on Jan 25, 2015 |
# ? Jan 25, 2015 01:02 |
|
KiddieGrinder posted:Something I'd like to see (if this is based on a Star Trek aesthetic?) is something more streamlined in the 'rooms', and the real meaty machinery technical stuff behind the wall in a sort of hidden engineering passage. I see it, I've thought it myself before. Hiding away the machinery in other rooms doesn't make sense to me but they should be integrated better. The thing is that every object is an upgrade the player places (though no room starts out empty), so it kind of has to be a simple generic room to begin with. I'm thinking better object designs that reach to the floor and ceiling should break up the square outlines. Right now a lot of stuff sits on legs which is silly. It all looked ok in the empty void where it was modeled! Tilesets per room are already in, it's just we'd have to make them before we can put them in. You can see the corridors have different walls than the rooms, that's using that system. And with that you've seen all tilesets we have right now Angled walls? You are correct, that is too much! The exterior of the ship will be modeled, pending final layout of the interior, so it won't be a big blocky thing floating in space. Few games have angled walls, I don't think that's going to be a thing people will mind when all is said and done.
|
# ? Jan 25, 2015 01:31 |
|
Ah that makes sense then.
KiddieGrinder fucked around with this message at 20:06 on Jan 25, 2015 |
# ? Jan 25, 2015 01:34 |
|
When you guys say something takes a day or two days, do you mean 8 hours coding or..?
|
# ? Jan 25, 2015 01:38 |
|
shimmy posted:Hello world (a lot of what I'd like to do to improve my HTR visuals, but probably won't have time for, is stuff you could do - you basically need to make it look "less Unity")
|
# ? Jan 25, 2015 02:19 |
|
We are not far enough into it to worry about it on that level. Except for palette, but for us it's just vertex colors.. easy to change but we will need someone with an eye for it. Anyway I want to stay aware of what should change but can't say when any of it will happen. First I want to get to gameplay, asap. Right now all you can really do is watch the crew move around... and call battlestations to mess with the guys taking a break. BATTLESTATIONS!!!
|
# ? Jan 25, 2015 04:49 |
|
I'm getting a kind of Evil Genius vibe from that gif, which is a good thing. One of the best parts of that game was to just kind of play ant farm and watch all your minions going about their routine and responding to alerts.
|
# ? Jan 25, 2015 05:13 |
shimmy posted:We are not far enough into it to worry about it on that level. Except for palette, but for us it's just vertex colors.. easy to change but we will need someone with an eye for it. It's pretty neat :p I would say create some more color variations between the different rooms to make it easier to find it's utility. One of the things I want to add to my game as is, is a better indicator of what each thing does
|
|
# ? Jan 25, 2015 05:15 |
|
Obsurveyor posted:Playing with shaders Looking really cool. shimmy posted:We are not far enough into it to worry about it on that level. Except for palette, but for us it's just vertex colors.. easy to change but we will need someone with an eye for it. I think Shalinor nailed it, the models actually look fine. I personally like the style you're going for. The issue is basically everything that is fortunately easily fixable, mostly the lack of lighting.
|
# ? Jan 25, 2015 05:21 |
|
|
# ? May 26, 2024 05:24 |
|
If you have time to UV unwrap your models, one thing you could do is just do an ambient occlusion pass in your modelling program and make that the texture, and it'll improve the lighting look a bit.
|
# ? Jan 25, 2015 05:25 |