Complex
A soon-to-be 3D multiplayer game, written in Processing
Development
- Framework for 3D environment creation: NxNxN (where N=5, for now) complex of cubicles, each with 6 faces, each with randomly generated features, each with individual component blocks
- Function to remove/modify extraneous (overlapping) blocks
- Moving 1st person camera
- Use Robot class to set mouse position to (0,0), mimicking how most 1st person games have the player look around
- Move 3D camera.target.location according to the horizontal and vertical angles modified by mouse movement
- Have ability to change camera orientation in all 6 cardinal directions
- Edit mouse movement » player viewing function to change for each orientation
- Changing time for camera orientation (so it's less confusing than simply setting the new orientation immediately)
- Collision detection: block w/ camera
- Gravity
- Jumping
- ¿Color blocks according to their appropriate cubicles to lessen disorientation a bit?
- Fix jumping
- Only display rooms within range N
- ¿Compass that shows where "North" (positive direction along z-axis) is?
- Server: environment
- Server: communication
- Server: players
- Server: enemies
- Server: projectiles
- Client: read in environment
- Client: store environment
- Client: update environment when far enough from last update point (add this if I ever want to make the complex larger)
- Client: read in other players
- Client: send self data (location, name, color)
- Client: read in enemies
- Server: create AI for enemies, so they move around obstacles
- Client: Sound effects... : I tested playing sound and panning the playback
- Client: aiming and shooting
- Test single client environment transfer
- Debug single client environment transfer
- Client: request environment
- Incorporate color in environment transfer
- Update environment server to take requests from multiple sources
- Update central server to perform consolidation (put multiple broadcasts of the same heading type)
- Store other players as Player objects (subclass of Block with names and lamps)
- Server: players: add new clients
- Server: players: replace client data
- Server: players: send client data
- Server: players: add clients file
- Server: players: update clients file
- Client: add score
- Client: add other players list
- Client: display other players
- Client: collide w/ other players
- Remove color from environment transfer (sending color made loading the environment WAY too slow)
- Test pretending there are other players (quit and restart to see my previous self)
- Test with multiple clients at once
- Client: stop sending color once the player server once player server has mine recorded
- Client: smooth other players' movement through 2-point interpolation (glide to next point)
- Client: store previous and future locations for players
- Client: update previous and future other player locations
- Fix environment transfer to send packets of ~200 to each request
- Client: change mouse controls to record mouse movement?
- Client: assign random colors to other players (don't send colors over internet)
- Test running multiple redundant player servers to prevent data loss? Potential problem: one server might send other player updates to a client that are outdated. Solution: have all programs run on a standardized time, and only accept updates with a time-stamp from the future.
- Client: predict fall for players if in the air?
- Server: have the environment server keep a list of requested blockNumbers. Then send packets for each one at a time.
- Client: if end header is not visible, read everything to the end of the data string
- Debug blockNumber list and reading broken messages
- Client: other players' movement is better (smoother), but still jumps. Solution: ??... for now, just examine the program to find the problem.
- Introduce standardized time.
- Server: Put time stamps on sent player data
- Client: Only read in other player data if time-stamp > that player's last time-stamp
- Test other players' updates w/ and w/o time-stamp condition above RESULT: doesn't make a very notable difference, especially with only 2 players at a time...
- Server: have projectile server load in a saved environment and check projectile-block collisions
- Client: introduce protocols for projectile requests, deletions, and updates
- Server: sends out deleted projectiles as well as current ones
- Client: incorporate multiple key-presses at once. Solution: have a boolean array of important keys, and update based both upon keyPressed() and keyReleased()
- Server: have player server read corrupted incoming messages
- Server: have projectile server read corrupted incoming messages
- Client: display projectiles
- Client: detect collision with projectiles and request their deletions
- Client: display collided projectiles
- Client: try playing sounds for collided projectiles w/ location suggested by amplitude and Left-Right panoramic effect
- Fix conversion from long to string (get rid of scientific notation). Solution: place each value at positions n, convert round((time % (10^n)) / (10^(n-1))) to characters, and concatenate them into a string
- Server: projectile server moves projectiles, then checks for block collisions, then sends their new locations
- Server: use above change to make projectiles move much faster
- Client: only keep track of initial location and latest location of each projectile, tracking their paths of movement. Draw these paths of movement as fading streaks
- ¿Client: add projectile flying sound in addition to impact sound?
- Client: collision animation for projectiles