frame

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

A sort of 3D test

edited April 25 in Play My Game
Not exactly a game, but here is something like a 3D proof of concept I worked on yesterday and finished up today. It works most of the time and I already figured out better ways to redo everything, and things to add like strafing, but I figure it is still worth posting.

Explanation
Blocks are always facing the player, their angle determines whether they are within the player's field of view, if they are beyond a 90 degree window based on the player's viewpoint they don't get rendered. angles determine the blocks X positioning, distance between the block and player determines their Y positioning. illusion of perspective (smaller objects farther away, bigger objects closer) is done through scaling down block spites using their Y position. depth is kind of achieved by modifying the alpha value the same way, farther/higher Y blocks have lower alpha values. from this window it's all rendered real-time, destroyed, re-rendered, and so on to keep everything updated.

It is messy spaghetti code, and stuff from the right-side of screen can bleed over onto the display, sometimes it doesn't work for certain walls, but it's good enough. Might be easier to understand using the minimap version below. "Wall" contains the logic necessary to render a sprite in the correct X/Y position on the left-side of screen. "Wall render" is the rendered sprite, contains the logic necessary for rescaling and modifying its own alpha value.


image
Rendered screen-only version: http://www.flowlab.io/game/play/880631


image
Rendered screen + "minimap" version: http://www.flowlab.io/game/play/882080


Just something extra I learned from this is that rendered screens could easily be used for multiplayer games to create splitscreens.
Tagged:

Comments

  • Alright, this is smart. Lags a bit and still have bugs but nice enough.
    Like the bug that if a wall is in the same line of another it will be never be at the same size.
    So mazes with this logic won't be possible yet.
    Or moving walls (enemies) would lag A LOT.

    I edited and tested a few other positions some of them worked others didn't. I can't test that much because it crashes a minutes after for me.

    But overall well done. This is such a nice begining and nice math

    And "could easily be used for multiplayer games to create splitscreens."
    Yes it could be ONLY IF the game were just walls
  • edited April 25
    Yeah it was a quick mash-up of the first solutions I could think of for every problem I came across, but completing it let me figure out better ways to do things next time. I think strafing can be implemented to make it more first-person, it just needs the the walls/objects to reference the player's rotation, this would also reduce the logic to maybe 20% of what it's currently at, would be more intuitive and less things would be running compared to the four redundant blocks of logic I'm using for the viewing angles. The player's field of view can be widened easily as well to give a better spatial sense.



    I edited and tested a few other positions some of them worked others didn't. I can't test that much because it crashes a minutes after for me.
    It was hell trying to figure out the angles for rendering, every attempt to run would make it crash or freeze and progress would be reverted...



    And "could easily be used for multiplayer games to create splitscreens."
    Yes it could be ONLY IF the game were just walls
    I have some ideas how to make it work better in a more game-like environment with trees and enemies, and also a way to only render when player's/enemies' position/rotation changes. A distant background loop can be added referencing player rotation showing for example mountains if viewing north, the sun in certain positions, and so on as well to help it feel more 3D.

    If there was a way to tranfser data between the walls to its respective rendered wall there wouldn't be a need for the spawn/destroy loop that rendering method utilizes, the cause of lag. I can't think of any method yet.
  • Oh, for split screen multiplayer, it would work the same. Both players can share the mini map, if they raycast each other, they spawn on the 3D map, if one shoots an enemy, it dies on the mini map and that kills the enemy on the 3D map on both screens.

    I haven't tested it yet, but I had this idea last year. If the wires are spaghetti, I won't be able to help you fix anything. All my games now use labeled behaviors, clean wires, and behavior bundle folders.
  • edited April 27
    This amuses me for how often it crashes. I wonder why.
  • edited April 27
    ^For now I think of it only as a necessary learning progress, I actually haven't touched it or looked at the original since posting. I'm redoing it with better ideas I have, like double the field of view and also without the limited 90-degree player rotation.

    For determining whether something is within a 180 degree field of view and should be rendered, it's simple enough subtracting (for left side) and adding 90 (for right side) degrees to the player's rotation and checking if the object's rotation falls within that range. I'm just having trouble when that range spans 0/360, because degrees of rotation are determined modulus 360 after normalizing it to positive values only, for example 350 is only 20 away from 10 in modulus 360, but with basic arithmetic (pretty much the only math I know) there's a 340 difference. I'm sure this problem affects the original one I posted as well, since walls sometimes didn't render at all.

    I think I almost have it figured out though, once that is solved the rest should be easy. I want to eventually clean this new version up so it's customizable and easy to change, like so you can change the horizon level, field of view, screen size, how far you can see, that sort of stuff. It should work well enough so you can drop the logic into any object and it will get rendered fine, maybe as easy as just placing a bundle in it.
  • edited April 28
    I was thinking something along the lines of, what if @grazer gave raycast the ability to rotate with the player? This would also help out a lot in RPG games, or any games really, because then whatever direction the character is pointed at, raycast follows within its range of visibility.

    If he did that, you could just have the character rotate and strafe.
  • edited April 28
    I was thinking something along the lines of, what if @grazer gave raycast the ability to rotate with the player?
    Does inputting the player's degree of rotation into the raycast not do this?

    Raycast being able to penetrate or ignore nontarget objects would be helpful as well, when i first used raycast for a few days I assumed this was the normal behavior and it caused so much confusion when it was being blocked by other things. The way it works does make sense I mean, I'm not even sure why I thought otherwise
  • That's exactly what I said to grazer. I don't understand why it can't have an option to see through objects. I don't really understand fully how raycast works, because I haven't had a lot of time to test it, but if you can already adjust the angle based on player rotation, you should use that.
  • edited April 28
    Test
    image

    For a new version I started, kind of got it semi-working, but because I'm not smart enough the logic is probably 40x bigger than it needs to be, it's an absolute mess, not even gonna share it yet. I wonder if it could run better if the code was done better, but I'm starting to think the rendering method is the problem. You can't be spawning and destroying so much stuff every frame. I tested out a moving object (the npc guy running back and forth) and it worked alright. The problem is there's no render order though so everything is kind of displayed over everything else without any reason, I was playing with the idea of limiting min/max size to 10 different sizes for each rendered object, and making them their own objects with layers like 1-10 to fix this but It's hard to even test without crashing lol and so the resizing is the only thing limited

    It also has a problem where entirely new objects are being created by the game and dumped in the object library after letting it run for a while. They have the same names and a solid red texture, pretty weird

    I will try making it better or limiting rendering only for when stuff changes on the screen, maybe that will help

    Kind of cool seeing from first person
  • Looks interesting to me, and much better. Here's an idea. Maybe @grazer can make a behavior block that changes the order layer with a number input. This would be useful not only for you, but for anyone that wants to be able to walk across an RPG bridge, then go under it, or go in a door, and have it close behind you, or walk in front of a tree, then walk behind the tree. For you, the closeness to the player sets the layer order number, and you could have it go to 20 layers or more so there's no flicker.

    Not sure what causes your lag, but your test looks promising.
  • This is really cool to see, @Wizardry

    Adding and removing objects can be relatively expensive, but I still wouldn't expect to be super laggy with so few objects on screen. If you haven't already, make sure that your objects have no physics (not movable or collidable) and that may make it run more smoothly.
  • Imagine if you made all of the objects somewhat transparent, you’d not have to worry about layering... but now I want to make an SB3 mode out of this...
Sign In or Register to comment.

flowlab.io

| make games in your browser
@ 2017 Flowlab.io, All rights reserved.

Contact us

Get In Touch