|
One of the (static image) Facebook ads got a comment from someone who was dedicated enough to click through, watch the trailer, and then return and call BLM a "terrorist organization". Speaking of Facebook ads, the trailer ads were rejected by Facebook (I believe in fact by an automated algorithm) on the basis that they were too political 
|
#
?
Jul 30, 2021 02:46
|
|
|
|
| # ? May 25, 2024 08:04 |
|
|
TooMuchAbstraction posted:One of the (static image) Facebook ads got a comment from someone who was dedicated enough to click through, watch the trailer, and then return and call BLM a "terrorist organization". Facebooks core audience contains a not small number of chuds. You're game is obviously upsetting to them, due to some of the content (lol, I can't believe they're that easy to trigger). Not clear fb alg is wrong here for what they care about.
|
|
#
?
Jul 30, 2021 12:42
|
|
|
Well their bigoted worldview is being actively purged from the internet so some anger is expected. Not fast enough or effectively enough but they're dinosaurs getting real mad that the universe doesn't want them around.
|
|
#
?
Jul 30, 2021 13:43
|
|
|
It seems that negative reviews only impact sales among possible customers who are already sympathetic to the specific complaint described in the review.
|
|
#
?
Jul 30, 2021 22:44
|
|
|
Bongo Bill posted:It seems that negative reviews only impact sales among possible customers who are already sympathetic to the specific complaint described in the review. The main other thing they impact is the game's overall rating, and thus how heavily Steam prioritizes your game. If you have Overwhelmingly Positive, you get significantly better billing than if you have Mixed or merely Positive. The cutoff for Overwhelming is 95% and something like 1000 reviews; the cutoff for Very Positive is 80% and at least 50 reviews.
|
|
#
?
Jul 30, 2021 23:28
|
|
|
That just sucks. I don't have anything more I can really say.
|
|
#
?
Jul 31, 2021 07:04
|
|
|
Bongo Bill posted:It seems that negative reviews only impact sales among possible customers who are already sympathetic to the specific complaint described in the review. Occasionally you get negative reviews that can potentially help you, in the sense that they stand out a bit and it might give some people a better impression of your game I got this gem yesterday  So I'd hope that if you were checking out negative reviews, at least you'd find out that these kinds of things are taken seriously!
|
|
#
?
Jul 31, 2021 20:25
|
|
|
Didn't Battletech get slammed for weeks just for including an option for picking your pronoun? Gamers are crazy. Maybe you should reach out to somewhat lefty game sites about the review bombing? If it got some attention that'd probably end up a net positive
|
|
#
?
Jul 31, 2021 23:11
|
|
|
What are "somewhat lefty game sites" anyways?
|
|
#
?
Aug 1, 2021 01:18
|
|
|
Harminoff posted:Interesting, must be a godot issue but I'll look into it. Someone was trying to stream it and it kept crashing their stream. I got the same error in Chrome: 
|
|
#
?
Aug 1, 2021 06:16
|
|
|
Rocko Bonaparte posted:What are "somewhat lefty game sites" anyways? Rock paper shotgun, Waypoint, maybe Polygon? Haven't looked at the latter in a while. There's a ton of smaller sites as well of course.
|
|
#
?
Aug 1, 2021 09:21
|
|
|
One Eye Open posted:I got the same error in Chrome: Thank you! Looking into it, it seems to be an itch.io issue with Godot files, and cross-origin isolation which Chrome required on July 20th. https://itch.io/t/1332996/cross-origin-isolation-to-unblock-wasm-sharedarraybuffers Hopefully they get it resolved soon, but going forward I see the value of also packaging my games as a download as well.
|
|
#
?
Aug 1, 2021 15:50
|
|
|
Whenever I'm troubleshooting a web thing at work and I see the CORS messages show up in the log a little part of me dies. I absolutely hate dealing with it because it because everyone just says "allow everything! Easy peasy!!" and I hate doing things the lazy way and dive into properly populating the access-control-allow-origin field. And this all this happens because of cookies, the worst implemented standard ever added to browsers. Thanks for that one Netscape.
|
|
#
?
Aug 1, 2021 16:01
|
|
|
xzzy posted:Whenever I'm troubleshooting a web thing at work and I see the CORS messages show up in the log a little part of me dies. I absolutely hate dealing with it because it because everyone just says "allow everything! Easy peasy!!" and I hate doing things the lazy way and dive into properly populating the access-control-allow-origin field. CORS and datetimes that move across timezones are along my least favorite things.
|
|
#
?
Aug 1, 2021 16:03
|
|
|
Has anybody tried the Unity Editor on Linux? Is it actually official now? I saw something about 2021 and we're rolling past halfway through the year. I also wonder on the odds that extensions and addons will actually work with it too.
|
|
#
?
Aug 2, 2021 02:47
|
|
|
Rocko Bonaparte posted:Has anybody tried the Unity Editor on Linux? Is it actually official now? I saw something about 2021 and we're rolling past halfway through the year. I've used it. It's still not in full support. Extensions/add-ons are hit or miss, but most things work fine. You'll run into problems with things that rely on native libs -- most things don't.
|
|
#
?
Aug 2, 2021 03:51
|
|
|
I made a post in the Making Games Megathread asking for advice on my game's graphics. On the off-chance that there's anyone in this thread who doesn't follow that thread, I wanted to mention it here as well. What is the difference between the two threads, anyway? 
|
|
#
?
Aug 3, 2021 20:55
|
|
|
TooMuchAbstraction posted:What is the difference between the two threads, anyway? That thread leans towards more game design discussion and game jam stuff while this thread being in the cavern of COBOL has more of a technical bent and is more programming heavy but there's tooooons of overlap and the threads are more of a venn diagram.
|
|
#
?
Aug 3, 2021 21:09
|
|
|
There's been a lot more overlap (and a lot less traffic in this thread) since Unity and company severely reduced the amount of technical knowledge needed to make something. It's actually kind of staggering looking at the start of this 14-year time capsule of a thread and contrasting the kinds of stuff people were asking about then vs. now.
|
|
#
?
Aug 3, 2021 22:28
|
|
|
That makes sense; thanks for the explanation! And yeah, game development is way more accessible than it used to be. I remember back in 2008 wrestling with SDL and OpenGL, where even just getting your screen to be anything more than a black void took a lot of work and understanding of the rendering pipeline. On a different note: I need to retrofit undo/redo into my ship designer. The ship designer allows you to make ships by adding, moving, and removing parts from a ship deck. I didn't design the system with it in mind from the beginning, so I'm not really sure how best to implement it. Any good insights here? Off the top of my head I'd think something like this: Whenever a noteworthy change to the ship is made, we record a ShipChange. ShipChange has a variety of subclasses for specific types of changes, but all of them can be executed forwards or backwards. That is, they apply some change to the ship, or they can un-apply that change. For example: - PartMovedChange: a part on the ship was moved from point A to point B (and possibly rotated). We store the transformation matrices of the part before/after the move, as well as the dbName of the part (dbName being a unique string that indicates which type of part, but does not reference a specific instance of that part). Applying the change in either direction means finding an existing matching part at one endpoint, and the applying the transformation matrix to get it to the other endpoint. - PartAddedChange: a part was added to the ship. We just store the transformation matrix and dbName. - SpecialsChange: the ship's activated special powers were changed. There's one dbName per each of the 3 special slots. - and so on... Then the designer controller maintains a list of these changes, and an index into the list. When you press Undo, it reverts the current change and moves the index back 1. When you press Redo, it applies the next change and moves the index forward 1. If you make a change when not at the end of the list, everything after the index is destroyed.
|
|
#
?
Aug 4, 2021 23:54
|
|
|
How much data is the state of the whole thing? It might not be a big deal to store the whole state and step through that, as long as we're not talking about something massive. Not very elegant but hopefully straightforward and more robust.
|
|
#
?
Aug 4, 2021 23:59
|
|
|
Lemming posted:How much data is the state of the whole thing? It might not be a big deal to store the whole state and step through that, as long as we're not talking about something massive. Not very elegant but hopefully straightforward and more robust. That was my initial thought, but I worried about performance. In the Unity editor, with deep profiling on and a really complicated ship, it takes 4.5 seconds to load the ship. A more reasonable ship still takes 1.8 seconds. Even if I apply a 10x speed penalty for deep profiling in the editor, that's still not great performance. Most of that time is spent on calculating firing angles for all of the guns on the ship, which the game has to do de novo each time it loads a new ship. If it does an incremental change, then it only has to recalculate the weapons affected by that change...but if I destroy and recreate the ship each time undo/redo are pressed, then I can't benefit from that. Or are you suggesting that I store the state of the entire ship, and then when undo/redo are pressed, I analyze and apply the state changes necessary to change the ship without blowing the old one away and recreating it from scratch? That sounds in principle doable, but I'd worry about failing to correctly detect a change. Effectively we're talking about writing a "diff tool" and corresponding "patch tool". ...wait, parts are stored in the JSON as one part per line. Maybe I could literally call out to diff to get the changed elements? I'd still need to figure out the context for a change...e.g. whether a changed line was adding a part on deck, or a new radar, is hard to tell because they use identical serialization styles but are stored in different lists. But at least for parts, I could conceive of getting a diff like code:
|
|
#
?
Aug 5, 2021 00:16
|
|
|
What you're describing is basically the command pattern which is one of the best ways to do undo/redo for sure. How detailed you want to get about mapping everything into classes is really up to you. I personally wouldn't worry too much about class modeling for something so single purpose. For transforms I would suggest just storing the matrix that encodes the actual transform. And you can always use the inverse of it to undo the transform later without having to store before after snapshots. novamute fucked around with this message at 00:59 on Aug 5, 2021 |
|
#
?
Aug 5, 2021 00:56
|
|
|
novamute posted:What you're describing is basically the command pattern which is one of the best ways to do undo/redo for sure. How detailed you want to get about mapping everything into classes is really up to you. I personally wouldn't worry too much about class modeling for something so single purpose. I get what you're saying -- if I have an object, and a transformation of that object, I can just store "hey apply this transformation forwards/backwards to the object". But my concern is that when objects get deleted/re-added, I'll "lose track" of them, i.e. references will become stale. So I'm imagining taking the part's dbName and position, and searching through the parts on the ship to find the specific one I want to transform. If I have to do that, I might as well store the full before/after transformation matrices for the part. Good to hear that the basic design makes sense though. I'm awful at remembering design patterns by name, but I can usually re-invent them on the fly as need be 
|
|
#
?
Aug 5, 2021 02:11
|
|
|
One thing I would add is that using two stacks (one for undo, one for redo) is a bit simpler than using a list and fiddling with indices. Every change command is pushed onto the undo stack, undo pops off that stack and pushes onto the redo stack. Redo does the opposite. This is a really common approach. You can control memory usage by limiting the stack sizes.
|
|
#
?
Aug 5, 2021 07:09
|
|
|
novamute posted:For transforms I would suggest just storing the matrix that encodes the actual transform. And you can always use the inverse of it to undo the transform later without having to store before after snapshots. If your undo/redo path is intended to only operate on undo/redo (and not, e.g. "undo only the operation I did 3 actions ago and keep the ones after it"), and you want to be able to walk the stack without replaying, then for precision's sake it makes more sense to store the "before" transform in your undo stack, and the "after" transform in your redo stack, than to store just one transform and apply it to "the canonical data". Or always store "before and operation" then you can walk both ways and get consistent results and you can also revert single operations from elsewhere in the stack. roomforthetuna fucked around with this message at 12:56 on Aug 5, 2021 |
|
#
?
Aug 5, 2021 12:53
|
|
|
roomforthetuna posted:Careful with that approach - if you keep applying two transformations back and forth your transformed data will tend to distort as the number of iterations goes up, due to floating point imprecision. Such a non-determinate undo would not make me happy. I guess there wouldn't be much deviation due to floating point unless you store forward/backward commands for every frame as "move by this much", but yes, having setPosition is still more sensible. Still I think it is much easier to do snapshots after every user action if you're not dealing with large data. If initializing it every time takes too much time, optimizing it will help also overall loading times, etc. If there is something like "calculating firing angles" that takes most of the time and cannot be optimized further, maybe there is an option to let it calculate in the background. User probably won't need it immediately. Of course it is much easier said than done
|
|
#
?
Aug 5, 2021 13:33
|
|
|
Adhemar posted:One thing I would add is that using two stacks (one for undo, one for redo) is a bit simpler than using a list and fiddling with indices.  that makes a ton of sense, thank you! I got the most basic command (adding a part) working yesterday, but of course ran into bugs with where exactly I was in the list of commands. Two stacks should make that much easier.commando in tophat posted:Still I think it is much easier to do snapshots after every user action if you're not dealing with large data. If initializing it every time takes too much time, optimizing it will help also overall loading times, etc. If there is something like "calculating firing angles" that takes most of the time and cannot be optimized further, maybe there is an option to let it calculate in the background. User probably won't need it immediately. Of course it is much easier said than done Unfortunately, the firing angle calculations are really complicated and rely on the physics engine because they're figuring out how far guns can turn without bonking into things. And they add a lot of depth to the puzzle of designing your ship. I've done a lot of work already on making sure they don't do any work they don't have to. But there's just so much you can do when the basic approach is "rotate this set of colliders in 5-degree increments and then check if they overlap anything nearby".
|
|
#
?
Aug 5, 2021 15:38
|
|
|
TooMuchAbstraction posted:Unfortunately, the firing angle calculations are really complicated and rely on the physics engine because they're figuring out how far guns can turn without bonking into things. And they add a lot of depth to the puzzle of designing your ship. I've done a lot of work already on making sure they don't do any work they don't have to. But there's just so much you can do when the basic approach is "rotate this set of colliders in 5-degree increments and then check if they overlap anything nearby". It sounds like you already serialize your ship state, albeit without the calculated firing angles included. What if you serialize those calculated firing angles for each ship part alongside their ID/name/location/rotation(/etc)? Then reinitializing the ship state should be far quicker -- since you're using the cached results of a bunch of expensive calculations rather than recalculating it all from scratch -- and would be useful in particular for executing undo/redo actions, but also for loading from a save file. And even if you don't trust user-modifiable save files, you could still instantiate the ship's parts using the cached firing angles, and then iff loading untrusted data you just rerun the firing angle calculations in a background "firing angle calculations" queue; once they complete, you can update the firing arc visualizations if they were incorrect, and also mark the current ship state as VERIFIED SAFE so it can be placed in the undo/redo stacks. You wouldn't need to do any recalculations when executing undo/redo actions by swapping snapshots between the stacks and the active ship state, since you'll be working only with known-good state at that point.
|
|
#
?
Aug 5, 2021 16:33
|
|
|
I do serialize the state inclusive of firing angles, but I don't store a complete cache of all of the data recorded when calculating angles. It's not just angles but also stuff like what the colliders are on the gun and what objects got in its way. That helps me detect when the cache needs to get invalidated. I mean, you're right, in principle I could repopulate the cache based on serialized state. But I've had enough cache-invalidation bugs around this code already to be kind of leery of trying to make it even more complicated. The good news is, I've gotten basic undo/redo working: https://twitter.com/byobattleship/status/1423429637296726018 Just for part placed/moved/removed, but that should be good enough to handle 95+% of cases where people want undo/redo support.
|
|
#
?
Aug 6, 2021 00:56
|
|
|
New problem that's driving me mad: my hitscan guns can't aim properly if they're upside-down. This is a problem because one of my bosses is a flying battleship which flies using giant rocket thrusters, and you're supposed to get damaged if you sail through the rocket plumes. So I put hitscan weapons pointing down below it, and the idea was that they'd track the player and fire invisible bullets if the player was underneath the ship. They're not tracking properly though, and I cannot for the life of me figure out why. Here's some screenshots from the editor view showing the actual aiming behavior. I have a gizmo on the gun that indicates its true aim. It's a white line to indicate that the gun thinks it has a lock. You can see that the gun seems to be aiming counter to the direction it should be aiming in. The middle shot has the gun actually aimed roughly correctly, and when that happens the player does get hit by bullets, but it's super inconsistent.    And the same thing happens when moving perpendicular:    The guns use a "turret" bone and a "barrel" bone to animate. The first points the gun as a whole at the target, the second rotates the barrel up/down to set the elevation. The gun has minY/maxY that limit the turret rotation, and lowestAim/highestAim that limit the barrel rotation. The gun thinks that it's correctly locked onto the target, but its bullets aren't hitting. code:Example debug output: quote:Target at (0.0, 3.6, 0.2) a.k.a. (-14.8, 95.2, 4.9), barrel at (0.0, 1.5, 0.0), so fireVec (-0.2, 1.0, 0.1), wantY -71.46854, elev -9.4133, limited False, locked True Any ideas? I'm at my wit's end with this stuff.
|
|
#
?
Aug 18, 2021 19:09
|
|
|
Is there a reason why you don't want to/can't use a traditional hitbox? Basically just a cylindrical or capsule shaped trigger volume attached to each thruster with a script on it that damages anything it touches in OnTriggerStay. I get the impulse to reuse existing methods, but sometimes doing something "for real" can actually be the simplest option.
|
|
#
?
Aug 18, 2021 20:31
|
|
|
Technically speaking, you're right. My main concern is that later on in the game, I'm going to want to have actual guns mounted on the sides/undersides of bosses, and I want those guns to work as well.
|
|
#
?
Aug 19, 2021 01:05
|
|
|
It seems strange that your supposedly normalized fireVec does not have overall length 1.
|
|
#
?
Aug 19, 2021 03:09
|
|
|
Jabor posted:It seems strange that your supposedly normalized fireVec does not have overall length 1. Blame Unity for that one; it rounds the string representations of vectors to the nearest tenth of a digit by default. Very annoying, and a pain in the rear end to override too.
|
|
#
?
Aug 19, 2021 03:52
|
|
|
I was writing something up about what sort of debugging strategies I'd employ to try and figure this out, but had a little spark of insight while I was doing so. Why are calculating fireVec to be from the barrel's current position to the target?
|
|
#
?
Aug 19, 2021 04:11
|
|
|
Are you talking about the barrel's position changing as the turret rotates? I don't think that's enough to explain the behavior I'm seeing; the difference between "target minus final desired barrel position" and "target minus current barrel position" is minor. Plus this code gets called every frame, so the error will approach zero anyway if the aim is at all working properly. Which it isn't, currently.
|
|
#
?
Aug 19, 2021 05:05
|
|
|
I realize this question is just going to highlight how much I need to just buckle down and actually learn some vector math but... (In godot fyi) Say I want the camera to follow some arbitrary point between the cursor and the player. I can do this to get a point equidistant between them: code: and I can further get a point equidistant the between the player and the last halfway point to get a quarter-of-the-way point: code: But what I'd actually like to do is be able to get some arbitrary point along that line instead of subdividing over and over to adjust the distance, but multiplying the vector by anything other than 0.5 like this code: So I'm super certain I'm going about this the wrong way, but googling hasn't turned up much help, mostly just 'how do I get the middle between two points' questions and answers, which I'm obviously already doing So goons... tell me how dumb I'm being (please)
|
|
#
?
Aug 22, 2021 15:35
|
|
|
don't know godot syntax butcode:Jewel fucked around with this message at 15:48 on Aug 22, 2021 |
|
#
?
Aug 22, 2021 15:45
|
|
|
|
| # ? May 25, 2024 08:04 |
|
|
Jewel posted:don't know godot syntax but Well that was fast! Thanks for the explaination. Makes sense and works perfectly
|
|
#
?
Aug 22, 2021 15:49
|
|