Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411712 Posts in 69402 Topics- by 58456 Members - Latest Member: FezzikTheGiant

May 21, 2024, 02:27:34 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsSpriteHunter (WebGL Multiplayer Exploration/Collection game)
Pages: [1]
Print
Author Topic: SpriteHunter (WebGL Multiplayer Exploration/Collection game)  (Read 427 times)
Inky Cricket
Level 0
*


View Profile
« on: September 14, 2016, 08:27:15 PM »

SpriteHunter Dev Log
The current version of the game can be tried at spritehunter.com

SpriteHunter is a game where you will be a sprite that is searching for and hunting wild sprites, skins so you can look like a boulder or an icicle or other stuff, and colors to change your looks. Sprites will be floating balls of whatever it may be; ice, fire, geometric shapes...anything goes basically.

In my current plans, there will be a collection book, similar in style to a coin collection folder and how they have empty slots for the coins. The only objective is to find them all. The collection book's slots will be separated by region. You will be able to equip the ones you catch and have mini versions of them floating around you to basically be used as guns to hunt more.

If I get far enough, there will be other things like a day/night and a weather cycle so I can add stuff like a sprite that appears near flowers that bloom during the night, or a lightning one that appears near an obelisk during a thunder storm. The empty spot in the collection book will have a background that is dark, or stormy, so in that case so you won't be completely clueless about when it appears.
« Last Edit: September 17, 2016, 06:00:07 PM by Inky Cricket » Logged
Inky Cricket
Level 0
*


View Profile
« Reply #1 on: September 17, 2016, 06:27:32 PM »

My progress from version 0.1 to 0.7 from before I posted this devlog:


0.1: Here I was mostly getting everything working and learning to use three.js and cannon.js.

Some issues I encountered here: The raycast was giving results in the order the bodies were added to the physics world. The camera could go against the wall and see through the floor below because the wall was added first. Had to add a thing to make it show closest instead. The second issue was the order of the camera's rotation. The typical x, then y, then z caused the camera to tilt at an odd angle if you tried to look around. Had to make y, the left and right angle, get applied first, then x for looking up and down was applied next. camera.rotation.order = "YXZ"

Instead of trying to wrestle with the physics engine to get good platformer movement, I decided that the player would float since they were sprites and would visually float anyway. Saved a ton of time. I remember the last time I wrestled with a physics engine for platformer movement, I think it was in unity. Didn't work well at all, so I was relived to have this little workaround accidentally allowed by the player being a floating thing.

The player raycasts down, and based on distance, he accelerates up or down. Can't jump if the raycast doesn't hit anything. The player falls if the raycast hits something too far down or it doesn't hit anything.



0.2:
Multiplayer added. You can only see the other player if you are close enough. The server has a big 2d array for the spacial partitioning. The floor was expanded so I could travel around and test whether or not I could see the other me I had open in another tab.



0.3:
I added the level editor, or at least the ability to add, remove, and save props. The only prop in game was the blue box. In the level editor, I did a raycast in the physics world when I clicked and if it hit something, it creates a prop there. If it hits nothing, it creates the prop a certain distance from the camera.

Had a really strange issue. If I clicked while moving up or down, it would sometimes add the prop farther up or down that it needed. I think it had something to do with the unproject function and the camera movement. I don't remember how I solved it or why it happened, just that it had to do with the camera movement.

Had some issues because I wanted the cursor to be locked while I held down the right mouse button and released when I released it, just like the unity editor or how lots of mmos do their camera movement. Firefox didn't like it and threw the ugly dialog thing saying I'm going to cursor lock each time I right clicked, so I had to click again in order to lock which defeated the whole point of right clicking to rotate. Recently I tried it and firefox worked after the first dialog, so either I was delusional, or firefox fixed this error recently. Too late firefox, chrome is my main browser now.

Put up a message in the level editor saying that the level editor works.  Smiley


0.4:
Added a few minor things. That other red ball is a wild sprite. It just follows the player in a funny pattern and is disabled when it has no target(player) in sight and will re-enable when it sees one again. The client is just told it's another player, but that will change when I start adding wild sprites for real.

Oh, yes. A major thing. I ended up adding my own physics broadphase for the server for the wild sprites to be able to collide with things. I could use sweep and prune in cannonjs, but I wanted a grid broadphase. I think it might have been the heightmaps or something, but cannonjs's grid broadphase didn't work for certain shapes that I needed, so I made my own. Basically, the wild sprite keeps track of what physicsbodies there are in the current square in the grid, accounting for the sprite's width of course so it could be in 4 squares at once if it was at a corner.

The green stuff is the physics bodies. It's a thing cannonjs has so I can see what the physics engine has vs what the display has.


0.5:
Added a heightmap that blends between 4 textures based on the red, green, blue, and alpha of the splat map (just an image).

Took pictures of a driveway and a sidewalk for two of the textures. The pebbles and the grey rocky texture. The other two textures are just placeholders slapped together with the noise filter, a color, and funny effects applied. After cropping some of it, I had it moved by 50% and had the image wrap the screen so all the edges of the image would be in a big + shape in the center of the screen and it would be easy to fix up the seams. Had to do some trick in gimp to equalize/homogenize the image because it was bright on one end and dark on the other. Pictures were taken with an ipad by an amateur(me), so this extra work was needed. After that, I used the clone stamp all over until it became almost impossible to see the seams. Lots of copied rocks, but even I have a hard time trying to spot a pair, so it worked out.



0.6:
Added in chunk loading and unloading. The farther away a chunk it, the lower quality it's heightmap will become. It creates the default chunk if the server returns a 404.

Because less vertices on a lower quality heightmap vs more on a high quality one means that it will not match, there will be holes in the floor between different quality heightmaps. Instead of adding that complicated stuff to make it match, I just added a "skirt" to the heightmap that extends down and has the uvs of the outside edge of the terrain. All the heightmaps have a height of 5 on the outside edge, so lower quality ones match perfectly at the moment, but I can mess with the uvs and clean it up a bit if the smudge does become unsightly after I add in proper heightmap editing in the editor.


0.7:
Around here I added some new props in and had them share a material and texture so they won't all create their own.


Here, I added geometry loading and sharing.

The chunk also combines the meshes of all the props that are in it into one big mesh. Because it has a lag spike when it does that, I made it only merge one mesh per physics update and only when it's done merging them all will it add the completed mesh to the scene. This will cause a delay before you see everything, but it's better than a lag spike each time you enter a new chunk. New chunks will still be far in the distance by the time they finish.

I tried some sort of threejs material that let me merge all the meshes into one mesh without messing up the materials so I could combine props of different materials all into one mesh, but the performance was worse than having each prop have their own mesh. So I had the chunk create one combined mesh for each material that a prop has in that chunk. Made it a lot more complicated, but it works.




Another picture of 0.7
The props aren't rotated randomly anymore so it doesn't look as good, but it's an improvement because it's now getting the rotation info from the saved chunk. The editor just adds it in with 0 rotation, and considering heightmap editing and splatmap editing is next on my to-do list, I'll probably add in a prop rotation option while I'm at it, and also a toggle for random rotations to make it simpler to plop a bunch of props everywhere.

--------------------------------

I moved the above to this post to make proper room on the first post for displaying current versions later on in the devlog.

I added a LoD system for the props too instead of only the heightmap. They just switch between the rock and some other model right now, but now I can specify a lower quality version of a mesh for lower levels of detail.

After that, I had to fix some stuff in the editor because in the editor I want to be able to add and remove props at will, but the mesh merging I added recently prevented that. After fiddling around to make an exception for how the editor worked, all is back to normal now.



Heightmap editing in the editor now works. I still need to make it affect more than just the one spot under the cursor and also affect neighboring chunks when on an edge or corner because the edges overlap.
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic