jpdev

Members
  • Content count

    335
  • Joined

  • Last visited

  • Days Won

    11

jpdev last won the day on January 21

jpdev had the most liked content!

1 Follower

About jpdev

  • Rank
    Advanced Member
  • Birthday 02/01/1982

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

736 profile views
  1. I can totally see how such a todo list would be laughable to you. [Edit: Did not take it to be meant in a mean way at all.] .. I shutter when I try to imagine your todo list(s) for features / bugs / help requests and so much more for babylonJS. I guess it's a good time to say: thank you and all contributors for all the work on babylonJS
  2. Hi guys, This is a quick update.. I am totally running out of time and my todo list won't really shrink down and it's only seven more days. I finalized the small area in which the game will be played, here is what it looks in blender: Very simple and the whole usable area is completely flat - but that was the plan all along. I changed the way the nameplates are displayed - I was using planes with billboard settings before, now I changed it an I am using Canvas2D: This way they are alway "flat" and the same size. Also "above" any scenery so no enemy can hide behind a tree and not be targetable. (You can click the nameplates to select the enemy just as you can click its mesh.) The new feature (requested after the first healer play test) are the health bars attached to every nameplate - so you can see whom to heal. Or in case of beeing a damage dealer you can see which targets have already taken damage. I also removed the meele attacks from the caster and the healer. They were pretty pointless - but now I have to replace them with another skill. (How you grow a todo list 101...)
  3. Hi, Thank you for the answer. I have found another thing that (not accessing "_" privates) seems to give me the required information: The beginAnimation returns an animateable object that contains the from and to frames and a flag if the animation is playing (animationStarted is the name of the flag). Right now that is how I try to solve my issue, if it does not work out I will look into the current frame! Edit: While I seem to have solved my problem by checking the animateable that is returned, your currentFrame is the perfect answer to the initial question. Thanks again @BitOfGold. Solved.
  4. Hi guys, I am looking for a way to find out which animation is "really" running on an object. I start my animations this way: this.mesh.skeleton.beginAnimation(name, true, 1.0); "name" is a string that is the animation name in blender. It get's translated to a range (begin frame and end frame) and that is played. I track which animation I set last to know what the animation of the object should currently be - but sometimes this doesn't match what is actually displayed. I am not sure what goes wrong - but I would like to be able to fix it. (For example, sometimes the death animation doesn't play on players - they just look frozen until respawn, and I would like to be able to correct this.) I am currently unable to check if what animation I think is playing is really currently playing. What I am looking for is a way to do this: this.mesh.skeleton.getAnimationName() or this.mesh.skeleton.getAnimationNames() - but not by tracking what animation name was last set (that's what I am doing now) but by really checking if the correct range is playing. I will gladly implement those myself, but I have looked the data in the skeleton, and I can't tell where I can find the currently playing animation range or the current frame. Any pointers into the right direction are appreciated.
  5. Hi Raggar, I think it might not be clear enough in my description above: My server doesn't know anything about the 3d world. All movement and collision takes place on a 2d plane (the server even uses x and y as the coordinates for everything, only in the clients this gets translated into x,y,z with a fixed y). The information about the world on the server consists of a grid of values. Each value covers the information for a 2 by 2 square in the 3d world. The value tells the server if it's blocked or not. You can kind of see this in this screenshot of my map in a previous posting: Geen means it's open ground.Grey / Tree means it's blocked. When checking for collision the coordinates are "projected" into the grid and the value is checked. For line of sight checks a direction vector is created and points along it are checked for collision. The server sends this map information to the clients on login - they not only use it for client side collision but also to "plant" trees and rocks in the level. I am working on having more 3d terrains (gameplay still only on one plane) but to have it look nicer - this 3d representation is only client side and the parts are simply marked as blocking in the map data. It looks like this: The elevated rock areas are marked as blocking on the 2d map.
  6. Thank you both for the praise Players and monsters move the same way: If the player clicks somewhere or the monster decides to "roam" somewhere a target position of two values is set: x,z (y is frozen the whole game takes place on a fixed y plane). If the player or the monster is in attack mode (for monsters this is triggered when they receive damage or a player gets to close) they have another object as their target, which just means every time the movement is calculated the x and z value of this target object are used as the target. Each object has a fixed speed per second. When moving a vector towards the target is calculated (direction), it is then normalized (length = 1) and then scaled by the speed per second of the object divided by the elapsed time. This vector is added to the current position. So everything moves in a straight line to their target. After applying the movement vector collision is checked (monsters collide with other monsters and "the world" while players only collide with the world). If a world collision is detected there is another check if moving only by the "x" axis avoids the collision, if that is the case only the x component of the movement vector is applied. If removing the "x" component does not help removing the z component is tested next. This way if the target is blocked by the world the object kind of "slides along" the obstacle as long at the target isn't straight behind it. You can see this in the gif posted here: And lastly if there is a collision with another object (only active for monsters) then a vector describing the direction towards the blocking object is scaled by the movement speed and subtracted from the movement vector and this new smaller movement vector is applied and collision checked. This way monster some what get around each other. But since there is no real path finding more than three or four monsters clump up and they do not really surround their target. But since I do not plan for such high monster density anyway I am fine with this for now. This is the clumping that happens with too many enemies:
  7. Hi, I had found the thread you linked, but it thought it described a different issue. I mean the screenshot/pg in the other thread shows, that the highlight layer only "breaks" when the sprite is in front of it (coloring the whole sprite in the highlight color). In my case setting the renderingGroupId all highlighted objects break. But I guess it could be the same reason internally. Thanks you for showing the two camera solution in code.
  8. This is another update - I finished the caster class today. It's a mage that can casts two fire spells and a teleport. Fireball: It has casttime and takes some time to reach the target and deal damage. Fireblast: It deals the damage instantly but has a cooldown Teleport: Let's you choose a target to teleport to instantly My wife play tested the mage with me. I recorded the last session, so here is the first gameplay video:
  9. Hi, Setting a renderingGroupId on a spritemanager breaks the highlightlayer feature for the whole scene. I have this bug in 2.5, but it is reproducible in the current playground: spritemanager without renderingGroupId, everything is fine (see picture 1): http://www.babylonjs-playground.com/#E3D3Y#6 Result as expected: setting a renderingGroupId on the sprite manager, all highlights break and are now filling out the highlighted objects: http://www.babylonjs-playground.com/#E3D3Y#5 The only change is line 114 is now commented in, the result is the unexpected and undesired filling of all highlighted objects: Note: This is not about the interaction of sprites with the highlight layer (the whole sprite in front of a highlighted object gets colored) this is only about highlights breaking that are no where near the sprites when the spritemanager has a renderingGroupId. Any workaround would be great. For my game I need some effect sprites to render above all 3d objects and I also use the highlight layer - this is not possible right now.
  10. Even as if you look down (move the camera angle towards the ground) more cubes become visible - it seems that the fog behaves as if it were attached to the camera and not as fog within the 3d world.
  11. @gryff & @hunts: At least in my case (maybe because I don't know any better) the server stuff in itself isn't all that different from just writing a normal gameloop that moves objects around. It's even in the same language, since I use nodeJS for the serverside. The next thing it's about getting the stuff to the clients (not complex either, since you can just serialize a bunch of objects with a simple call to JSON.stringify and get them back on the client side with JSON.parse). Now it's the clients job to represent the server objects to the user. For me the complexity (and bugs.. lots and lots of bugs) come in at these points: - On the server side: not sending everything all the time to the clients (tracking on the serverside what has changed and only sending those objects) - On the client side: haveing things keep moving while waiting for the next message from the server (server says playerA is moving from (10, 20) to (20,20) - the server will only mention this player again, when he reaches 20,20 or he cancels his move or does something else - so now the client has to animate the player moving there on its own, with the same speed that the server moves stuff) That pretty much describes what is going on in an abstract way. When the game is done I will most likely release the source code (which is a mess, keep in mind this an experiment). @Deltakosh: Thank you again for the encouragement - I feel the need to say: The goal & scope of this game is to provide something to play for a few minutes that requires 3+ players that coordinate a little. I say this so nobody expects a mmo-experiance or something like it. With that out of the way, here is a small update: The last fighter skill is something to press when there is a lot of damage incomming (or maybe when the healer is busy running away from something) to keep you alive a little bit longer. It's an energy shield. Here is the playground I used to come up with an effect for the shield: http://babylonjs-playground.com/#LFUNT#1 Also the scry mentioned in an earlier update got (kind of sloppy) walk & death animations and is now in the game. Here is a fighter using all skills, first a charge and then swipe & shield to fight a scry: I have started working on the third and last character class, the caster. Here is the full team: Last weekend I had a friend visiting and we took about 20 minutes to test the game, he played the healer and I played the fighter. It quickly became obvious, that as a healer you need to see the health bars of everybody and a better way of targeting who you want to heal. He also found a bug where the healer would attack other players if you first attacked a monster and then heal a player. All those things are really hard to notice when solo testing the game, which shows how important it is to get help testing multiplayer games.
  12. I think the solution to the picking problem should be to move the mesh by modifying mesh.position instead of changing the vertex data. (shown in the code georage posted) I am pretty sure that will fix your picking issues. (Because that's the way I move my meshes and picking works fine.) mesh.position.x += 1;
  13. Hi aarroyoc, You babylon file only contains a cube named "Cube". I have put your file on my server, and this playground loads the only mesh in it: http://babylonjs-playground.com/#2G9IR#0 You can confirm, that there reallly is only a cube in it (and no "sectarian") by opening it in a text editor - it's json and human readable.
  14. Thank you Delakosh & joshcamas for the praise. In reply to the idea that this could be a community thing: I fear this project is a long way of from something that can be easily extended. Since it is my first attempt to create a multiplayer game it lacks structure and uses many "hacks", just because I make it up as I go along. Anyway, here is my newest update: The fighter character has learned to charge at enemies. I started with this playground with the goal to create something like a heatwave/shockwave: http://babylonjs-playground.com/#JNOJX#4 I improved on it a little when adding it to the game, this is what a charge looks like: Next up I finished the healers skills. They consist of a normal heal with moderate casttime and no cooldown, an instant heal with no casttime at all and a group heal with a longer casttime and a cooldown. Here are the heals "in action": When experimenting with the charge effect I came across this thread: I now finally understand the difference between hasAlpha and adding a opacityTexture: hasAlpha: This is 1 bit transparency. A pixel is either fully see-though or completly solid. (alpha test) opacityTexture: Smooth alpha values from the texture are used. (alpha blending) Next I made a playground to add an effect to a swiping attack for the fighter character. It deals damage around the character. http://www.babylonjs-playground.com/#OJCYN#0 When put ingame the swipe attack now looks like this: Notice that it is completly overpowered in this version - you will not be able to just swipe a bunch of enemies and kill them in one hit.
  15. It's not anymore... Didn't manage to do much on my project this week. Only one month to go. Well, I guess we need to chaaaaarge to the finish line... (A very good use of the limited project time is to make gifs for stupid puns...)