|
AntiPseudonym posted:So I had this bright idea of having a small chance of the murderer leaving the murder weapon in the victim. 
|
#
?
Oct 26, 2015 14:24
|
|
|
|
| # ? Jun 12, 2024 06:43 |
|
|
Shalinor posted:Please leave a small chance of this still happening Also I made my ghost better: http://johnearnest.github.io/Octo/index.html?gist=aaa6b2ce7d748f1ac73d
|
|
#
?
Oct 26, 2015 14:58
|
|
|
AntiPseudonym posted:So I had this bright idea of having a small chance of the murderer leaving the murder weapon in the victim.
|
|
#
?
Oct 26, 2015 15:00
|
|
|
AntiPseudonym posted:So I had this bright idea of having a small chance of the murderer leaving the murder weapon in the victim. This is actually really great, the murderer could have just had super strength or something and it adds some more variety, you know? Also I'm finally done with this garbage! (garbage/scrap tiles that is, for an abandoned scrapyard area with scrap monsters and stuff)   Looks pretty weird when viewed from the side, there's also a strange kind of 3D effect when you walk past them cause the tiles are rendered by a perspective camera, but its hard to show without making a video.
|
|
#
?
Oct 26, 2015 15:13
|
|
|
AntiPseudonym posted:So I had this bright idea of having a small chance of the murderer leaving the murder weapon in the victim. 
|
|
#
?
Oct 26, 2015 15:26
|
|
|
I agree with everyone else. That definitely falls into the "it's not a bug it's a feature" camp.
|
|
#
?
Oct 26, 2015 15:29
|
|
|
Mercury_Storm posted:This is actually really great, the murderer could have just had super strength or something and it adds some more variety, you know?
|
|
#
?
Oct 26, 2015 15:32
|
|
|
ah, nature's gun holster
|
|
#
?
Oct 26, 2015 16:09
|
|
|
That's a great way to gently caress up your back
|
|
#
?
Oct 26, 2015 16:25
|
|
|
Shalinor posted:Please leave a small chance of this still happening The Kins posted:Adding to the crowd of voices saying this should be kept as a rare occurance, maybe with an extra "Wow, whoever did this must've really hated this guy!" bit of flavour text so players know it's not an unintentional bug. BUGS OF SPRING posted:I agree with everyone else. That definitely falls into the "it's not a bug it's a feature" camp. Don't say I never do anything for you guys!  (Has a 0.01% chance of happening) Edit: Can't decide if this is more or less brutal: 
AntiPseudonym fucked around with this message at 17:14 on Oct 26, 2015 |
|
#
?
Oct 26, 2015 17:08
|
|
|
You're a good man, Charlie Brown. You mentioned you're gonna be showing this at Pax this weekend, right? I'll have to swing by and give it a whirl!
|
|
#
?
Oct 26, 2015 17:13
|
|
|
The Kins posted:You're a good man, Charlie Brown. You mentioned you're gonna be showing this at Pax this weekend, right? I'll have to swing by and give it a whirl! Awesome, we're gonna be at stand 40! I'll be the tall guy that looks well out of his depth, come and say hi! AntiPseudonym fucked around with this message at 17:37 on Oct 26, 2015 |
|
#
?
Oct 26, 2015 17:18
|
|
|
AntiPseudonym posted:Don't say I never do anything for you guys!
|
|
#
?
Oct 26, 2015 17:39
|
|
|
AntiPseudonym posted:
|
|
#
?
Oct 26, 2015 17:40
|
|
|
Zereth posted:Please make it so you murderees can also be shot with a knife.
|
|
#
?
Oct 26, 2015 17:41
|
|
|
Mercury_Storm posted:Also I'm finally done with this garbage! (garbage/scrap tiles that is, for an abandoned scrapyard area with scrap monsters and stuff) vicious scrapchicken prowls its domain
|
|
#
?
Oct 26, 2015 20:05
|
|
|
_jink posted:vicious scrapchicken prowls its domain Haha yeah, waiting on the artist to make the concepts for the scrap monsters still. So far on monsters I have a bunch of robot types done and a few more basic enemies, but robots types aren't area specific and can appear anywhere as more "out of depth"/oh poo poo enemies. There's one specific robot that's constantly moving though the world and beelines for your location if you happen to set off an alarm that looks like this:  And other not quite as smart robots too:  Also the terrifying fat giant seal:  (just kidding it will probably be a very rare joke enemy if anything) Mercury_Storm fucked around with this message at 23:26 on Oct 26, 2015 |
|
#
?
Oct 26, 2015 20:30
|
|
|
 moment at Unite:"Yeah, if you make your texture using Clouds or Difference Clouds at a power of 2 texture size, it tiles seamlessly" "What!"
|
|
#
?
Oct 26, 2015 23:55
|
|
|
It tiles yes. EXTREMELY visibly, but yes.
|
|
#
?
Oct 26, 2015 23:56
|
|
|
Zereth posted:Please make it so you murderees can also be shot with a knife. You don't want to go overboard with something like this, but scrambling the murder weapons from Clue is good comedy and a good opportunity for misdirection. Blunt trauma with the handle of a knife, choked on a bullet, the knot in the noose came undone and the victim fell only to land exactly on an exposed lead pipe.
|
|
#
?
Oct 27, 2015 00:10
|
|
|
Don't lie to me, those are all actual CSI Miami episodes.
|
|
#
?
Oct 27, 2015 00:26
|
|
|
SynthOrange posted:
I thought this was something everyone learned around the time they were making floating eyes on difference clouds backgrounds as babby's first photoshop? But to get nice noise / variation layering it's better to just use some photos and make them seamless by using offset and painting out the edges.
|
|
#
?
Oct 27, 2015 00:39
|
|
|
In abstract, I find the concept of pistolwhipping to be funny. "That's not how you use it!" We have been playing a lot of Mysterium this past week, which has a lot of jumbled person-place-weapons in it. The oddest one so far is a chest. We could not make sense of it. In my head, I imagine they grabbed it over their head and bopped the person to death, River City Ransom style.
|
|
#
?
Oct 27, 2015 05:16
|
|
|
Open chest lid -> Put head in -> Close chest lid (very hard) ? ?
|
|
#
?
Oct 27, 2015 07:40
|
|
|
I know it's typically bad form to mention RPG Maker stuff, but MV apparently released recently and is javascript based. Enterbrain apparently listened to a lot of people and took a lot of things into consideration with it (even to the point of plugins having, what I think I understand as, defined fields so you literally cannot gently caress up a plugin that is designed properly). I'm probably going to check out a demo for it when I get home and see what insanity it has. I know for me, it improves damage formulas (more length), gives you a choice of front or side battle views (innate!), has mobile export (in before a wave of lovely phone RPGs saturates the market), and mouse/gamepad support. Its... actually not that bad looking for once... did I just say that?
|
|
#
?
Oct 27, 2015 15:28
|
|
|
It definitely makes me feel stupid for having ever bought VX Ace, what with it having had few if any improvements I could notice from loving 2000.
|
|
#
?
Oct 27, 2015 15:51
|
|
|
FraudulentEconomics posted:I know it's typically bad form to mention RPG Maker stuff, but MV apparently released recently and is javascript based. Enterbrain apparently listened to a lot of people and took a lot of things into consideration with it (even to the point of plugins having, what I think I understand as, defined fields so you literally cannot gently caress up a plugin that is designed properly). I'm probably going to check out a demo for it when I get home and see what insanity it has. I know for me, it improves damage formulas (more length), gives you a choice of front or side battle views (innate!), has mobile export (in before a wave of lovely phone RPGs saturates the market), and mouse/gamepad support. If RPG Maker is what it takes someone to finish a game, then so be it. I mean it's not like it can only make really ugly RPGs, much like UE can make more than hyperbulky plastic men, but it required digging around in those Ruby encrusted guts. Which hopefully the javascript change will make, if not easier, more common.
|
|
#
?
Oct 27, 2015 15:56
|
|
DStecks posted:It definitely makes me feel stupid for having ever bought VX Ace, what with it having had few if any improvements I could notice from loving 2000. There's a lot of improvements from 2000 -> Ace, one of them being RGSS3. VX was the one where they took a huge, confusing step back and then had to scramble to fix everything they broke (and that manifested as Ace) and added a couple new features as well, such as some advanced functions w/r/t music playback to name one. I tried the MV demo and I dunno... something about it just feels oversimplified to me. I suppose I'd have to try the full version before judging but I'm not about to drop 70 bucks on MV when Ace serves me perfectly fine for my last RPG Maker game.
|
|
|
#
?
Oct 27, 2015 15:56
|
|
|
It's irrelevant for me anyway, since (unless I missed something very, very big) MV would still need to be bent into pretzels to get what I'm trying to do with my game. VX Ace is still fun for me to just tool around in, which is all I ever did with 2000 anyway.
|
|
#
?
Oct 27, 2015 16:05
|
|
|
FraudulentEconomics posted:I know it's typically bad form to mention RPG Maker stuff, but MV apparently released recently and is javascript based. Enterbrain apparently listened to a lot of people and took a lot of things into consideration with it (even to the point of plugins having, what I think I understand as, defined fields so you literally cannot gently caress up a plugin that is designed properly). I'm probably going to check out a demo for it when I get home and see what insanity it has. I know for me, it improves damage formulas (more length), gives you a choice of front or side battle views (innate!), has mobile export (in before a wave of lovely phone RPGs saturates the market), and mouse/gamepad support. RPG Maker is just fine for what it is and what it is is a way for people with no programming skills to make a JRPG. It isn't marketed toward people making commercial games it's primarily marketed toward people who think it would be neat to make a game some day but don't have the time, ambition, or talent to make commercial games. More of a "hey here is a thing for an individual to fart around making games with" than an actual engine. Seriously, it gets more hate than it deserves.
|
|
#
?
Oct 27, 2015 16:13
|
|
|
Noyemi K posted:There's a lot of improvements from 2000 -> Ace, one of them being RGSS3. VX was the one where they took a huge, confusing step back and then had to scramble to fix everything they broke (and that manifested as Ace) and added a couple new features as well, such as some advanced functions w/r/t music playback to name one. From what I can see, it's got a TON of the functionality of very common plugins either native or packaged with it. Side battle, animated battlers, advanced action effects, just to name a few. It's got XP's layer system back which is a loving godsend as opposed to Ace's fiasco. DStecks posted:It's irrelevant for me anyway, since (unless I missed something very, very big) MV would still need to be bent into pretzels to get what I'm trying to do with my game. VX Ace is still fun for me to just tool around in, which is all I ever did with 2000 anyway. MV seems like it's more like bending hot metal versus concrete. The Plugin interface is a lot easier to use and if you have experience with javascript it's very possible to just make what you need and have it work well enough on its own. Unhappy Meal posted:If RPG Maker is what it takes someone to finish a game, then so be it. I mean it's not like it can only make really ugly RPGs, much like UE can make more than hyperbulky plastic men, but it required digging around in those Ruby encrusted guts. Which hopefully the javascript change will make, if not easier, more common. There have been maybe 1 or 2 actually good RPG maker games, but with the amount of love present in this iteration could very well result in higher quality games. Unique systems will be easier to implement because you aren't looking to keep everything as neat and tidy anymore supposedly! No need to worry about making your side battle system work when it's built in now, so you can focus on your farming simulator. ToxicSlurpee posted:RPG Maker is just fine for what it is and what it is is a way for people with no programming skills to make a JRPG. It isn't marketed toward people making commercial games it's primarily marketed toward people who think it would be neat to make a game some day but don't have the time, ambition, or talent to make commercial games. More of a "hey here is a thing for an individual to fart around making games with" than an actual engine. I fall under the "don't have enough time to develop programming skills beyond fixing poo poo" category so I like visual editors and such. Javascript will probably attract a new crowd of plugin devs, and probably ones that aren't as entitled to charge for a single line of code like some of the more manchild-esque coders have been known to do. Edit:  I'm watching their youtube series about the plugins that come with it and GOD drat. Item upgrades (think ability slots) packaged with it!? This... yeah I may be making a purchase soon holy fuckshit.
FraudulentEconomics fucked around with this message at 16:28 on Oct 27, 2015 |
|
#
?
Oct 27, 2015 16:22
|
|
FraudulentEconomics posted:From what I can see, it's got a TON of the functionality of very common plugins either native or packaged with it. Side battle, animated battlers, advanced action effects, just to name a few. It's got XP's layer system back which is a loving godsend as opposed to Ace's fiasco. I see a lot of complaints being levelled against XP's layer system being stripped out but honestly that was the least of the problems I had with the move from XP to VX. Clever developers got around the layer thing by using the event layer as an additional tile layer—this is also why BCDE could be used as event graphics in VX/A. As much of a stubborn nail as I am in insisting Ace is perfectly fine and my distaste of MV's interface, I might wind up using it if it goes under $40 at some point (because I want to author plugins like I did for Ace).
|
|
|
#
?
Oct 27, 2015 16:35
|
|
|
FraudulentEconomics posted:MV seems like it's more like bending hot metal versus concrete. The Plugin interface is a lot easier to use and if you have experience with javascript it's very possible to just make what you need and have it work well enough on its own. Well number one, I don't know javascript. And number two, this is what I'm doing with my game:  Maybe somebody who's an absolute Jedi master of Java and RPGMaker could accomplish that, but at that point all you're using RPGMaker for is the graphics engine and level editor.
|
|
#
?
Oct 27, 2015 16:36
|
|
|
I've got a couple questions about making a top-down shooter, I guess. Right now I only have 2d, and recently I decided to tackle melee. What is the most common approach? What I've quickly hacked together is a simple raycast to a short distance ahead of the player, and I don't know if that's enough, probably because I don't have any animations yet to really test if it works, but enhancing the things with a shape, instead of a ray, or even having a body for an attack simulation are options that could work? I'm in libGDX. I'm not entirely sure what's going on with my sound. I've tried adding footsteps, and if I play them for all characters on the screen it basically creates white noise, but even if it's just a few closest to the player I often have sound cutting out... So I don't know, maybe it's a limitation of libGDX, or my hardware, or it's just not done. Also I've got everything hardcoded, and the list of enemy types keeps growing (right now at just 7 though)... I probably should switch to external files. Are simple text files the best? Also it probably will make things clearer, but right now I'm not convinced of the benefit. I mean, the data is still going to be spread around several files (graphics, enemy characteristics, level settings), and I'm not sure how much the opportunities for loving up will be decreased. Finally, when I started I thought I'd make this very quickly, and therefore uncomplicated, so the gameplay and motion right now is like an infinitely scrolling shooter. The player character walks forward by itself. The idea was that most npcs would fear and escape the player, so I thought it would be best to prevent the player from stopping so it doesn't end up in a vacuum. But at the same time it's probably less satisfying with this limit on control. However, storywise the resistance should grow in the wake of the player (a.k.a. cops), thus also forcing the player to always keep moving to avoid being overwhelmed, thus basically having to keep the forward key constantly pressed, which is another of my reasons to force forward movement. Any thoughts? Oh, another thing - are the hitboxes in this kind of thing usually a circle? supermikhail fucked around with this message at 16:59 on Oct 27, 2015 |
|
#
?
Oct 27, 2015 16:56
|
|
|
Circular hit boxes are fine - it keeps things simple both from a programming perspective and a player perspective, so long as your characters fill the circles well. For melee attacks, instead of a raycast you can use a shape as a hit volume - this will work better for sweeping type attacks since it allows for it to register collisions along the entire arc rather than only in the middle of the attack.
|
|
#
?
Oct 27, 2015 17:08
|
|
|
supermikhail posted:Right now I only have 2d, and recently I decided to tackle melee. What is the most common approach? What I've quickly hacked together is a simple raycast to a short distance ahead of the player, and I don't know if that's enough, probably because I don't have any animations yet to really test if it works, but enhancing the things with a shape, instead of a ray, or even having a body for an attack simulation are options that could work? I'm in libGDX. Shapes are fine. What's often done is you draw some kind of arc indicating the swing of the weapon, and then you roughly approximate that arc with a rectangle and use that rectangle for collision detection. Collisions don't have to be super-accurate to work well. quote:I'm not entirely sure what's going on with my sound. I've tried adding footsteps, and if I play them for all characters on the screen it basically creates white noise, but even if it's just a few closest to the player I often have sound cutting out... So I don't know, maybe it's a limitation of libGDX, or my hardware, or it's just not done. I'm not super-familiar with sound, but it may be that you're running out of sound channels, which puts a limit on how many sound effects can be played at a time. This may be something you can configure in your game's startup code, or it might be a hardware constraint (see also: not super-familiar with sound). If you look at a game like Nuclear Throne, say, the player has footstep sounds, but all of the enemies are much quieter, typically only making noise when they're attacking. Don't worry about having sounds that only play for the player. quote:Also I've got everything hardcoded, and the list of enemy types keeps growing (right now at just 7 though)... I probably should switch to external files. Are simple text files the best? Also it probably will make things clearer, but right now I'm not convinced of the benefit. I mean, the data is still going to be spread around several files (graphics, enemy characteristics, level settings), and I'm not sure how much the opportunities for loving up will be decreased. Use text in preference to binary (except obviously for things like image data or sounds), since text is a lot easier to debug and file sizes are not an issue. I'd recommend using a standard markup language like JSON, XML, YAML, etc. (if you want one recommendation, use JSON in my opinion) that has pre-existing libraries for your language of choice. You don't want to write your own custom file format and parser; the benefits are practically nonexistent and the costs can be unexpectedly significant. quote:Finally, when I started I thought I'd make this very quickly, and therefore uncomplicated, so the gameplay and motion right now is like an infinitely scrolling shooter. The player character walks forward by itself. The idea was that most npcs would fear and escape the player, so I thought it would be best to prevent the player from stopping so it doesn't end up in a vacuum. But at the same time it's probably less satisfying with this limit on control. However, storywise the resistance should grow in the wake of the player (a.k.a. cops), thus also forcing the player to always keep moving to avoid being overwhelmed, thus basically having to keep the forward key constantly pressed, which is another of my reasons to force forward movement. Any thoughts? It sounds like you're basically trying to cross an infinite runner with a shmup. That can probably work fine. I do think it's important that you show the player the advancing wall of doom (made of cop cars, I guess) behind them and give them opportunities to fail and get swallowed by it. In a normal game that could happen because they aren't pressing the forward button enough; if you're taking over the forward button for them then it should be because they get hung up on walls or knocked back by attacks or whatever. Don't feel afraid to have a game where the player is pressing a button 95+% of the time though. Very few shmups have a "don't shoot" button.
|
|
#
?
Oct 27, 2015 17:35
|
|
|
The Cheshire Cat posted:Circular hit boxes are fine - it keeps things simple both from a programming perspective and a player perspective, so long as your characters fill the circles well. That's kind of the problem... my basic sprites are right now drawn from the side, or could perhaps pass for isometric perspective, so they don't combine at all well with their hitbox, and what's more, if I expanded the hitbox to fit everyone would collide like they're lying down. Actually drawing stuff top-down doesn't really appeal to me artistically, although it would certainly make my job easier. TooMuchAbstraction posted:I'm not super-familiar with sound, but it may be that you're running out of sound channels, which puts a limit on how many sound effects can be played at a time. This may be something you can configure in your game's startup code, or it might be a hardware constraint (see also: not super-familiar with sound). Unfortunately it seems that libGDX doesn't support much sound configuration. But I was already thinking that playing general crowd noise would be good enough. Still, judging by games I play it seems my hardware should be more than capable to handle the mixture of sounds that I throw at it, and I find this disparity somewhat confusing.
|
|
#
?
Oct 27, 2015 18:04
|
|
|
supermikhail posted:That's kind of the problem... my basic sprites are right now drawn from the side, or could perhaps pass for isometric perspective, so they don't combine at all well with their hitbox, and what's more, if I expanded the hitbox to fit everyone would collide like they're lying down. Actually drawing stuff top-down doesn't really appeal to me artistically, although it would certainly make my job easier. A lot of shooters have ships with seemingly ridiculously small circular hitboxes, so it might not be a problem. It makes it more fun for the player if there's a good amount of leeway for getting hit and blown up, especially in games with zillions of bullets on the screen and one hit does you in. If it's too hard to figure out where the hitbox might be, you could always draw some sort of core to indicate where it is. (destroy the core!) Mercury_Storm fucked around with this message at 18:13 on Oct 27, 2015 |
|
#
?
Oct 27, 2015 18:10
|
|
|
Mercury_Storm posted:A lot of shooters have ships with seemingly ridiculously small circular hitboxes, so it might not be a problem. It makes it more fun for the player if there's a good amount of leeway for getting hit and blown up, especially in games with zillions of bullets on the screen and one hit does you in. If it's too hard to figure out where the hitbox might be, you could always draw some sort of core to indicate where it is. (destroy the core!)
|
|
#
?
Oct 27, 2015 18:13
|
|
|
|
| # ? Jun 12, 2024 06:43 |
|
|
supermikhail posted:Finally, when I started I thought I'd make this very quickly, and therefore uncomplicated, so the gameplay and motion right now is like an infinitely scrolling shooter. The player character walks forward by itself. The idea was that most npcs would fear and escape the player, so I thought it would be best to prevent the player from stopping so it doesn't end up in a vacuum. But at the same time it's probably less satisfying with this limit on control. However, storywise the resistance should grow in the wake of the player (a.k.a. cops), thus also forcing the player to always keep moving to avoid being overwhelmed, thus basically having to keep the forward key constantly pressed, which is another of my reasons to force forward movement. Any thoughts? The more general problem you're trying to solve is how to keep the player progressing through the game without actually forcing them forward. There are a couple of solutions to this, and I've been thinking about them recently for my own top-down spacegame. There is, as you mentioned, forced movement. This is fine for arcade-style games but it does remove the sense of freedom and agency (the feeling that one's decisions had an impact) from the game. Having a solid wall-of-death trudging forward is effectively this approach, although a little more stylistically presented. There's also the Cruisin' USA model, as I like to call it. Hunger in Roguelikes. You have some resource that is necessary for gameplay to continue; fuel or food or whatever makes sense. If the player runs out of it, they lose. And the only way to acquire more of it is to go forward. This system adds for more leeway, as if you burn through the first areas quicker than expected you'll have a surplus of whatever the resource is and be allowed to spend longer in later areas. You can still math it out such that it's balanced the same as forced movement (the player loses if they're not past Area 5 at the ten minute mark), but there's much more freedom for the player to control the pacing. There's also the approach of increasing danger, which seems like it might fit you best thematically. You have secret requirements for pacing -- there's no danger for the first minute in each section, and you should absolutely be past any section by the five minute mark (make up pacing rules as you see fit). Give the player a warning that they've started to linger too long, either via the UI or by a wimpy unit spawning behind them. Then, as time progresses without them moving significantly forward, spawn increasingly harder enemies. If you spend a little too long in an area it's not a big deal, and there might even be slight rewards for the danger of extra combat, but eventually the endless enemies will overwhelm the player unless they move onward. This feels nice thematically (first the motorcycle scouts show up, then the small squads of beat cops, and eventually the tanks), without feeling unfair like an automatic wall-of-death would. It also allows the player some freedom in how to spend their time, yet allows you to control the tempo of your game just as well as the other two options.
|
|
#
?
Oct 27, 2015 18:27
|
|
