caymanbruce

Members
  • Content count

    111
  • Joined

  • Last visited

About caymanbruce

  • Rank
    Advanced Member
  1. @jedimasta Thank you for the detailed explanation. They actually patented the game in the US so I think you need to make sure it's legit when you release your game to the public in the US. You don't really need to worry about problems for thousands of players now. Actually, if you can go that far, you can hire somebody else to solve the technical problems for you. As far as I know Minecraft's multiplayer mode is also laggy and being complained a lot. For building a distributed networked game, I have heard Erlang is a very good language for the backend. It's easy to learn and it has built-in distributed environment support and can scale quickly.
  2. I have seen the game video and I think the game looks very cool. Is it a gambling machine? I am very interested in this. Hope you don't mind telling me the rules. With regards to the performance issues of your house-built game, I think the best you can do is to profile it, both on server side and client side to find out where the problem is. You can create some dummy players to play with you to simulate a multiplayer game. For me, the client side part could be not caching the resources or creating too many new objects in the animation loop. The server side slowness may be caused by sending too much traffic in the update loop. But you are not creating a real time game I guess the network payload is very low in your game. The problem you came across may not be a network code issue.
  3. @Jammy That is impressive. I will first try it without the containers and see how it goes.
  4. Very good point. Maybe I should do that too. I always want to have control to individual sprite so maybe it is unnecessary to use a Container for each player which contains a group of sprites. But if I do use it. I want to know if there is any additional cost? Consider maybe I will have 800 players on the map, which means 800 containers if I use it for each player. I have a vague perception that maybe it's better to reduce the number of containers in the game.
  5. Thanks. Suppose I use ES6 ( I like to use ES6 ). If I have a Train class in which I draw the sprites, I can just pass in the parent container, such as "gameScene" or even "stage" to add the sprites as its children. Looks like I don't need to create another Train container in my Train class. Is there any good reason that I have to use a new container in my Train class?
  6. Thanks for your input @Jammy. Your game is very interesting to watch. At the moment my game is still immature so I have only a few sprites to be destroyed in one second. But I expect to delete at least 50 - 60 sprites a second when my game is finished. My game is not tile-based maybe this makes it a bit easier to handle.
  7. When I first use PIXI.js I used to put every sprite onto the stage. Then I know that there is a Container class to hold the sprites. So I can add some sprites onto one container and other sprites to another container. After that I can add all the containers onto the stage and PIXI.js will handle the drawing for me. This is a very smart idea because I can use it to group sprites that I may want to scale together or delete together. But on some occasions I still have questions putting them together because I am afraid I may have a bad design. If deleting a container means it also delete everything inside the container, is it a good design to put sprites into a container if I want to delete them as a whole in the future? Does the computer need more resources if I use many levels of containers in my game? For example, if my player have several segments or several parts, like a plane with some shield or small added laser guns, is it better to group them into one container or just put them into the parent container? If I am building a train, is it better to put all the carriages of the train into a container as a whole, meaning the train is a container, or put them into the parent container? If robustness and efficiency are the main concern, what design rules should I follow?
  8. Thanks for advice by @xerver and @themoonrat I don't have time for detail profiling at the moment. But I have come up a mixed approach for this situation. I think I will first make the sprite invisible when it's off screen, then after a certain amount of time in the animation update loop I will perform a removeChild for every invisible sprite in the Container. The interval will be at least 1 second so it's not performed every frame.
  9. you are right.
  10. Ok I would just use this: sprite.texture = PIXI.Texture.fromCanvas(canvas); but not sure if I need to destroy the old texture or it will be dumped automatically. Using this technique I need to be very careful with the alignment of elements inside the resized texture. I have also found that even if I use a bigger size texture I still need to scale the sprite a little. Maybe I didn't calculate the new size very properly.
  11. Do you mean to reapply the same texture to the sprite with the `new PIXI.Texture statement` when I need to scale the sprite? Also you are using PIXI.SCALE_MODES.LINEAR in your code.
  12. This works! Thank you. Now my problem is that the texture becomes a bigger ugly pixelated texture after scaling like I said in another thread.
  13. Thanks I have tried this but all I can see is a bigger pixelated texture. What do you mean to set this before loading the texture? I don't know how to do that since I use `Sprite.from(canvasObject)` to build a sprite. I was trying to use it as `sprite.texture.baseTexture.scaleMode = PIXI.SCALE_MODES.NEAREST;` but it doesn't go well.
  14. Thanks I generate the texture at run time. So there is no image asset.
  15. Thanks I will try that later and let you know the result. Currently it has no effect because I am doing this inside a scaling container.