|
I've just spent the past week shotgunning this thread -- thanks to everybody who's showed off their stuff, it's an incredibly useful resource! I've been working on a game in XNA in my spare time for just under a month. It's partially a project to teach myself more about C# and XNA, but if I get a cool game out of it at the end that I can share with people, so much the better. It's an arena shooter taking cues from Gauntlet, The Chaos Engine, and Alien Breed: my goal eventually is to add support for several players so that you can fight and loot your way through a series of randomly-generated levels with your friends. Also, it's Saturday, so here's some footage of the game. Last night I got line-of-sight working the way I want, which was a big confidence boost. I've stuck a (poorly-recorded) video on Youtube at https://www.youtube.com/watch?v=wphWb4tYMJw to show off what it looks like. The sprite graphics are still placeholders for now, either knocked together in MSPaint or nicked wholesale from a spritesheet.
|
#
¿
Jun 8, 2013 10:40
|
|
|
|
| # ¿ Apr 23, 2024 15:03 |
|
|
I agree -- most things that might be colliding move so quickly that it's unlikely a player will be in a situation where they can see the bounding box collided but the sprite didn't. Also, it's Saturday. Have some game footage! https://www.youtube.com/watch?v=cNaw3bRYfYk I've added in dynamic music now, so that the pace speeds up when there are enemies onscreen. The game could use a longer track, but I reckon the way it works is pretty sound. The next big goals are adding a health meter, so the character doesn't go down to a single enemy hit, and support for several players. My biggest worry here is line-of-sight, which is weighing up to be the most costly routine as it stands. One solution I've been toying with is to only give one player a light source, so they all have to bundle together, but I'm not sure whether that would be fun in practice or not. I also want to play with the AI for the roaches a bit: at the moment, the way they head straight for the player means that they have a habit of bunching up around a corner and then all mobbing you when you pass it, which isn't very fair. My current plan instead is to move them in fairly straight lines until they end up in line-of-sight, and only have them start chasing you then. That way they're less likely to all be clumped around a corner when you go around it.
|
|
#
¿
Jun 15, 2013 15:09
|
|
|
Some more videos for Sunday: https://www.youtube.com/watch?v=0vWYd6bKbHA shows the line-of-sight code now working with four simultaneous players. You can't see it, but I'm using quadtrees for collision detection now. This makes dealing with all the bullets four players can throw out run a lot more smoothly. E: While I'm posting, actually, one thing's been gnawing at me. Currently bullets are shot out of the centre of the players' hitbox, which means they appear to be shooting out of their feet. This looks pretty crap. I want the bullet graphics to be coming out of the player's gun, but then I have to choose between (a) The bullets' hitbox stays where it is, and the bullet graphic appear higher up. Upside: the bullets are still coming out of the centre of the player's hitbox, so if you stand directly left of something and shoot towards it, you'll hit it. Downside: the bullets don't match up with their hitbox on the screen. (b) The bullets' hitbox is higher up too. Upside: The bullets coincide with their hitbox on-screen. Downside: they don't coincide with the player's hitbox, so if he's up against a wall they just impact into that. (c) The player's hitbox covers all of his sprite. Downside: The player now gets hit by enemies who he's standing in front of. Does anyone have any suggestions on which of these is the least bad solution? Whybird fucked around with this message at 20:44 on Jun 29, 2013 |
|
#
¿
Jun 29, 2013 20:37
|
|
|
SupSuper posted:If you're moving one tile of a time, you can just check if the moved tile is still adjacent to at least one other tile. That won't work -- if it's in the middle of a chain one tile wide, you could move it so that it's adjacent to another tile but now the shoggoth is in two pieces. I think flood fill is the way to go.
|
|
#
¿
May 2, 2017 22:32
|
|
|
I'm currently getting to grips with what the 'right' way of doing things in Unity is, and one thing that's been puzzling me is how 2d tilemap editors are coded. The examples I've seen all create a separate Gameobject for every individual tile in the map, but it seems like once you start getting to any decently-sized levels this will give you a huge number of Gameobjects floating around, potentially each with their own colliders and things -- by instinct this seems to me to be a hugely wasteful way of doing things. Am I misunderstanding how Unity works, or am I just looking at editors that are designed for smaller maps?
|
|
#
¿
Jul 8, 2017 20:55
|
|
|
FuzzySlippers posted:edit: Has anyone ever done a boss rush rpg? Lots of games have fun and interesting boss fights with long tedious grindy sections in between. Like my experience with SMT/Persona is they have lots of interesting ideas but take way too long getting going and throw in too much tedium. Something where there's a management metagame (ala DD or something) with just boss fights could be fun. Banner Saga sort of does this: there are no boss fights per se, but every single battle is scripted and part of the plot, so you're never just fighting enemies to get from A to B.
|
|
#
¿
Aug 7, 2017 07:50
|
|
|
Kassoon posted:I think I've played 2 games where it was worthwhile to use buffs, and 0 where going all-in on pumping damage was wrong. I've always thought that the best way to get around this is to have every attack do damage -- so instead of choosing between doing damage and debuffing (which is normally a non-choice) the player is choosing between different and varying types of buff and debuff to the enemy.
|
|
#
¿
Aug 7, 2017 17:58
|
|
|
Yodzilla posted:Games where bosses are immune to various spells/debuffs/abilities for no good reason other than being bosses can go straight to hell. The flip side of this is that a debuff that takes an enemy out of the fight for a while is nicely balanced against regular enemies but completely game-breaking to use on a boss -- you can just keep the boss locked down while you whale on them, which doesn't make for a fun fight. There are a couple of ways to get around this -- you can have bosses recover from the more severe debuffs more quickly (but not so quickly that they feel worthless) or, the better solution to my mind, make sure bosses always come with a stable of mooks to keep the pressure up even if the players keep the boss locked down with debuffs.
|
|
#
¿
Aug 8, 2017 00:41
|
|
|
Zaphod42 posted:You can do it any way you want. The thing is, certain ways of organizing things are going to make development easier as you have to go back and make changes or add new features or fix bugs. That's basically the whole discipline of software engineering and nobody can really sum it up for you in a text blurb. This is a really good post, thank you! To someone who doesn't have 4 years at university to study these things but still wants to read up, are there terms other than Coupling and Cohesion to read up on that cover the things you'd take into account making these kind of decisions?
|
|
#
¿
Sep 19, 2017 17:07
|
|
But also maybe google around about code organization and best practices for your language.
|
Honestly, I think the biggest answer is simply not to have combat in the game. If you are trying to emulate the feel of a gritty detective drama, then having a character who can reliably win fights is going to run counter to that. It sucks that you've created a thing that is fun but you can't include, but there will always be other projects that you can slot it into after you're done here.
|
|
#
¿
Dec 15, 2017 17:13
|
|
|
I remember there were a few moments in the Monkey Island games where you would choose one dialogue choice and Guybrush would give a completely different answer, because he was too scared to speak his mind. Those were played for laughs, but I didn't feel like I'd been cheated when I was playing them.
|
|
#
¿
Jan 10, 2018 10:09
|
|
|
The game is super fun, but I did run into a problem with the text wrapping:
|
|
#
¿
Jan 13, 2018 11:41
|
|
|
A couple other pieces of feedback on Sequence Storm: It would be good to have a seperate graphic for when one of these lines starts that doesn't appear in the far-right track. As it is, it looks like the correct response is for me to press K and then very quickly switch over to J, when actually the game just wants me to press J.  The interface here could be made clearer. It's not apparent how to get back to the main menu from here. Also, the section which tracks how many credits you've got is hidden away in the top right in a window "beneath" the one that the user has their focus on, so it's really hard to find it -- I would put it a lot more front and centre in this window.
|
|
#
¿
Jan 14, 2018 12:02
|
|
|
Omi no Kami posted:That bugs me a bit, because monsters effectively become guaranteed damage; the only input I get is whether or not I send someone over to fight, and how I've upgraded my guys and focused (or not focused) on combat efficacy. Do you guys think that's enough? What if you choose what you arm your people with before you send them off to fight? That way you can decide whether to expend limited resources on taking down a monster quickly. You can also have choices like having noncombatants take cover for the duration of the fight, or carry on doing their jobs at the risk of being caught in the crossfire.
|
|
#
¿
Mar 8, 2018 18:38
|
|
|
I've mostly been lurking this threat up until now because I didn't want to jinx myself by posting about my game before a substantial part of it was done, but I'm now at the point where I'm looking at my work and thinking hey, I might actually finish this sometime! I've posted the first area on itch.io: https://team-robostar.itch.io/robostar:  I'm developing partially to teach myself how to work in Unity, partially to build the kind of game I want to play, and partially because I get a real kick out of other people enjoying things I've made. What other sites besides itch.io do people tend to post this kind of thing to? Most of the feedback I've gotten so far has been from getting friends to sit in front of a screen, staying resolutely silent, and taking notes while they play. The intro / tutorial sequence went through a whole number of redesigns when I kept on finding players missing what the game was trying to tell them. Are there tools that you can use to do a similar thing online, or do most people just rely on their testers being able to articulate what they think?
|
|
#
¿
Apr 29, 2018 13:09
|
|
|
KillHour posted:Like this? Oh, wow, I had no idea that Array.ConvertAll existed. Can you specify your own delgates and do something like code:
|
|
#
¿
May 5, 2018 11:02
|
|
|
I've learned so much about making tutorials obvious in the time I've built Robostar. The tutorial takes place as enemy mercs shoot your character, and introduces you to the 'shoot' keys by having you pointblank them at the point that they assume you're defenceless. I made the mistake of having the tutorial message of 'PRESS I' appear in the status bar, and my first playtester just watched the mercs shoot his character to death. Afterwards, he was genuinely confused to learn that there had been a tutorial message: he'd been so focused on the action of being shot to death that he hadn't seen it at all.
|
|
#
¿
May 7, 2018 21:07
|
|
|
A bit late for screenshot saturday, but Robostar now shows you a map at save points!
|
|
#
¿
May 14, 2018 12:33
|
|
|
It's nowhere near Screenshot Saturday. Have one anyway. Added a new enemy type, smarter and faster than the standard robots with better pathfinding.
|
|
#
¿
May 28, 2018 20:01
|
|
|
If your goal is to make a number on a website somewhere go up then yes, having big anime tits in your game will achieve that goal. If your goal is to make a good game then no, adding big anime tits will not achieve that goal.
|
|
#
¿
Oct 23, 2018 07:58
|
|
|
TooMuchAbstraction posted:I feel like that's unsatisfying though. It doesn't feel very organic and gives the player little opportunity for self-driven discovery, which is IMO a key part of what I want to do. I'd like the player to have downtime to get to know the different factions, and I'd like their choices to be presented in a more organic fashion than "okay, you've finished the last encounter, here's the next one, what do you do?" Have you played Eighty Days? That's a really good example of a game that is at its heart a CYOA, but because of the way it's presented it feels like the exploration is organic and choiceful.
|
|
#
¿
Feb 8, 2019 20:44
|
|
|
TooMuchAbstraction posted:I haven't, thanks for the recommendation. Can you describe some of what makes you feel that it handled the choice system well? Just that there was a thing you said earlier: quote:I feel like that's unsatisfying though. It doesn't feel very organic and gives the player little opportunity for self-driven discovery, which is IMO a key part of what I want to do. I'd like the player to have downtime to get to know the different factions, and I'd like their choices to be presented in a more organic fashion than "okay, you've finished the last encounter, here's the next one, what do you do?" and 80 Days is a game where you are fundamentally making CYOA-style choices (OK, there's a bit of item-trading and inventory management) but where you still feel like you're discovering things and getting to know the world and making interesting choices about what to do. I honestly couldn't say what about its writing makes the game feel like that: I think maybe that the choices aren't heavily signposted. Like, going to Vienna might have a load of plot with you fleeing a revolution, but you don't know that going in: you just know it's the next stop along the way, and you're making choices based on train timetables rather than plot hooks so when the plot actually hits, you feel like it was a discovery you made and not the next step on a pre-planned diagram.
|
|
#
¿
Feb 9, 2019 23:17
|
|
|
Create a $1 DLC that adds a skeleton and a $5000 DLC that gives the skeleton a top hat. Then create an achievement for wearing the hat called "Conspicuous Consumption".
|
|
#
¿
Mar 5, 2019 18:13
|
|
|
TooMuchAbstraction posted:That latter will piss off completionists. good
|
|
#
¿
Mar 6, 2019 07:59
|
|
|
I currently have a scene that contains any global objects including a room loader, and then I have a scene for each room the player can enter. It's probably not a good way of doing it, though, I suspect that I'm achieving is replacing Unity's dynamic loading system with my own badly-coded buggy dynamic loading system. Today I rearranged where all my rooms were sitting on the map so that I could take a picture of them all together. It didn't achieve anything but it gave me a nice sense of accomplishment. 
|
|
#
¿
Mar 14, 2019 20:42
|
|
|
Don't get hung up on whether something 'counts', that's bullshit. If you're making a thing that people enjoy, or hell, if you're making a thing that you're enjoying making, then does it really matter whether it counts as a game or a novel?
|
|
#
¿
Mar 15, 2019 15:56
|
|
|
I would go with composition over inheritance. Rather than having a script per type of enemy, have a script per way of responding to being hit -- so a "JumpBackWhenHit" script, a "FallBackWhenHit" script, etc. Then have them all implement an IOnHitBehaviour interface. When an enemy is hit, you just call GetComponent<IOnHitBehaviour>() on it to get the script that handles it's behaviour when hit, and call the relevant function on the interface. That way, you can easily have multiple different enemies which share the same behaviour when they're hit, but are otherwise totally different.
|
|
#
¿
Mar 22, 2019 10:41
|
|
|
leper khan posted:It’s going to feel weird if you’re coming from enterprise land, but unity doesn’t want you to use properties for things and its tooling does not interoperate well with them. Use fields. Don’t make them public unless you otherwise want them to be — use the [SerializeField] attribute to expose them to the editor. Yikes. I'm really deep into coding a game and I'm doing quite a lot of these things -- in particular I'm instantiating things at runtime like they're going out of fashion. Fortunately it doesn't seem to have impacted speed -- I assume because the game I'm writing is quite simple -- but this is really useful to know for the next thing I do.
|
|
#
¿
Apr 14, 2019 19:35
|
|
|
However, it's worth bearing in mind that in that circumstance it sounds like you'll only be instantiating an entity when the GM spawns a new one, or when the enemies take their turn and a new enemy appears, so that's not so much of an issue as far as slowdown goes. If you had an animation for, say, casting magic missile where a load of pretty bolts of light flew out of your character and at an enemy, and you were instantiating each one of those on the fly, then that might be something to be concerned about, but even then it might be OK.
|
|
#
¿
Apr 15, 2019 06:41
|
|
|
Hard disagree on this -- sure, you should use playtesting to work out what range of values is fun, but those values will inform a whole load of other things throughout your game that you need to use math to decide Like, you can conclude from playtesting that fighting enemies feels satisfying if they take aroundthree hits to kill, maybe five, definitely no more than seven -- but that figure then has to go into a spreadsheet to help you work out how many HP an enemy has based on things like weapon damage and chance of hitting. You're not ever going to get a solid answer but having tools like that available to you will make life way easier than just trying to do things based on a gut feel of "this weapon feels weak".
|
|
#
¿
Apr 29, 2019 08:23
|
|
|
TooMuchAbstraction posted:This is amazing, but I feel like it could be improved by making the hitshake on the treasure chest even more improbable towards the end to make it harder to click on. After the trombone is unlocked you should have to click on it to collect it.
|
|
#
¿
May 26, 2019 08:47
|
|
|
Just release a cover of it.
|
|
#
¿
May 27, 2019 08:01
|
|
|
One alternative to 4'33" would be to do a track that is entirely drum solo. The more I think about your game the more I think of tracks that you should include. You should totally have a version of Duelling Banjos where only the player's instrument is a trombone.
|
|
#
¿
May 28, 2019 17:22
|
|
|
Sundae posted:People will ignore a falling-over death sprite suddenly not holding a gun anymore, but they're definitely not going to ignore the player's red vest and blue backpack suddenly vanishing as the character dies, as an example. Solution: when a character dies, all their clothes hurtle into the sky like losing a game of Buckaroo.
|
|
#
¿
Aug 15, 2019 09:15
|
|
|
Lork posted:Transitions from "Any state" have the setting "Can transition to self", which is on by default I guess. Turn it off to get the behavior you want.  All this time I've been writing an individual transition from each other state to get around this problem.
|
|
#
¿
Sep 18, 2019 10:17
|
|
|
I'm using Unity for my learn-to-code-games 2D game and it's worked pretty smoothly at every point. That's just a single data point from someone who doesn't really know what he's doing, though.
|
|
#
¿
Sep 23, 2019 14:49
|
|
|
Hammer Bro. posted:It may be a tough sell to get players to throw spears at cute little foxes then eat their bloody remains. Change all the animals into giant living vegetables that stampede around causing a ruckus.
|
|
#
¿
Oct 23, 2019 22:24
|
|
|
Mother of god, I had assumed that the developer behind this had given up and vanished off the internet and resigned myself to deapair. Now I look at it, of course the trombone game is you as well, they both have a very similar sense of humour.
|
|
#
¿
Nov 11, 2019 18:16
|
|
|
Yes -- I would suggest that the missions are set up as either: 1. "We need you to do this thing, so that what would be a crushing defeat instead becomes a successful escape" 2. "We need you to do this thing to give our last, desperate plan a hope of success (but the enemy is going to achieve conventional victories while you do it)"
|
|
#
¿
Nov 26, 2019 10:53
|
|
|
|
| # ¿ Apr 23, 2024 15:03 |
|
|
I'm going one step further with my current project and making a comedy "near-impossible to defeat, probably not even fun, what the hell are you thinking even trying this" difficulty that's tuned to be too hard for the developer.
|
|
#
¿
Dec 27, 2019 10:16
|
|