Mew added the prototype to the project. now there are sounds maded when jumping, but now I need to design the movement component better so I can know when moving (on what is assume ground) without having that logic in the character. Also I need a more reliable way of knowing the ground.
I may make a sound object that handles creating, playing, and cleaning up. I may have the audio manager keep track of them, but will keep the node manager part for cases where I may want to have then globally reused. Meow I think too much.
*rolls around with you*
I am not sure where I could learn to make sounds. maybe MIDI may have some stuff I could simulate with the nodes. I also could look for libaries, though I am a bit picky. Meow I do need to figure out what to do today as long as life do not distract me much.8
to play, then I probably could design it to do more. So far there two way to play a sound. config it and run it or make sound every (fixed) update as needed. Also I am not sure how many sound contexts are safe to have, but I assume it easier to manage with one since too many at a time create errors.
Meow the other day I couldn't focus a ended up making a simple audio manager for making and modifying sounds. I ended up stripping it of the play tune and instead it now manages the ref of reusable nodes and a default audio context. I have no experience with sounds, but when I figure out some stuff
Well the system is set up the handles 13 or so additional cell types which could be mesh sets that are design to connect properly, I just am not sure when I will try to work on meshes since I kind of wanted to focus on an old style 3d maze.
things that a pain to fix without a dedicated game engine (active floor detection that is cheap) or require more resources to fix(modual rooms seams being too sharp. would need to use a tiled approach which mean ~16 materials or hacking the shaders to do it with some kind of global matrix).
generate the map, and then the rest of the stuff. Currently I can't await on things and been using signals and events to maintain call order which does not play well with loading many textures one by one (I could bulk it, but I will try that when I do the cleanup).
Also I keep running into little
Meow I am getting to the point where I need to clean it up and redesign the start logic so that all texture are loaded before the game starts. Mostly by not starting the game in any contractors. Create the game object and then call start to begin all the logic needed to load necessary resources,
generated if their a blocking cell in that direction, is at a world border, or the flag is set and the mesh info would decide what material the floor and ceil uses or the default if unset. I was think of compressing more data, but I think keeping it simple be better meow.
have a three mazes stack upon each other may be more interesting. This is for the static mesh though. Could also reserve id for dynamic mesh from a json or some other file. Also the fix color value of 255 for full block is only because it be easier to read. Floors and ceils would only be
Meow maybe I keep the maze image data simple. 2 flags (floor or ceil override), 0 as empty and 255 as a full block. All other values would be the mesh used plus extra for direction or variant. Each level would use a text/json file to override default slots. Also each channel would be height since
I do need to name function for setting up the physics and maybe edge cases such as if the world changes. Well at least I can slide into corners and well do not have to micromanage to physics meow. Some of the old could probably be used with pathfinding though. Meow not looking forward to that.
route all of the children add/remove child event to the game connect and disconnect functions. This will add objects with the physics_update and update function to a list to be call during the loop. I did not want to surround them in a event/signal since I did not want to mess with cleanup.
Meow well added Cannon-es and now slowly working on cleaning up the structure. I made a base Game class for maze game and I probably should do the same with the level and move all the maze gen stuff back to maze.js as maze_level.
I am abusing the child add/remove and remove events in three.js to
somewhat blind. Really it more of trying to add stuff to the clean up that may get leaked, else I should not worry about it. Meow why would anyone refresh a page a few thousand times anyways *rolls around*.
I do like working with js if I am able to declare classes and have control of most of the flow. I ended up working on more cleanup logic while moving things to the resource manager. It may be a bit before I can crack down on memory leaks between sessions since it resets my log so I have to do it
Then again I do not know if js have anything like that built in, but if so I feel it may be a pain to get working with three.js. Three.js could have one, but I kind of worry I would not like it if it did. I am odd and like making my own things meow.
have it manage some of the lifetime of the resource and text/json loading into class base objects or something. It is the first real singleton like object of this project (maze game just a global that need to be init when ready. Resource Manager will create a instance of itself when loaded)
Meow I am working on a Resource Manager for the project to strip level of all the nonsense code and allow preloading resources that are not ready on demand. Mostly it is for Three.js types that are not gb collected, but also allow a share space for accessing loaded or set up resource. May even
I will add it to the build maze logic. I do wonder if I should add colors for floors and ceil. I still not sure how I want to handle image data. Could make them flags. Ids, or both. Think it up to 24 flags or over 765 ids.
System or figure out how to extends Three.js more advance material. This lead to the uv of the border cubes being stretched (or super bright with shaders), so I made it an array of planes to merge into one geo. I did not do the floor or ceil since I did not apply the texture to them, but probably
I was lazy and got distracted with other things like restructuring to reduce memory usage by 80% (I was declaring too many vectors on update). I did added a silly menu to adjust far and near plane as well as fov. Then I added a texture, try to get shaders working, learn I have to built my own light
a 0 or 1 case and more backtracking the x or y base on character radius if there a wall blocking it. (The issue is making sure the edge is flush and the previous logic prevent the clipping). Meow now I hate I have a solution so I may end up using that.
move is colliders are already colliding, then project the move from the edge of the collider. This part is a bit odd if sliding since it is the player collider sliding so the final origins is the wall normal times player radius for each wall base on the axis block strength. With a grid, this is
of the return end point. I did assume I should also check the space between incase clipping, but I was too tired to think of how without rethinking the collision detection in and out. Probably should pass a collider, direction, and magnitude instead of from and to points. Then I could cancel the
clipping (which means walking pass the collider). The player still is a point collider so that may be the issue. Not sure why I having trouble adding space. I assume offsetting it base on the move direction and use that offset+location for the collision start would work as long as I subtract the
Also I might just leave the physic system as is since enemies or objects do not need to be slide against and most probably can be walk through. Really it is the slide logic that I am struggling with. either second collider block the slide or the slide is too flush with the first collider and lead to
if mixed with the current system and then additional passes for dynamic colliders which may be manage by a physic system or not. Meow this project is odd but interesting. I just am not a fan converting all this math and testing it when there is likely many systems that faster with it.
