|
Agreed. I'd rather the loading screen say "hold X to restore controls to default" or something than having to click through screens before the game even loads. Especially if I want to play it on my couch remotely.
|
#
?
Jul 27, 2019 04:03
|
|
|
|
| # ? Jun 3, 2024 13:52 |
|
|
That Dang Lizard posted:You could have one of those "game launcher" type things where you can edit binds, graphics settings, etc. before loading the game? Kind of old-school but it works. brah gross
|
|
#
?
Jul 27, 2019 04:28
|
|
|
You could have a seperate config program that didn't NEED to be launched before the game You could just have both KB and pad input accepted all the time like 90% of games do and not totally over think What If scenarios
|
|
#
?
Jul 27, 2019 04:40
|
|
|
Yeah there is some over-thinking going on. Just make it work.
|
|
#
?
Jul 27, 2019 07:07
|
|
|
Finally added the foreground tiles to the first level of Louny Balloony. https://twitter.com/harold_krell/status/1155147625592545281 The building tiles were modeled after some prototype background buildings I ended up omitting since they seemed too busy and detailed to put as backgrounds for the game.  
|
|
#
?
Jul 27, 2019 17:43
|
|
|
Working on the story scene player. Nothing complex. Text with markup for text color and other scene animations like character portrait effects. Simple enough that I can make an in-engine scene editor to speed things along. 
|
|
#
?
Jul 27, 2019 18:01
|
|
|
I've been experimenting with generating streets with Voronoi diagrams instead of L-systems. I prefer the flexibility and power of L-systems, but the Voronoi grah is so much easier to manipulate and debug that it's probably gonna be my go-to for prototyping. Honestly it's probably even fine for final production-quality areas, but even with a bunch of Lloyd relaxation and manipulation of the lot polys it's very visibly a Math Thing, and not an organic city.
|
|
#
?
Jul 28, 2019 00:21
|
|
|
The main reason for that is a lack of long continuous roads, which you probably already figured out. I do think the voronoi method can work very well for areas bordered by natural obstructions like waterfronts or cliffs, but in an open space a city's streets will tend to stay gridlike because that's just the most efficient way.
|
|
#
?
Jul 28, 2019 14:26
|
|
|
Yeah, I'm going to keep tinkering with L-systems on the side and see if I can't get it working... I actually already have the new york rule/raster-style grids set up fine, since the rule is really simple: you just extend a set distance while maintaining some kind of ideal length/width ratio to make for clean allotments, then add constraints to direct around high points in elevation or other obstacles. Where I've been stymied is in getting more organic-looking roads; I think what Parish & Muller and most systems based on that paper do is use a population heatmap and tell each street to grow towards the highest population density in its general path, but I tend to get ugly spirals/clusters when I do that. It's not unsolvable, it just needs a lot more attention and iteration than I want to put in when I'm still building the game part of the game. ^^
|
|
#
?
Jul 28, 2019 15:59
|
|
|
Omi no Kami posted:I've been experimenting with generating streets with Voronoi diagrams instead of L-systems. I prefer the flexibility and power of L-systems, but the Voronoi grah is so much easier to manipulate and debug that it's probably gonna be my go-to for prototyping. Honestly it's probably even fine for final production-quality areas, but even with a bunch of Lloyd relaxation and manipulation of the lot polys it's very visibly a Math Thing, and not an organic city. How do you get L-systems to join back up in a realistic looking way?
|
|
#
?
Jul 28, 2019 17:54
|
|
|
In the original L-system-for-cities paper, the title of which I forget, the idea was that when you add a new road segment you scan a given circular area around the segment's endpoint (and if your new segment crosses an existing one the endpoint is the intersection point) and if you find one or more existing vertices within that radius you snap your endpoint to the closest or otherwise more appropriate vertex.
|
|
#
?
Jul 28, 2019 18:06
|
|
|
Chev posted:In the original L-system-for-cities paper, the title of which I forget, the idea was that when you add a new road segment you scan a given circular area around the segment's endpoint (and if your new segment crosses an existing one the endpoint is the intersection point) and if you find one or more existing vertices within that radius you snap your endpoint to the closest or otherwise more appropriate vertex. Yup, exactly that. There are usually three local constraints you apply to every piece of road: two intersecting streets form a crossing, ends near a crossing stretch to meet it, segments close to intersecting extend to form an intersection.
|
|
#
?
Jul 28, 2019 18:09
|
|
|
When I attempted an L-system city grid several years ago, I brute forced it by writing the rules to guarantee that some of the streets overlapped, then writing a function to find those overlaps and simplify them into a single line. I lost the code in a hard drive blow up at some point, this is the only surviving proof I did it:  The colored subdivision was me starting work on filling in the space with buildings.
|
|
#
?
Jul 28, 2019 20:03
|
|
|
Screenshot...Sunday? I was away from my computer all day yesterday, but I threw together a few more ship/part models this morning, this time based on the German heavy cruiser Admiral Graf Spee. This isn't even remotely the most ridiculous WW2-era ship bridge; the Japanese navy had some preposterously huge ones. But it is tall enough that the side-view camera can't fit the entire thing on-screen. And I had to move the top-view camera up so it wouldn't be embedded inside the bridge.
|
|
#
?
Jul 28, 2019 20:09
|
|
|
That's wild; where's the center of mass of that beast? How far can it roll before it just capsizes?
|
|
#
?
Jul 28, 2019 20:53
|
|
|
I have no idea what the stats were like for the original ship, but doubtless they put a lot of heavy equipment (like the boilers that drove the screws that provided thrust) at the bottom. Plus of course the main hull is heavily armored -- the original Graf Spee had 10cm-thick armor plates on the sides, and 14cm-thick armor on the turrets. For my game, ship parts don't have mass directly; instead, their mass is added to the mass of the hull. And I don't let my ships capsize until they're dead.
|
|
#
?
Jul 28, 2019 21:06
|
|
|
If you're ever really bored, you could add those bizarre prototype carriers the USN tried to make out of ice and sawdust.
|
|
#
?
Jul 28, 2019 21:08
|
|
|
xzzy posted:When I attempted an L-system city grid several years ago, I brute forced it by writing the rules to guarantee that some of the streets overlapped, then writing a function to find those overlaps and simplify them into a single line. Oh man, working out decent-looking subdivisions is super tough, I've honestly been finding that almost as frustrating as making organic-looking road networks. I've spent the last week or two fiddling with a bunch of different approaches, but the simplest and most consistent way I've found to generate allotments is still the Parish & Muller thing of recursively subdividing each lot polygon:  I might find that it looks weird to people, but I know that more than one game has pretty successfully gotten away with straight-up populating their city blocks with a sealed perimeter of buildings and nothing in the middle, so I'm hoping that as long as it serves the gameplay well, nobody will notice if the inner 25% of each block is just inaccessible empty space after I delete each allotment that can't path to a nearby street. Edit: Sorry for the double post, meant to edit this into my first one. <_<
|
|
#
?
Jul 28, 2019 21:11
|
|
|
I think the road I was going to go down is subdivide into a relatively fine grid like you have there, then run another routine that merges subdivisions back together to make the buildings. This makes it relatively easy to create alleys because then you can establish a border around each building where no building can touch another building. The complexity develops when you want blocks with different types of structure.. like a huge skyscraper that takes up an entire block, or a strip mall, or whatever. That gets you into the pain of needing a scheme like a heatmap or something to pick which block gets what types and how to make it look plausible.
|
|
#
?
Jul 28, 2019 21:23
|
|
|
Hmm yeah... for the zoning I've been assigning each polygon a single zone type, and once I get to the point where I want to mix big and small buildings I think I'll probably treat each subdivision as a real-estate allotment that can hold one building, and simply let some buildings reserve multiple adjacent allotments. I could probably also make it more organic-looking by placing each building at a random spot inside its allotment, but since my current game is set in urban Japan it's easier to just make each building match its allotment shape 1:1 so you end up with completely flush structures.
|
|
#
?
Jul 28, 2019 21:37
|
|
|
Omi no Kami posted:If you're ever really bored, you could add those bizarre prototype carriers the USN tried to make out of ice and sawdust. Warship Gunner 2 (the game I'm imitating) had an iceberg battleship as one of the bosses, along with various other implausible gigantic war machines. I see no particular reason not to imitate it in that respect as well. 
|
|
#
?
Jul 28, 2019 21:40
|
|
|
This weekend's insomnia overengineering madness: adding a networking abstraction so that networked objects/attributes more or less just mark the things they want synchronized, and don't have to worry about the status of the other clients or their peers at all. After six hours and maybe three revisions today, I'm to the point where even six-line functions just look like wobbly messes of words. But it throws no errors nor warnings for the first five seconds of synchronized online play, and I know why the first failure occurs, so I can sleep easy tonight! (I'm pretty sure it's a house of cards. Networking implementation is easy; networking logic is treacherous.)
|
|
#
?
Jul 29, 2019 02:58
|
|
|
Hammer Bro. posted:This weekend's insomnia overengineering madness: adding a networking abstraction so that networked objects/attributes more or less just mark the things they want synchronized, and don't have to worry about the status of the other clients or their peers at all. I’ve always found eventually consistent systems easier to work with than deterministic ones. Should probably try my hand at building a deterministic lib again.
|
|
#
?
Jul 29, 2019 03:09
|
|
|
Though I'd never heard of the phrase previously, I think what I'm designing is more similar to an eventually consistent one than a deterministic one. The only concerning corner cases have to do with the creation/destruction of objects, as the Godot networking abstraction I'm working atop considers it an error if you attempt to send a message to a client that does not have a copy of the receiving object. And yowza, I added a simple cache/filtering mechanism to my personal network abstraction machine and it turns out ~98% of the messages I was broadcasting can be dropped as redundant. I feel like a genius though I'd like to hope that most production systems don't routinely broadcast already-known information.
|
|
#
?
Jul 29, 2019 23:03
|
|
|
Hammer Bro. posted:Though I'd never heard of the phrase previously, I think what I'm designing is more similar to an eventually consistent one than a deterministic one. The only concerning corner cases have to do with the creation/destruction of objects, as the Godot networking abstraction I'm working atop considers it an error if you attempt to send a message to a client that does not have a copy of the receiving object. Deltas are rad. Also for patching. And streaming video formats.
|
|
#
?
Jul 29, 2019 23:13
|
|
|
It's always the things that sound simple that end up being stupidly complicated. I want my ship parts to take up some space belowdecks, so that they'll be competing with things like the engines and screws (giant propellers), making the ship design minigame more complicated. But this means that the player needs to be able to see the space they're taking up and the parts they're intersecting, even though the ship is in the way. So no problem, I'll just draw a box on the screen representing the space taken up by the belowdecks portion of the part's collider. Rendering lines on the screen is apparently some deep dark magic these days. I was expected to have, like, some kind of "after the frame is done rendering, this callback gets invoked; here's some functions that draw graphics in software, Camera.WorldToScreenPoint can tell you where to draw, knock yourself out" kind of library. Nope. Unity's only support for line rendering, as far as I can tell, are:
In unrelated news, World of Warships is giving me some serious impostor syndrome. I'm making an arcadey naval combat sim game...and inevitably I'll be compared to that. They have multiplayer and much nicer art than I can ever turn out. Their models are doubtless more historically accurate too. I'm gonna have to think hard on how I can differentiate myself beyond just "you can design your own ships".
|
|
#
?
Jul 30, 2019 02:58
|
|
|
Make a new camera, set it to depth only culling, give it a higher depth than your main camera and set its culling mask to only the layer containing your lines (however you make them) and it should render them on top of everything else.
Lork fucked around with this message at 03:37 on Jul 30, 2019 |
|
#
?
Jul 30, 2019 03:29
|
|
|
TooMuchAbstraction posted:It's always the things that sound simple that end up being stupidly complicated. I want my ship parts to take up some space belowdecks, so that they'll be competing with things like the engines and screws (giant propellers), making the ship design minigame more complicated. But this means that the player needs to be able to see the space they're taking up and the parts they're intersecting, even though the ship is in the way. So no problem, I'll just draw a box on the screen representing the space taken up by the belowdecks portion of the part's collider. Vectrosity is very needs suiting.
|
|
#
?
Jul 30, 2019 03:38
|
|
|
World of Warships is entirely multiplayer isn't it? That's a pretty big difference by itself, but it also sounds like you are a bit more immersive and arcade-y. Despite the decent art the World of X games are kinda amazingly bad at immersion. They feel awkward and like I'm controlling a toy (sorta like most MOBAs to me). I've never had the enthusiasm to learn any of the games well enough to not get destroyed. A game where I can just sail around in a big boat blowing up AI sounds more fun.
|
|
#
?
Jul 30, 2019 09:19
|
|
|
leper khan posted:Vectrosity is very needs suiting. Thanks, bought it and got my lines working in maybe a couple of hours. I may well end up using it for my radar/sonar as well, and maybe a few other widgets. World of Warships does have bots, but (and I should probably at least play the game myself so I can better understand how it works) I gather they're on basically even footing with the player equipment-wise, and each play mode is a single fleet engagement. My game is more going to be about having a super-powered single ship that has to take on multiple enemy fleets in each mission of a campaign. Getting the gamefeel right on piloting a warship is going to be hard. Not only do I have no idea what it should feel like, neither will 99+% of the playerbase. It's all going to have to be about building plausibility and verisimilitude. If you have any specific points where you feel World of Warships fails to immerse, by all means let me know. But e.g. both it and my game will be cheating gloriously on how maneuverable ships are and how fast their guns reload, because only the most grognardy players would want to pilot ships that take multiple minutes to turn around and can only fire once or twice per minute. And my game in particular is going to feature explicitly implausible elements, from the player having access to a floating drydock and factory that produces the parts they put on their ships, to there being gigantic enemy superweapon bosses.
|
|
#
?
Jul 30, 2019 15:20
|
|
|
FuzzySlippers posted:World of Warships is entirely multiplayer isn't it? That's a pretty big difference by itself, but it also sounds like you are a bit more immersive and arcade-y. Despite the decent art the World of X games are kinda amazingly bad at immersion. They feel awkward and like I'm controlling a toy (sorta like most MOBAs to me). I've never had the enthusiasm to learn any of the games well enough to not get destroyed. A game where I can just sail around in a big boat blowing up AI sounds more fun. Yes multi only. WoWS is a ton of fun, also when you start (first 100 matches) they put you in a protected queue (other new players and bots) so you don't get destroyed. I personally couldn't get into WoT, it has a ton of busy work (ammo/crew) and doesn't protect new users. I'd really suggest trying WoWS if you have any interest, a game where you can sail a big boat blowing up AI sounds like a ton of phone as well.
|
|
#
?
Jul 30, 2019 15:32
|
|
|
TooMuchAbstraction posted:... FYI battleships in WoWS guns take 28-35 seconds to reload as was apparently realistic. Destroyers are a few seconds, and cruisers 1/2 way in between. Battleships hit so hard that it's incredibly tense waiting to shoot/afraid their reload is almost up. If you haven't tried WoWS and your making a boat game I'd suggest looking at it.
|
|
#
?
Jul 30, 2019 15:35
|
|
|
Stick100 posted:I'd really suggest trying WoWS if you have any interest, a game where you can sail a big boat blowing up AI sounds like a ton of phone as well. You might also want to see if you can try (or watch video of) Battlestations: Pacific, which is an older single player game where you get to drive around WW2 ships and blow things up 
|
|
#
?
Jul 30, 2019 16:16
|
|
|
Battlestations (both Pacific and its predecessor Midway) was an extremely good time, it "felt real" but was super arcadey so everyone could have fun with it. The boat controls in particular were extremely well done, you could lock the camera to a broadsides view which made it easy to exchange fire with another ship, and they had little LED type lights on the hud that would indicate which of your guns could shoot where you had the crosshairs aimed. The multiplayer was a riot too, they would plop a bunch of boats on two sides of a map and everyone would charge at each other like it was a pitched battle.
|
|
#
?
Jul 30, 2019 16:29
|
|
|
Here's another blind accessibility dev log/playthrough video. https://twitter.com/SEQUENCE_STORM/status/1156303341128835073
|
|
#
?
Jul 30, 2019 21:38
|
|
|
Hammer Bro. posted:Though I'd never heard of the phrase previously, I think what I'm designing is more similar to an eventually consistent one than a deterministic one. The only concerning corner cases have to do with the creation/destruction of objects, as the Godot networking abstraction I'm working atop considers it an error if you attempt to send a message to a client that does not have a copy of the receiving object. A keyword for you to look up is CRDT, or Conflict-free Replicated Data Type.
|
|
#
?
Jul 31, 2019 00:54
|
|
|
TooMuchAbstraction posted:botegames etc I absolutely loved Warship Gunner, and would desperately love more games like it I suspect their ship-design section was just ratcheting predetermined 2d shapes on a pair of grids, though, based on what I could see
|
|
#
?
Jul 31, 2019 17:08
|
|
|
LordSaturn posted:I absolutely loved Warship Gunner, and would desperately love more games like it Me too, which is why I'm working on this. More games need to combo design-your-own-whatever with an escalating part unlock system. It's a really cool take on the whole "RPG mechanics" thing. And you're probably right about their ship designer. Certainly I can't imagine they did some of the stupid algorithms I'm pulling on PS2 hardware. I'm going full-3D mostly to avoid having to draw two blueprint diagrams for every single part I model. But I am ratcheting the part positions so players don't have to try to finely-tune everything down to the millimeter. I haven't posted a progress image in a few days, so here's the undersides of gun turrets conflicting with the ship's boilers:  In Warship Gunner 2, parts can either be on the deck (optionally with some portion extending into the underdeck area, like the turret here), or along the bottom of the ship, with the latter being reserved for boilers/diesel/nuclear power and the ship's screws (propellers). Either way you don't get to choose the elevation of the part, which is convenient from a control perspective as it means there's only two axes you need to position the part along. I'm musing about whether I want to break that rule, mostly so that I can include parts like "radar room" and "damage control center" that would provide various other utility. Like, the radar room would of course expand your radar range, the damage control center speeds up repairs and firefighting, etc. I think probably the better bet is to say "there's a certain amount of volume in the hull; parts that extend into the hull use up volume. You can spend unused volume on abstracted rooms that boost your ship in various ways, and you can build extra rooms on the superstructure to provide more volume." It's less detailed, but I'm not sure that it would necessarily be fun to try to jigsaw a bunch of rooms into every spare bit of space in the hull, especially given the control complexity of trying to position something in 3D space.
|
|
#
?
Jul 31, 2019 17:40
|
|
|
TooMuchAbstraction posted:I think probably the better bet is to say "there's a certain amount of volume in the hull; parts that extend into the hull use up volume. You can spend unused volume on abstracted rooms that boost your ship in various ways, and you can build extra rooms on the superstructure to provide more volume." It's less detailed, but I'm not sure that it would necessarily be fun to try to jigsaw a bunch of rooms into every spare bit of space in the hull, especially given the control complexity of trying to position something in 3D space. I would definitely go with this. I would personally find it irritating that I can't put a gun where I want it because some largely-invisible room is blocking it and I have to go rearrange a bunch of junk belowdecks.
|
|
#
?
Jul 31, 2019 17:46
|
|
|
|
| # ? Jun 3, 2024 13:52 |
|
|
megane posted:I would definitely go with this. I would personally find it irritating that I can't put a gun where I want it because some largely-invisible room is blocking it and I have to go rearrange a bunch of junk belowdecks. Yeah, good point. I definitely want the guns to be able to interfere with critical underdeck parts like the boilers and screws, but having to shuffle around your radar room (which can probably go basically wherever as long as you can run signal wires) to make room because you want to move a gun 1m over sounds like a pain in the rear end.
|
|
#
?
Jul 31, 2019 18:26
|
|