yes, thank you for the help, this will improve the game.
Okay, everyone, with the help of āThuamaturgeā I was able to include a customizable controls option, I have updated the links in the original post, thanks.
I have placed the option just after you past the title screen and before the character select screen.
Congratulations on releasing the new version, and Iām glad if I was of service.
Why touching a nuclear paint bucket makes you lose your life?
heh heh, well it is still in alpha, what that bucket is actually supposed do is explode killing your character with the explosion, if you played crash bandicoot 2 or 3, that game featured āNitroā boxes which exploded on contact, same concept here.
A little stereotypical since nuclear material itself cannot explode, anyways sorry, I have only the function of it covered at this time, I still need to work on visuals of it.
Let me know if you are still having trouble with the controls, because I want incorporate onscreen cues showing what you can do and what key does it.
yes, thanks vary much, I,m interested to see what people think of the customizable controls.
A quick update, I have fixed the water jumping mechanics (okay it was done with the key mapper update, but forgot to mention it), I have also included a on screen keys that display the keys to the camera controls as well as the secondary mechanic appropriate for the current situation.
This was at the response of some people getting confused at the controls, of course the links are in the updated links section named as the original links found in the original post, Enjoy.
I think these updates are minor ones.
In my opinion, your game suffers from wrong pacing - everything is too slow. And this is not my PC - I watched your video.
Fading menus in and out, skipping the dialogs, moving the character, etc - shoud be sped up from 2 to 10 times. It just lacks dynamics. Look at other games in the similar genre - Crash Bandicoot, Super Mario 64, etc. They are pretty fast-paced.
Donāt trying to be mean, just want to give some useful advice.
I get you, but other then title screens, and maybe the character interactions, I donāt have any clue how to speed the game up (at the moment), I apologize.
Edit: I wondering if it is the FPS cap you are experiencing, I donāt know if I ever mentioned it, but the game itself is capped at 30FPS, because the laptop I have is not strong enough for 60FPS, it used to be, but a update to 10.1 changed that.
Edit 2: I just remembered something, if you are using the windows build it is really slow compared to the mac and linux builds, and this due to openGL being the only option on the official " windows wheel", believe me that I tried to get DirectX to run, and after numerous tricks still failed, so I settled with the current circumstances.
Also I do apologize for the videos, they were screen captured from my laptop from quicktime, and what you see is the vary first release of the alpha, I have shorten load times significantly from then, as well as changed the graphics.
Regarding character-movement, your game is based in Roaming Ralphāis that right? If so, look for the code that moves the character. You should see in each action (moving forward, turning right, etc.) a number multiplied by ādtāāif you increase that number, the speed of the corresponding action should increase.
It is collision pusher, thats why characters move so slowly, in the game the character is moving 3 ālevelsā faster twirling then if she/he were walking, if the character moves any faster while twirling then she/he begin to move through walls in certain conditions, faster then that starts moving through walls more commonly.
Edit: I was also thinking it could have been my choice of using polyset instead of basic shapes too.
Ah, I see. In that case, two points come to mind:
- First, as you say, basic collision solids would likely be more reliable than polygonal collision, if Iām not much mistaken.
- And second, take a look at this manual pageāit describes a feature that may improve the reliability of your character (if represented by a CollisionSphere) colliding with polygonal collision at high speed.
You could also look into the Bullet physics engine, which Panda has bindings forāI donāt know whether it does handle such cases better than Pandaās built-in collision system, but perhaps someone on the forum has already looked into it.
Huh, well I have that mode in the article you gave me already on, however I never knew you needed a special setPos for it, I thought it took care of all the work automatically, question, is it just the setfluidPos? or is there setfluidX, setfluidY and setfluidZ?
Your second solution seems more doable, I mean there is no scene editor for Panda3d, so how would I even implement basic collision solids? Plus it will stifle my creativity if I did so anyway, so you second solution is more possible, thanks for the help.
I honestly donāt recall whether Iāve ever used Pandaās āfluid-posā methods, so Iām afraid that I donāt know much about how they work. However, I imagine that the API should be able to tell youājust look up āsetFluidPosā, and see whether the same class has āsetFluidXā, etc.
It can be done, either in code, or via a 3D modeller like Blender, I believe.
But if using fluid collision-detection works better for your game, then fair enough!
Yeah, I have been using Blender3d for object placement, but the accuracy is off, and for something like collision, it needs to be accurate, unless your talking about transforming a basic box object in blender3d into a collisionSolid? rdb show me something like that when I was creating āloadingā zones.
I do have concerns with performance if I start setting fluidPos, but I,m going to attempt it soon, Iāll look up the APIs now, thanks.
Thatās weirdāthe placement shouldnāt be off, I would think. (Unless youāre doing something like placing an empty object and using code to spawn a collision-object at its location, which can be prone to inaccurate placement, I think.)
Thatās what I had in mind, I believeāalthough I think you can also generate other solids, such as capsules.
Yeah, the answer to your first statement is a marker system of small tile objects which are destroyed at the time of loading the model and their pos obtained put in dictionary and use for other objects, to place them, sorry for not clarifying.
Ah, fair enough. Yeah, I can see that being inaccurate.
So there is a setfluidX,Y,Z, so I going to start testing this, I just wanted to say thanks for the tips, Iāll report back in while.
Itās my pleasureāI hope that the āsetFluid*ā methods work well for you!