Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›623 »

Rickshaw: Apr 11, 2004; just a coconut going for a stroll

I'm working on a hobbyist indie adventure game in Unity. I wanted random characters to appear at various places in the game world, so I wrote a person randomizer script. A simple one-line bug resulted in this most interesting bug:

# ? Jan 25, 2020 22:35

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 14:34

TIP: Mar 21, 2006; Your move, creep.

Rickshaw posted:

I'm working on a hobbyist indie adventure game in Unity. I wanted random characters to appear at various places in the game world, so I wrote a person randomizer script. A simple one-line bug resulted in this most interesting bug:

You're ready to make a Scanner Darkly game.

# ? Jan 26, 2020 00:03

ButtWolf: Dec 30, 2004; by Jeffrey of YOSPOS

Rickshaw posted:

I'm working on a hobbyist indie adventure game in Unity. I wanted random characters to appear at various places in the game world, so I wrote a person randomizer script. A simple one-line bug resulted in this most interesting bug:

Yeah, this isn't a bug. These are called "new features".

# ? Jan 26, 2020 01:31

Angryhead: Apr 4, 2009; Don't call my name
Don't call my name
Alejandro

ButtWolf posted:

Has anyone here made a procedural tilemap generator in Unity? I'm essentially going for Dead Cells. I sort of know how I'm going to approach it but I am just looking for maybe some tips n tricks that you learned while doing it. Maybe small things that tripped you up. Thanks.

The general #1 tip I wish I had heard before we started is to first build the maps you'd want to achieve by hand and only then start working on procedurally generating them.
Tiled is neat, and I use it for some prefab rooms in Escape from Aeon - and actually wrote a blog post about map gen in Escape from Aeon a while ago; maybe there's something in there you find useful.
The "map testing tool" I've found really worth the time investment; to be able to directly tweak parameters and just rebuild a level is great for fast iteration.

# ? Jan 26, 2020 13:33

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Angryhead posted:

The general #1 tip I wish I had heard before we started is to first build the maps you'd want to achieve by hand and only then start working on procedurally generating them.

Yeah this is super important.

Also recognize that if you are trying to minimize building maps, building a good random map generator that isn't bad is going to be like 10x as much work.

# ? Jan 26, 2020 17:23

ButtWolf: Dec 30, 2004; by Jeffrey of YOSPOS

Angryhead posted:

The general #1 tip I wish I had heard before we started is to first build the maps you'd want to achieve by hand and only then start working on procedurally generating them.
Tiled is neat, and I use it for some prefab rooms in Escape from Aeon - and actually wrote a blog post about map gen in Escape from Aeon a while ago; maybe there's something in there you find useful.
The "map testing tool" I've found really worth the time investment; to be able to directly tweak parameters and just rebuild a level is great for fast iteration.

Hell yeah, THis is exactly what I needed.

# ? Jan 27, 2020 01:21

Calipark: Feb 1, 2008; That's cool.

If anyone is looking for a large chill game dev Discord server. The Awful Jams discord has more or less become a place to hang and get help or feedback.

You can hop in here: https://discordapp.com/invite/UwXZtgJ

Be sure to introduce yourself or show off your stuff in the #your-game channel!

Calipark fucked around with this message at 05:55 on Jan 29, 2020

# ? Jan 29, 2020 05:45

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Synopses:

It's a dungeon building game focused on security, agents have keycards with regimented access to certain doors. Think security levels 1-4, and corresponding doors with security levels 1-4. While you can build your base in any shape and place doors wherever you want in any configuration.

Problem:

It's a management simulation, these AI's need to pick jobs to do off the stack and go do them. But some will not be able to get to some jobs due to their security access. Therefore it seems beneficial to categorise jobs based on what security access they require. Which means examining the tile they are on and what security access that tile requires. Therefore I need an algorithm I can run that is reasonably efficient that will assign a security level to every tile, and update when either a hallway connects, or a new door with whatever security level is added.

I've got some idea. I'll start somewhere outside at security level 0 or whatever, and just flood fill as far as I can. I think I can fill the whole map this way on load but it seems unreasonable to remap the whole darn thing whenever anything is changed. Seems like flood fills will be necessary and seems like whenever I'm flood filling and run into a lower security level, switch to that security level. Lower levels always override higher levels. If I have a hallway at level 2 and I place a level 4 door in the middle of it. Well then what side of the door is level 4 you know?

I'm thinking about scrapping the whole security door idea unless I can nail down a conceptualisation of this functionality. Just wondering if there's a solution out there.

Nolgthorn fucked around with this message at 11:41 on Jan 31, 2020

# ? Jan 31, 2020 11:32

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

So while I'm flood filling and I pass through a door I store what direction I passed through it. Which is beneficial anyway since even though the door is bi-directional, someone stuck in level 4 who only has level 3 access doesn't make sense they should be able to go through.

So then while I'm filling if I hit a door and it's facing in I know I'm done. And if it's facing out then I know I can keep going... ?

:raise:

Somebody stop me trying to implement this.

# ? Jan 31, 2020 11:58

Purple Prince: Aug 20, 2011

Prison Architect just handles this by not having a security door mean anything in particular and making players allocate the security level on each side of the door manually. You could try this approach. Alternately you could make players choose which side of the door is higher security when a security door is placed.

# ? Jan 31, 2020 11:58

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I could more easily recalculate all tiles if I track rooms as entities.

So a room would be a collection of tiles that exist between doors. Then I could track the whole map in terms of "this room connects to this room through this door" and it would be significantly less complicated to work out. The biggest challenge then would be keeping track of which tiles belong to which rooms. But that shouldn't be as daunting.

Prison architect:

I'm fairly opposed to the zoning mechanic like seen there. I want it to feel a little bit more organic.

# ? Jan 31, 2020 12:20

Star Warrior X: Jul 14, 2004

If it's tile-based, I don't think flood fills on each change would be too computationally expensive You could simply do four separate floods, one for each security level. Each flood can be blocked by higher-level doors and pass through equal or lower doors. This will also be useful since you will want to be able to give players an overlay showing what security level each tile is anyway, so they can accurately diagnose a misplaced door.

# ? Jan 31, 2020 14:07

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I kind of like that because it would be the totally fool proof, brute force method. You don't think it will be expensive to flood fill the entire map? We're talking about 36,000 tiles total (if there were no walls anywhere) and doing that 4 times. I'd love for that solution to work because it could never bug out.

On the other hand I'm daydreaming what type of new mechanics having rooms could add now.

Nolgthorn fucked around with this message at 15:58 on Jan 31, 2020

# ? Jan 31, 2020 15:55

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

Alternatively, you could build the "security door" determination into the pathfinding the AI uses to get to the job. If the AI can successfully pathfind to the top job on the stack, it takes it, otherwise it goes to the next job on the list.

# ? Jan 31, 2020 16:14

KillHour: Oct 28, 2007

HappyHippo posted:

Alternatively, you could build the "security door" determination into the pathfinding the AI uses to get to the job. If the AI can successfully pathfind to the top job on the stack, it takes it, otherwise it goes to the next job on the list.

The point of precalculating this is it makes pathfinding a lot faster. An A* pathfind to somewhere you can't reach is a flood fill.

# ? Jan 31, 2020 16:17

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

KillHour posted:

The point of precalculating this is it makes pathfinding a lot faster. An A* pathfind to somewhere you can't reach is a flood fill.

That's a fair point. I guess it depends on how many "regions" there are on the map. If all the zones of a given security level are connected, then yeah a pathfind will flood fill all the tiles at that security level. If they are broken up into numerous regions, then trying to pathfind out will flood fill just a portion.

# ? Jan 31, 2020 16:27

OtspIII: Sep 22, 2002

I definitely advise going quick, dirty, and inefficient on this right now and using flood fill until you hit player-noticeable slowdown. It sounds like you don't have your design locked down yet, so trying to get clever or elegant with your code is just a recipe for making it hard to iterate going forward.

# ? Jan 31, 2020 16:37

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I'm prototyping this right now.

I have `tile` entities and I'm adding `room_id`. I have `door` entities adding `room_id1` and `room_id2`. My `room_id`s map to dictionaries that so far only contain `security_level`. For any `tile` I can look up the `room_id` and get back the `security_level`, for any `door` I can look up the `room`s it touches.

Something like:

code:

# We are removing room_id2
func combine_rooms(tiles: Matrix3, room_id1: int, room_id2: int) -> void:
	# Update security level to lowest
	_rooms[room_id1].security_level = min(_rooms[room_id1].security_level, _rooms[room_id2].security_level)
	# Update tiles to new room
	for tile in tiles.cells:
		if tile.room_id == room_id2: tile.room_id = room_id1
	# Update door pairings
	var doors: Array = find_doors(room_id2)
	for door in doors:
		if door.room_id1 == room_id2: door.room_id1 = room_id1
		if door.room_id2 == room_id2: door.room_id2 = room_id1
	# Erase room
	_rooms.erase(room_id2)

func find_doors(room_id: int) -> Array:
	var result: = []
	for door in _doors:
		if door.room_id1 == room_id or door.room_id2 == room_id:
			result.push_back(door)
	return result

If I have rooms like this being maintained on either side of doors then using flood will be about 1000x less computationally expensive, and I'll be able to maybe color the floors and walls depending on security level. Feels like I rubber ducked you guys. If I go insane I may revisit the brute force method mentioned above.

Pathfinding:

The other issue is a job might involve a few stops, pick up a tool and use it for example. So I'd need to figure out ahead of time whether they could path to two locations.

Edit:

The post above this one is probably totally right.

# ? Jan 31, 2020 16:39

KillHour: Oct 28, 2007

HappyHippo posted:

That's a fair point. I guess it depends on how many "regions" there are on the map. If all the zones of a given security level are connected, then yeah a pathfind will flood fill all the tiles at that security level. If they are broken up into numerous regions, then trying to pathfind out will flood fill just a portion.

It will flood fill into any area of equal or lower security levels because a level 3 guy can walk through a level 2 area to get to a different level 3 area. Considering most of the map will probably not be the highest security level, this basically means a flood fill of most of the map.

# ? Jan 31, 2020 16:46

Grace Baiting: Jul 20, 2012; Audi famam illius;
Cucurrit quaeque
Tetigit destruens.

I would suggest doing just a single flood fill like a path search, except instead of storing distance_from_start in each tile, you store a security_level value that only changes (within each search iteration) when it steps through a security door.

This is just a generalized cost search through your graph, where the only edges that increase the cost of a path are the security doors themselves. You also don't need to store the parent node since you're not actually reconstructing an optimal-cost path afterwards.

So start with something like this:

code:

# initialize
for tile in all_tiles:
    tile.sec = inf
q = priorityqueue()
add initial security_0 tile(s) to q
for tile in q:
    tile.sec = 0

Whenever a security door is permanently opened, reinitialize the queue with the adjacent tile that has the lower security level (skipping if they're equal)

code:

# update security
if tile_a.sec < tile_b.sec:
  q.push(tile_a)
elif tile_a.sec > tile_b.sec:
  q.push(tile_b)
else:   # nothing needs to be updated
  pass  # if both tiles had equal
        # security levels

And then, after either initializing or opening a door, run the following:

code:

# search
while q is not empty:
  curr = q.pop()
  for tile in curr.neighbors:
    door = door_sec(curr, tile)
    new_sec = max(door, curr.sec)
    if tile.sec > new_sec:
      tile.sec = new_sec
      q.push(tile, tile.sec)

door_sec is a function that returns the security level of a door between two adjacent tiles, or 0 if there's no door.

I'm suggesting a priority queue as a minor optimization, since that will reduce the number of times a single tile gets added if there exist any security doors that don't actually partition your level. A regular queue should have an identical result.

OtspIII posted:

I definitely advise going quick, dirty, and inefficient on this right now and using flood fill until you hit player-noticeable slowdown. It sounds like you don't have your design locked down yet, so trying to get clever or elegant with your code is just a recipe for making it hard to iterate going forward.

...although this is a compelling point, especially since my assumptions above (especially "security doors only ever open permanently") may not hold, and actually making your entities path through the world will be tied up into this with extra complexity.

Room-based security stuff sounds reasonable to me though!

# ? Jan 31, 2020 16:55

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

My self-written "malleable depending on how annoyed I get" design document stipulates that security doors failing can happen. A nearby power generator might to go offline for example, or the door itself is damaged. Further, the building stuff mechanic is core to the greater system. So I hopefully will be able to make updates to the secured areas easily and rapidly.

That's why it feels like not so much a premature optimisation trying to get my hands around this.

# ? Jan 31, 2020 17:23

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

I'm going to advocate for the pathfinding approach one last time. For two reasons:

First, you'll have to add the capability to the pathfinder regardless. Even if you know an agent can reach a particular location, you still need to find a path there through the appropriate doors. So if you're adding that to the pathfinder, you might as well see if it's "good enough" to just use that capability to determine tasks. If it isn't you can try the flood filling as an optimization later.

Second, it's more robust. How does the flood filling handle this situation?

What security level is required to get to the central room? If an agent it starting in the left area, then it's level 1. But if they start on the right, it's level 2. If you use the pathfinder, it's no problem.

You also mention that doors can be altered by the user/lose power. This could leave agents "stranded." How does flood-fill handle this? For example, say there's an agent at A with level 1 clearance here:

Now suppose that the left-most door is deleted/fails. Using flood-fill, the big room B is now level 2. But the agent at A can still reach areas in that room. But the flood-fill approach would tell that agent it couldn't do any tasks there. With pathfinding it'll just work.

# ? Jan 31, 2020 21:04

TIP: Mar 21, 2006; Your move, creep.

I'm working on adding a VR mode to my unity game, my needs are pretty simple and I don't want to spend forever reinventing the wheel so I was thinking about using VRTK. Is that still the recommended framework for VR interactions?

It worries me a little bit that the last release was about a year ago. I don't want to get deep into integrating it just to discover that it's outdated in some terrible way.

HappyHippo posted:

I'm going to advocate for the pathfinding approach one last time.

This whole discussion has been interesting even if it's totally out of my depth, but I just wanted to say, what a great post. Posts like this are why I read this thread.

# ? Jan 31, 2020 21:21

KillHour: Oct 28, 2007

The idea would be to use the preprocess step to find contiguous areas of connectivity and use the results of that to inform the pathfinder. To use your examples, the first one would result in a graph that looks like this:

The connectivity part of the pathfinder would only need to determine if there exists a path through this trivial graph without any edges greater than the agent's allowed access to know if there is a valid path. Once that's determined, the detailed pathfinder would only care about finding a path through each node of the graph, and not the level as a whole. Yes, this means you can create contrived examples where the pathfinder won't pick the shortest path, but instead the path with fewer security doors, but 1: that's fairly realistic because most people would generally choose fewer security checkpoints over a shorter walking distance and 2: you can add weights to the graph to favor certain nodes over others based on size/shape/whatever.

In your second example, the graph would look like this:

If you deleted the level-1 connection between B and C, the agent could still move freely between A and B, but not go to C.

As for how you would display that to the player, the easiest might be to have a placeable pin that defaults to "outside" or wherever stuff spawns on the map and shows the minimum level required to get to each area. If you move the pin, the display updates.

KillHour fucked around with this message at 21:33 on Jan 31, 2020

# ? Jan 31, 2020 21:27

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

KillHour posted:

...

Ah, so this looks more like segmenting the map into rooms, then assigning security doors as edges in the graph (but not to the rooms themselves). That could certainly work. However it looks like some of the other discussion is about attempting to assign a "security level" to each tile, which could run into the issues I showed.

# ? Jan 31, 2020 21:45

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Yeah sorry, I meant to mention that a key piece of information would be the `security_level` on the doors themselves the rest of that stuff is sort of like caching but more importantly it informs as to which room the agent is currently in and where they are going though use of the tile's room_id.

Being able to instantly figure out the security level of the tile is just a bonus.

Nolgthorn fucked around with this message at 02:46 on Feb 1, 2020

# ? Feb 1, 2020 02:36

Tempora Mutantur: Feb 22, 2005

I just wanna say that this has been a super helpful discussion for general graph-traversal-stuff-related-to-proc-gen-maps and I really appreciate what everyone's posted.

Also, this is great advice:

OtspIII posted:

I definitely advise going quick, dirty, and inefficient on this right now ... until you hit player-noticeable slowdown. It sounds like you don't have your design locked down yet, so trying to get clever or elegant with your code is just a recipe for making it hard to iterate going forward.

Tangential, but I really enjoyed the talk from one of the Crashlands devs, "Design by Chaos" https://www.youtube.com/watch?v=WtDPNoVGZIw

# ? Feb 1, 2020 03:48

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I've build a function that takes two vectors and a security_level then returns an array of doors.

That operation should be very inexpensive relative to the tile system's astar implementation. Using that, I'm able to figure out if an agent can get somewhere and which doors to use in order to do it. The heuristics are still calculated using real distance between the doors so I don't think it'll ever pointlesly send them on an adventure across the whole base.

Now it's only a matter of pathfinding between doors. If a door ever stops working or comes back online it should be trivial to recalculate the "low resolution" pathfinding of all agents from wherever they currently are.

I've also built a function that updates the security level of all the rooms. It starts by setting all rooms to level 5, the outside to level 0, and then tries it's best to set all rooms to the lowest value it can. If it runs into a more secure door it increases it's paint value to match the level of the door. It quits if it runs into a lower level room because it's assumed there's an easier way to get there.

This all seems to be working.

So I've essentially got the brute force method and I've got the fancy method. Thanks your suggestions it was a big help.

Nolgthorn fucked around with this message at 11:36 on Feb 1, 2020

# ? Feb 1, 2020 11:34

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I've got a video of what I did because I'm proud of myself. My function takes an array of tiles, and recalculates all the rooms touching those tiles. This is necessary because when I put down an object in a room I need to check all the surrounding tiles of that object and repair the room. I could split a room in half with statues perhaps.

In the case of doors you'll almost certainly be splitting a room in half.

So I pass all the tiles that surround the door and it recalculates all the rooms they touch. It's also possible to place an object (or a door) in the middle of a room, not splitting the room in half at all. Or maybe it's a door that goes outside, so one side of the door is a new room and the other side isn't.

Out of all the things I tried the "give it an array of tiles for it to figure out" wound up being the easiest way to build an api in this case.

It flood fills using connections found in astar starting at one of the tiles, collecting all the tiles that makes up a room. I check all those tiles to see which rooms they used to belong to. Pick one, or create a new one if needed, set all tiles to be part of that room, then remove all the tiles from the "array of tiles to check" array and move on to the next one.

This demo has my "room debugging tool" enabled where each room is a random colour.

With room entities accurately reflecting the shape of the map, I'm able to set security levels for all of the rooms by traversing the simplified grid from outside. I can recalculate room security levels quickly, and because pathfinding is always going to start at the "how do you get to this room" level, I can also recalculate everyone's pathfinding quickly. I'd show a demo of that but it's my first astar implementation and I broke it an hour ago somehow.

The important thing is now I won't need to be careful about how often the map gets shifted around.

I tried a solution that reconstructed all the rooms on the map, like it does when the game loads, instead of the before mentioned "check these tiles" solution. But it's probably slower. It's basically the same thing except instead of being given <20 tiles to start with, it's given all 36000.

Thought I'd share.

Nolgthorn fucked around with this message at 06:33 on Feb 6, 2020

# ? Feb 6, 2020 06:06

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Here you go dudes. This is my working security doors demo too.

# ? Feb 6, 2020 09:51

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

So lets say I have a camera 25m in the air at a 45 degree angle with a raycast as a child, and I want to calculate how far away from the camera I need to move the raycast so that it doesn't collide with anything higher than 1, 2, 3, 4, 5, or 6 units above the plain. Where a unit is 1.7m. How would I calculate that?

Is it (25 - (n * 1.7)) * 1.5?

Because it's 45 degrees, I think it might be 1.5....

Apparently "The length of the diagonal of any rectangle equals the square root of the sum of the squares of its length and width." But that doesn't take into account that 45 degrees won't be an actual diagonal of a rectangle it would be the diagonal of a square.

Does that work when the camera could have any rotation around it's pivot? What about that the raycast moves around the surface of an orthagonal camera, doesn't that mean it's also moving up and down too? Some equation that figures out where it would collide with a plain and then only caring about what's below that plain would be what I'm looking for.

I think in godot I can't just "get an array of everything hit" and then filter out the hits above a certain y transform, without casting multiple times anyway, maybe I should do that

# ? Feb 8, 2020 03:05

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I know the transform of the pivot point is exactly where the raycast would hit if it were coming from the centre of the camera.

If I calculate the length of a raycast as equal to the distance from one plain to the next one, times however many units I want, somehow translated by the raycast's offset to the camera in relation to how it would be projected onto a plain. And then start the raycast from that point then my head explodes.

# ? Feb 8, 2020 03:25

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Nolgthorn posted:

So lets say I have a camera 25m in the air at a 45 degree angle with a raycast as a child, and I want to calculate how far away from the camera I need to move the raycast so that it doesn't collide with anything higher than 1, 2, 3, 4, 5, or 6 units above the plain. Where a unit is 1.7m. How would I calculate that?

I don't understand the question. First off, to me a raycast is a verb (or a function call), not an object in the world, so I don't know what it means for a raycast to be a child of an object. But secondly, you haven't defined the length of the ray, which is critical for determining whether it will hit things a set distance away.

If your goal is to position the camera a fixed distance away from whatever object is directly in front of it, I'd be doing something like

code:

fire very long ray from camera's position along camera's look vector
if the ray did not hit anything, uhhh choose a default camera position
otherwise, x = distance the ray traveled before hitting something
y = distance we want the camera to be from object
translate camera along its look vector by (x - y)

# ? Feb 8, 2020 03:48

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

The raycast node in godot is just an origin point and a direction. Because it can be set as a child it is convenient that it has the parent node's transform, I can simply adjust origin x to set how far away from the camera it is. The length of the ray isn't important because I'm trying to move the raycast further away from the camera so that it doesn't hit a lot of things.

I want it only to hit things that are below a certain world point y. There are more things above that world point y which would be in the way if I kept the raycast origin at the camera.

# ? Feb 8, 2020 05:54

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

OK, so you have the camera's position and aim vector, and you want to figure out how far along the camera's aim vector to position a point such that that point's Y component equals some set value?

code:

cam = camera position (XYZ)
aim = camera aim vector (XYZ)
wantY = desired altitude (Y)
deltaY = wantY - cam.y // how far we have to move in Y axis
finalPos = cam + aim * (deltaY / aim.y)

In other words, we know where we start (at cam) and how we move (by sliding along the aim vector). We just need to know what to multiply the aim vector by. That gives us the equation cam.y + X * aim.y = wantY where X is the amount we need to move. Rearrange that to isolate X and you get (wantY - cam.y) / aim.y = X

# ? Feb 8, 2020 06:07

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I'm not sure how that equation works, I think it's confusing because the aim vector is at an angle in 3d space but your equation only takes into account y. Not to say it isn't correct, but what I really think I need is to calculate the intersection point between a line and a plane. The best (simplest) I can come up with is something like this:

http://paulbourke.net/geometry/pointlineplane/

With that in place I'd be able to easily position the raycast's origin. Unfortunately I'm too stupid to understand.

Nolgthorn fucked around with this message at 06:20 on Feb 8, 2020

# ? Feb 8, 2020 06:17

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

It doesn't matter what the rest of your rotation is as long as your camera is (as you specified in the problem) at a fixed 45 degree angle. You could spin it in circles maintaining that 45 degree angle and it doesn't seem like the answer you're looking for would change?

So, forget about all 3d poo poo for now. Simplify it down to a 2d scenario, work out exactly what you want there, and then generalize it back up to the 3d world (which should be pretty straightforward).

I still have no idea what you're actually trying to accomplish, so perhaps try drawing a 2d diagram of your situation and what you actually want to achieve?

# ? Feb 8, 2020 06:29

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I mean sure here's a picture.

# ? Feb 8, 2020 06:53

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I got this solution to work, inspired by TooMuchAbstraction:

code:

func _input(event: InputEvent):
    ray.global_transform.origin = project_ray_origin(event.position)
    var offset_y: float = global_transform.origin.y - ray.global_transform.origin.y
    ray.transform.origin.z -= (transform.origin.y - LAYER_HEIGHT - offset_y) * sqrt(2)

The only problem is I don't really understand it, I'd love to just set the transform once. Value I get back from `project_ray_origin` is a global position, representing a spot on the front of the camera's viewport. So I put the global origin there, so that I can move the origin out. I can work with this so that I at least move on maybe this just isn't a good week for me and maths.

# ? Feb 8, 2020 08:12

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 14:34

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

It seems like you should be able to do what you want.

- You know the height of the camera above the Y-plane.
- You know the angle of the camera (45 degrees)
- Hence, you know how far away your blue square is from the camera (it's the height above the x plane / cos(45))
- Hence, in the camera space, your ray starts at [0, 0, (camera.y - yplane.y) / cos(45) ]

Jabor fucked around with this message at 11:13 on Feb 8, 2020

# ? Feb 8, 2020 11:10

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›623 »