sharvil / dotproduct Goto Github PK

XHR supports sending/receiving binary data through xhr.responseType = 'arraybuffer'.

It's hard to distinguish between a player name and the message content because they're all the same font / size / color. Treat chat messages as an ordered sequence of structured data so we can color-code / highlight fields.

This is in regards to the messages printed and faded from center of screen.

Exit and enter messages are supposed to be blue.
Kill messages are green.
Kill messages involving you (being killed or killing someone) are yellow.

Repro steps:

• Place a prize immediately above a single tile
• Approach the tile from the right
• Make sure the center of the ship is slightly above the tile but still positioned such that it would collide with the tile
• Notice that the prize is collected and the ship transports to a location to the left of the tile instead of bouncing off it

A co-worker of mine from a different company thought it would be nice to have voice communication and/or video chatting (since "everyone has built-in webcams nowadays and so you can see who killed you). Submitting in this suggestion for him.

I have felt that the ship gibs that go flying everywhere when killed disappear too soon. So I have compared dotproduct to watching and timing gib lifespan in Continuum. For the sake of experimentation to see how it feels and looks, try increasing the lifetime of the ship gibs to 1500ms before they instantly disappear.

I couldn't build the application, for some reason.
Are there any instructions on how to run the project so we can open pull-requests?

Btw, I had the original SubSpace back in 1998, but I couldn't play online by the time because it's Brazil, you know, greedy taxy gov and technological advances don't mix.

I think the very first frame of the thrust animation graphic should be above the player ship. The first frame looks like a star.

A player today reports that it is very easy to notice that the 2nd layer of starfield is the same as the first.

I think we need to put a link somewhere on dotProduct webpage back to the Facebook Group and Google+ Circle, and possibly back to this Github as well.

Fatal error that seems to be coming from:
https://github.com/sharvil/dotproduct/blob/decouple-gfx/js/views/Game.js#L343

Browser: Chrome
OS: Mac OS X 10.8

Unable to fly / shoot / do anything -- however most of the objects in the screen are loaded.

At present, prizes persist until they're either collected or a new seed arrives from the server. Prizes should be more active and decay / regenerate even within a single seed sync interval.

Move at full speed in one direction. Then, immediately use reverse thrusters (down arrow key). It looks weird for the thrust to look like its propelling you forward instead of in reverse.

Should brainstorm for a creative alternative or tweak the physics/mechanics of thrust graphics when using reverse thrusters.

EDIT: In the original game, the thruster graphic simply just shoots in the inverse direction from the same spot it shoots out when using forward thrusters.

There are some weird behaviors with the chat input field.

1. Unsent message disappears when chat input field loses focus.
2. Unsent messages are kept but hidden when chat input field loses focus.
   (Could make this into a message draft feature?)
3. Cursor splits messages when chat input field loses focus.
4. Once the chat input field is unfocused with an unsent message, you can click on it to write
   messages, which will then be covered up when you press enter, but that persist independently
   of messages typed with enter, until you send the message.

To reproduce:

1. Type in "message1", but don't send it.
2. Unfocus chat input field, by clicking somewhere else either in or out of game. Then refocus chat
   input field by pressing enter when the game has focus.
3. Type in "message2", but don't send it.
4. Repeat step 2.
5. Press left arrow key once (at which point the cursor will be to the right of "message2"),
   and add the text "message3".
6. Repeat step 2.
7. Press left arrow key three times and type in "message4", to get "message2messagmessage4e3".
8. Repeat step 2.
9. At this point you will see "e3" to the right of the cursor. Type in "message5", to get "message5e3,
10. Repeat step 2.
11. Now use left arrow to go back to any of the hidden messages and put cursor in the middle of
    any of the messages.
12. Repeat step 2.
13. Use left and right arrow keys to see that the message was split where you left the cursor when
    the chat input field lost focus.
14. Repeat steps 11-13 as much as you like to keep splitting the hidden messages into smaller
    hidden messages.
15. Send your message with the cursor at any location, and you will send the concatenation of all
    your hidden messages.

The mouse trouble can be seen by unfocusing the chat input field with a message typed in, which leaves it clickable. If you type a message by clicking on the chat input field, that message will be covered up when you press enter.

Title says it all.

From yesterday's playtest, the idea of having control instructions printed on the webpage somewhere was made.

I am considering putting together an illustration (picture) showing the mapped keys and what they do on one image, so that way it would be user-friendly and intuitive (being in the form of a picture) and quick to understand. We could have some sort of mouse-over hover on something to get it to popup (and disappear upon moving the cursor off).

I noticed last night while testing under Mozilla Firefox that the technical information (latency, framerate, number of players, coordinates) is not being displayed under the canvas. It is entirely missing/hidden. Not a major issue though, and can be ignore.

I also remember that in one of our recent playtests one of the players reported that it was missing for them too.

The game does not appear to get past the loading banner. Not sure why. Only seems to affect Safari 6.0.2 on OS X Mountain Lion.

Chrome Packaged Apps might offer a way to use UDP sockets so we don't suffer from slow start and HOL blocking on TCP sockets.

As of Dec 28, 2012, packaged apps have terrible performance. dotproduct runs at about 15fps as a packaged app vs. 60fps in Chrome proper. Revisit this in 6 months or so.

It feels like a fast-1500ms.

Try 2500ms (probably too much but...)

Title says it all.

The settings are set to afterburnerAcceleration = 0.02 and afterburnerMaxSpeed = 2 * speed.

They should be at 1:1 scale, but they aren't (they are smaller than original dimensions).

Some players from yesterday's playtests wished the canvas was centered on screen as they were having discomfort or trouble getting it positioned properly on their screen.

You might consider using absolute centering. There are many resources on this:

• http://lysergicstudio.com/absolute-centering-a-div-with-css/
• http://perishablepress.com/absolute-horizontal-and-vertical-centering-via-css/
• http://www.zachgraeve.com/2006/10/01/center-abosulte-position-div/
• http://www.mezzoblue.com/tests/centered-css/

Adding planets / nebulae will give the background more character than the current parallaxed starfield.

Could the upgrades we've picked up be shown as a list or something in the top right corner? Or a level number by 2 icons representing gun power and bomb power.

The current asset is too large for the Weasel's ship radius in Trench Wars. Either grab the latest from TW or manually shrink it down to fit.

When the LoginResponse packet is sent back to the client, it is processed by by the LoginView which processes the packet as follows:

switch(packet[0]) {
    case 0: {
      alert('Login failure: ' + packet[1]);
      break;
    }
    case 1: {
      var resources = packet[1];
      var settings = packet[2];
      var mapData = packet[3];

      this.successCb_(resources, settings, mapData);
      break;
    }
    case 2: {
      this.formNode_.style.display = '';
      this.nameNode_.value = '';
      this.nameNode_.focus();
      break;
    }
  }

Looking at the code, it seems that the packet structure should be: [packet_identifier, resources, settings, mapData]

However, the data sent from the server to the client is:

[1,1,{"graphics":{"tileset":{"url":"data/arenas/svs/tileset.bmp","xTiles":19,"yTiles":10...

The second value in the array, 1, seems strange?

Might be worth experimenting to see how it would look. I think as the thrust graphic animation reaches the end of its animation, it should rotate each sprite faster and faster and enlarge the graphic bigger and bigger. From start to finish, I think the final sprite should be no bigger than either dimension of a ship (16px?). Should probably try around 10-12px for the final graphic.

This idea is sort of like that in Goldeneye (N64)'s rolling explosion effect.

EDIT: At the very least, you probably want to apply some random rotation to each sprite of each frame so that it doesn't look like a static cape trailing behind you.

Title says it. Reverse up to a wall, and then forward thrust. Presently, the thrust sprites will be above wall tiles and go straight through them. Looks a bit weird ... gives a whole new meaning to walls. :P

Title says it all. I imagine it as a keyboard layout (similar to the drawing style of the image shown by the [?] button in the header) on a webpage where you can move your mouse over keys that would illuminate pink, you can click to reveal an actions menu that contains all the possible actions (forward thrust, reverse thrust, rotate left, rotate right, fire guns, fire bombs, strafe left, strafe right, enlarge chat history, change to ship X (1-9), initiate chat and submit a chat message, etcetera).

Not change the bounce factor, but adjust the wall friction.

Currently if you come at an angle and then face a wall straight on with forward thrusters, you will slide along the wall rather than align perpendicularly with the wall no matter how long you hold down forward thrusters. You can then let go of thrusters and wait a minute or two to find yourself drifting sideways away from the wall. (The away from the wall part is technically correct, but drifting sideways after spending some time forwarding thrusting into the wall at a perpendicular angle doesn't quite make sense.)

@sharvil
Just creating this because I was reviewing gameplay recording and you had mentioned to yourself that you should implement streaks

You can currently go at afterburner speed for free with strafing. Such a speed increase should come at a price, if such a strafing speed boost is allowed at all.

One of the interesting things about no strafing is the reliance of movement on orientation. When strafing is introduced with acceleration power equivalent to forward and back thrusting, it eliminates the link between those two game mechanics since you can move in any direction equally well by combining forward, back, and strafing, without needing to turn.

If strafing is introduced, a link between orientation and movement can still be preserved to some degree by only allowing afterburners to affect forward and back thrusting, and/or by making strafing less powerful than forward and back thrust. This would keep open the balancing aspect of play between orienting for (fast) movement and orienting for attacking, rather than simplify it to two simultaneous but separate tasks.

Another issue with adding both strafing and afterburners is that it adds to the number of regularly pressed-in keys, which is a problem for many keyboards because of simultaneous key press limits. It is already a minor issue in subspace (without using either strafing or afterburners), since some keyboards have a limit of 3-4 pressed-in keys, and subspace often requires simultaneous thrusting, turning, and bulleting/bombing. The issue can be mostly avoided in subspace by a player taking care to release unused keys as they press in new ones, but with an extra three main gameplay keys (L/R strafe and afterburners), the average needed simultaneous keys would be as high or higher than the key limit.

My vote: strafing should be less powerful than forward and back thrust and unaffected by afterburners. Perhaps have strafing at half the acceleration power of forward/back thrust.

Everyone within blast radius gets damaged, if it's your own bomb your energy goes down to a minimum of 1 (i.e. you can't kill yourself).

This could come in handy, and I think you (sharvil) had mentioned something along the lines of needing to focus on settings. Need to try out those Realism Zone settings

Title says it all. Would be interesting if it could potentially be applied to other weapons as well.

For now, until dotproduct gets bigger and we see an actual "stable release" version, I think dotproduct should run on port 80 instead of 8000, or perhaps both. I have tried to share this with some co-workers and they are unable to get the actual game loaded after doing "Play Game" in the Facebook popup once they've logged into their Facebook. This is because their workplace firewall blocks port 8000 or whatever ports are necessary to actually give this a try.

This could also be an issue for students at college and university campus.

Create two tabs, sign into dotproduct in each tab. The user will jump around on other players' screen based on position packet timing.

The server should kick off the old session when a new session for the same user begins.

Might be worth keeping some objects around even if a player dies. All player objects need to be removed when a player quits.

The weapon fire delay is defined per player, not per weapon so you can't e.g. fire a bullet and bomb at the same time. This doesn't make much sense since they're independent weapons so they should also be independently rate-limited.

Posting on behalf of JoWie @ http://www.subspace.co/topic/26499-dotproduct/#entry283045

Have you tried using inverse multiplexing for the WebSocket network communication?. Could help with incidental packetloss.

The big issue with TCP is the buffering after packetloss/bit error/etc occurs (one segment gets dropped/damaged, subsequent segments are delayed until the bad segment is resolved).
Those may have been the big latency spikes in the video.

If you implement a system where you:

• use multiple WebSockets
• track the arrival of the messages you send (other party replies with an acknowledgment message)
• when sending, use the socket with the least in-flight/unacknowledged messages.

This works especially well for redundant data (like the position of a player).
I tested this a while back, and as long as you have enough sockets and the cause of packetloss is incidental (like bit error) and not caused by congestion, the latency is comparable to UDP.

Of course this assumes your engine is able to deal with messages arriving in the wrong order.

Oh, and this piece of javascript code may be interesting (works for me with firefox + java): http://pastebin.com/6tYG8rqK . Uses LiveConnect to open an UDP connection without user interaction. Downside is that it does not work on localhost, only works with domains if you set up a reverse dns.

The current energy bar alone does not give enough information about how much energy you currently have or can recharge to.

Specifically, there should be a visual marker for the max size of the energy bar, and also an exact numerical energy display in addition to the energy bar, like they have in SS.

It would be nice to have the option to show the numerical energy display next to your ship (with the option to change its transparency level), like they have in SS. This makes it so you don't have to look away from the most important part of the screen (your ship) to get one of the most important pieces of information (your energy).

Alternatively, to keep things nice and smooth looking near the ship, perhaps have the exact numerical energy display out of the way (like in the top right corner, as they have in SS, or just above radar, so that they can get energy and radar information in the same spot), and add a cleaner visual energy aid on or near the ship, so that it doesn't get in the way. Perhaps have a colored glow around your ship to indicate your energy (and have it disappear at full energy), or make the ship become redder as you get to lower energy (this would minimize visual obstruction).

In SS, players make a lot of mistakes because they don't have awareness of their current energy due to focusing on their ship and not looking at the energy displays on the edge of the screen, as is required in many situations. One of the most common mistakes among new players is to overshoot and drain all their energy. Having some sort of energy information near the ship, even if not as precise as an exact energy readout, would probably help newbies get the hang of the weapons-energy game mechanic much faster.

Posting on behalf of Absentee @ http://hardforum.com/showpost.php?p=1038937832&postcount=6 (paid subscription required to access Genmay)

Change the fire buttons to non-modifier keys like z or x.

I'm shithoused right now and even I know those are bad choices for controls. Otherwise, add some touch controls that only show when a CSS @media recognizes it as mobile and allows tablet users to play (even simple onClick commands to register a keypress would work i believe.) Canvas works great on the iPad/iPhone and simply displaying controls for those users would make it playable for those users. I can see people pressing alt-tab while they are trying to fire and drop a bomb in the heat of the game when using the current control scheme.

Thank god for auto correct and not-so-ninja edits because this post wouldve made no sense otherwise night, I'm done drunk postin.