benevolent-games / benevolent.games Goto Github PK

this will eliminate caching problems when we make new deployments 👍

• fullscreen on ios literally not supported on ios
• thumbsticks touchmove on ios
• thumbsticks occasionally get stuck on android
• thumbsticks are vertically stretched on android, they shouldn't be stretchy
• ios crashes in high quality mode

the ci routine is gobbling up our bandwidth quota, because it downloads all the assets for every push on master

• let's figure out how to skip lfs objects in the master build
• reduce master build to only compile typescript

we've accomplished netcode 0, and achieved webrtc connectivity and data transfer in sparrow-rtc testing.

we've accomplished netcode 1, and integrated user accounts, guest users, invite links, and a scoreboard that shows connected users and their pings.

these accomplishments have set the stage for the big kahuna: actual multiplayer gameplay

• this first prototype, it will be crude, it will be basic
• we might not even have the robot character ready in time, all with its animations and gorgeous blinking eyes
• but the goal, is that we will be able to walk around. and see each other. and push that damn cube around!

we need a sophisticated system for coordinating the layering of character animations

babylonjs doesn't come with support for this out of the box: https://forum.babylonjs.com/t/how-can-we-mix-character-animations-and-control-precedence/27831

hopefully we can create a system for organizing animations into overlaying blending layers

• new desert landscape
• drilling and mining facility built into the central desert butte
• deep bore-hole, which players must be careful not to fall into!
• underground mining-cart tracks, which players must be careful not to get hit by a fast-moving cart!

okay, even though i said i'd work on #40 to clean up the code before adding any new features... we've been having a lot of fun eating pizza and adding features, and here's my wishlist to accomplish before proceeding with boring refactoring:

• improve the robot animations waiting for response on babylon forums
• interpolative smoothing for networked movements
• in-head first-person view
• player colors
• wave mechanic blocked by animation issues
• jumping next time 🤷
• human mesh swap button
• respawn button, to alleviate sticky situations next time 🤷

let's organize the assets directory with better names

• start with the .blend file in this .zip concrete_barriers.zip
• art must fit within the confines of the base meshes provided in the .blend
• each collection should contain 1 high poly mesh that was used for baking, and 3 lods, all lods will share the same static from lod1.
  • top quality (this is the source material that is not exported into the game)
  • high quality (this is lod0, it will be used for the high quality mode and be seen close up. ex. name: modelname.lod0)
  • low quality (this is lod1, this is for low quality setting, it will also be used as the static mesh. ex. name: modelname.lod1)
  • bottom quality (this is lod 2, it should be the lowest quality and only be seen at far distances. ex. name: modelname.lod2)
• only 1 full set of pbr textures used across all concrete assets assets at 2k resolution
• finished work should be in a .blend format

we need to build a good virtual thumbstick for mobile users.

thumbstick

• we want to build a modern replacement for nipplejs https://yoannmoi.net/nipplejs/
• we want to place the thumbstick in the lower-left corner, and use it as player movement input (in addition to wasd)
• we want the thumbstick to work based on touch events on mobile, but it should also be usable by desktop users via clicking and dragging
• we need an in-game interface for toggling the mobile controls (turning the thumbstick on or off)

thumblook

• instead of having a right thumbstick, we want the user to touch-and-drag anywhere on the right side of the screen to initiate "looking", where they press and drag around to control their aim direction
• similarly, we want desktop users to emulate this action with their mouse by clicking and dragging when the mobile controls are on

user experience

• the user needs some in-game interface for toggling the mobile controls
• when the mobile controls are activated, the pointer lock system should deactivate

• make a gist tutorial about how to make good seo
• robots.txt and sitemap and whatever
• microdata for nice embeds with discord and messenger links

• stop unnecessarily rebuilding the bundle in the dev watch routine (since we are using es-module-shims)
• let's do some renaming
  • maybe rename main.ts to humanoid.ts
  • extract website homepage script to website.ts
• rethink s/demo
• reorganize s/thumbtastic/ (into a toolbox?) and upgrade xiome and fix thumbtastic.ts <any>
• add .github/CODEOWNERS to require me to approve any changes to deployments

the three new buttons near the right thumbstick, don't work in a multi-touch context.

that is, they don't work when you're already touching the left thumbstick to walk around.

we need to rework the mobile buttons so they work, even when you're also touching another part of the screen.

• start with the .blend file in this .zip hesco_barriers.zip
• art must fit within the confines of the base meshes provided in the .blend
• each collection should contain 1 high poly mesh that was used for baking, and 3 lods, all lods will share the same static from lod1.
  • top quality (this is the source material that is not exported into the game)
  • high quality (this is lod0, it will be used for the high quality mode and be seen close up. ex. name: modelname.lod0)
  • low quality (this is lod1, this is for low quality setting, it will also be used as the static mesh. ex. name: modelname.lod1)
  • bottom quality (this is lod 2, it should be the lowest quality and only be seen at far distances. ex. name: modelname.lod2)
• only 1 full set of pbr textures used across all hesco assets at 2k resolution
• finished work should be in a .blend format

• organized into assets/
• separate glbs for low/high quality
• source textures are in assets, and we have automated build for compressing low/high quality versions
• low and high quality stuff is tested and works, ready to integrate with #4

• the artwork
• the code

• website interface for launching the game in high or low quality
• in-game interface for switching quality
• load different glb assets based on which quality was selected

• start with the .blend file in this .zip sandbags.zip
• art must fit within the confines of the base meshes provided in the .blend
• each collection should contain 1 high poly mesh that was used for baking, and 3 lods, all lods will share the same static from lod1.
  • top quality (this is the source material that is not exported into the game)
  • high quality (this is lod0, it will be used for the high quality mode and be seen close up. ex. name: modelname.lod0)
  • low quality (this is lod1, this is for low quality setting, it will also be used as the static mesh. ex. name: modelname.lod1)
  • bottom quality (this is lod 2, it should be the lowest quality and only be seen at far distances. ex. name: modelname.lod2)
• only 1 full set of pbr textures used across all sandbag assets at 2k resolution
• finished work should be in a .blend format

right now, the player can sort of move around with WASD — but it's really awful.

work will be done in player.ts

the code is very rough, and bad. our objective is to quickly write up a working prototype, and then refactor the code and make it beatiful after we have found a working implementation.

• ✔️ the current player mouselook algorithm is working well
  • however, you may notice a bug, in windows+chrome, where the player look will suddenly snap to a new location
  • this is a known chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=1031906
    not sure if there's anything we can do about this except to wait for chromium fixes it, unless we want to fix it ourselves.
    we'll wait for the time being.
  • we believe this bug does not manifest in firefox, which may make it our primary browser until a chrome fix lands
• ❌ the current player movement algorithm is horrible
  • the work of this ticket is to redo the player movement
  • currently, we apply force on the player capsule based on WASD presses, applying more force when shift key is pressed
  • one major problem, is that we have a high amount of friction between the player and the terrain
    • we need the friction, so when the player is standing on a slope, they don't slide down
    • but to defeat the friction, we have to apply an insane amount of force
    • this also makes it nigh impossible to traverse uphill, we cannot overcome the friction
  • the next problem, is that there's no top-speed, and so once the player gets moving, they proceed to move at rocket-like speeds
  • and the final problem, is that the player has a habit of falling through the terrain, into the eternal underworld
    • this may simply be because of the extreme forces at play
    • this might also be a matter of the physics engine being poorly configured, perhaps with too low a tickrate or something like that

and so, the criteria for making the player movement good includes

• player should have friction against the ground, so they don't slide around
• player should be able to walk around and use shift to run faster
• player shouldn't fall through the terrain
• player should accelerate up to a configurable top speed, so they don't rocket around
• bonus: we'd really like the physical simulation of the player capsule to remain intact, that is, they can push boxes around properly, and more importantly, physics objects should be able to push the player around

this work doesn't need to be perfect, we just need significantly better player movement than we currently have.

some people (lonnie) don't have a working F11 button.

so let's make a little button for toggling fullscreen.

using our new sparrow-rtc tech https://github.com/chase-moskal/sparrow-rtc

• game should default to hosting a multiplayer session
• in-game interface should allow the host to copy a link to their clipboard, so they can invite other players to their game
• in the developer console, we should see heartbeat activity to prove they are connected (no actual gameplay yet)
• let's have the server record ping times for each client, so players can see who's connected and their current ping
• let's launch a server so we can test this in the wild, and see real world-wide-web connections at play and find nat issues

now that #3 is done, the next step is to integrate multiplayer connectivity into humanoid.

this will not yet include any actual gameplay, this is the precursor for that.

1. connectivity
   users can connect to each other's sessions, and see debug info about the game session
2. accounts
   integrate xiome logins for users to login to their account.
3. scoreboard
   the scoreboard displays connected users, their nicknames, their user ids, and their pings.
   users who are not logged in should be given a random guest name.

with #39 we've done the spike of the ol' spike and stabilize routine.

now it's time to refactor all this new netcode before it continues to spawl from something merely chaotic into something completely unbearable.

this needs to be done before we continue to add new features to the multiplayer, which will lead to netcode 4.

it will be so much fun to be able to drive the dune buggy around!

• use ammojs vehicle physics to make the dunebuggy drivable
• should have some squishy suspension
• we think it would be ideal if the controls were just like vehicles in Halo
• we'd really like players to be able to jump in and out of the vehicle by pressing the F key

💰 bitcoin bounty 100k satoshis
💸 bounty halves every 10 days after 2022-02-03

we'd like for developers to be able to develop benevolent games in unity.

• we want to pursue a unified api for benevolent games, that can control either babylon or unity
• the goal of this ticket, is to export a unity game, and to control the unity engine via typescript
• we want the unity build to be as optimized and small as possible, ideally, around 5 or 10 megabytes

shadows are currently wonky and appearing in weird places.

• currently, gamers using a keyboard are able to jump with the spacebar, and change perspective mode with the p key.
• mobile users do not have a keyboard, and so we need to add buttons near the right thumbstick for them to use.

• J should be the jump button
• P should be the perspective-swap button
• M should be a third button, for swapping character mesh

understanding the relevant code

thumbsticks

these new mobile buttons will be similar to the thumbsticks, so we need to understand how the thumbsticks work, because the integration of the mobile buttons will follow a similar pattern

• thumbstick lit component is defined here in thumb-stick.ts
• the markup that places the thumbsticks onto the game page is located here in humanoid.html.ts
• the css that styles the mobile control area and the thumbsticks is located here in _game.scss
• thumbsticks are queried and passed into gameSetup here in humanoid.ts
• thumbsticks are passed along until they are given to player.ts

so, perhaps, one good way to implement the mobile controls, is to create the concept of a mobileControls object, which would contain both the thumbsticks and also the new jump, perspective, and mesh buttons

• then instead of passing thumbsticks along through gameSetup and into player, we should pass the whole new mobileControls object along the same path

triggering actions, like jump, perspective, and mesh swap in player.ts

• networked actions must be actuated by calling sendMemo, which instructs the host to take the appropriate action
• to trigger a jump (networked), we send a jump memo, similar to what is seen here in player.ts
• to trigger a character mesh swap (networked), we call sendMemo as seen here in player.ts

for any action that is NOT networked (only happens on the local client's screen), we do NOT need to send a memo, and can just change the 3d world as needed directly

• perspective swap is NOT networked, and so instead of sending a memo, we simply call toggleThirdPerson() as seen here in player.ts

we just need to adjust the environment spawn script, to apply static physics onto the static collision meshes

animations

• idle
• lookupdown
• walk
• strafeleft
• straferight
• crouch
• jump
• wave

• stop using ?pretty url parsing to determine quality -- we don't want people's links to be contaminated with their quality settings
• add a simple loading indicator, so users don't worry the game is frozen and doing nothing

• now that our watch routine doesn't bundle, we should be able to feasibly start using babylon's es module distribution

the copy invite link button is broken on windows chrome, and probably other platforms.

we should fix this. it's probably a permissions api situation.

• cool looking dune buggy
• single wheel mesh ready for the programmer to delicately place into a suspension system
• test it by spawning it onto the map somewhere

• sweet looking robot
• rigged mesh is interchangeable with human forms
• keyframes for aiming all the way down, and all the way up
• animations for standing, walking, running
• [ ] animation for blinking eye display

we need a system for fundraising by community donations

• members can become "benevolent donors" by signing up for a subscription starting at $5
• benevolent donors will be marked as such on their profile and on scoreboards
• benevolent donors will have access to premium cosmetics like skins

this work is being implemented in xiome in this ticket: chase-moskal/xiome#120

then the remaining work here will be to integrate it onto benevolent.games

the current player movement could use some improvement.

• the current movement is jumpy, when it hits uneven terrain
• acceleration and deceleration would be an improvement
• perhaps we could customize the "slope-climbing-ability" somehow
• current movement interferes with gravity, which shouldn't happen

💰 bitcoin bounty 100k satoshis
💸 bounty halves every 10 days after 2022-02-03

we need a button to show/hide the scoreboard.

maybe we can also make the scoreboard more compact.

we need a gun, ready for gameplay

• the gun itself
• hands, to hold the gun in first person
• animatons
  • idle
  • aim
  • shoot
  • reload
  • rack a round

algorithm for assigning indoor lights to indoor meshes