Fangames > Engines

RegalPrime-UnityEngine v1.4.1 - 8-18-15

<< < (6/13) > >>

RegalPrime:
Finished watching the video, thanks for all your comments.
I will comment on what you mentioned during the playthrough.

Mashing bullets doesn't work - There is a delay on fire rate set to every 0.1s. Instead of limiting the bullets on screen I just limited the fire rate.
That torch, was added in near the end and it seems making the pickup / drop button the same as shoot was not too bright :p
Because of it being the same button, there is a 1s delay between being able to pickup and drop it, which adds more confusion.

Guy sometimes off the ground a pixel, is probably an issue with me stinking on creating the ground hitboxes, but I will keep an eye out to make sure it isn't anything more.

Mentioned that water might making the character fall slightly slower. Right the only difference between normal stats and water stats is that the fall speed is capped at -2 instead of -9. I had a hard time finding stats and information about how certain objects effect the player. For the most part I think I collected from enough random posts and sources, but its possible they may have been wrong.

Boss was laggy. Yep, at the moment each object is being created and destroyed X seconds after. For simple things this is ok, but massive amounts of object it can be laggy.
There is a thing called Object Pooling that reuses the objects instead of creating and destroying them all the time. This is extremely more efficient but I haven't coded it into the object spawner script yet. On my list of things to do.

Now onto the more complex stuff.
Right now the character is controlled by velocity / rigidbody / collider and there is nothing other than Unity stopping the character from going through the walls or ground.
I have found that even a spike 1-2 pixels inside another block can still be "touched" if you are moving at high enough velocity, even though the character actually never ends up inside of that object. So walking over a certain "safe area" is ok, but jumping and landing will cause you to touch that submerged spike pixel. So it seems that unity, even though for a split second, will move you to your next position, calculate game stuff, then say, Woooha you aren't supposed to be here, and move you back to just before the solid object before the visual frame loads. So if you are at the correct align you could, for an instant, be considered in a block and use a basic jump instead of double jump or be inside a spike and die. This is what was going on and I need to really dig into how Unity actually calculates it and how my scripts are interacting with that effect. I will probably have to put pre-wall / ground checks to prevent that. Overall I could remove velocity all together and put in Transform based movements, but then I loose all the power having a velocity gives.

Holding onto directions after reloading doesn't move you. Yep, I know ///
There is also a small chance of doing a boosted jump, which you did once and were confused. This has to do with the jump signal being pressed, released, and pressed in a single frame (I think).

Unresponsiveness of movement. Ive been meaning to update how and when button presses work. Ive been away from playing typical guy games since I started working on this engine and I know I have lost "what feels right." I know my design choice for button presses is very basic and worked at the start, but its time to update it.

Overall these "more complex stuffs" are all in the 2D controller which needs an update badly anyways.
I think I spend wayyyy too much time on coding prefabs to make it easy to create a screen (All the objects in the game were just drag and drop prefabs).
Its about time I go back to coding the 2D controller.

As for things I learned from watching you play.
I took out the option to change the screen resolution (which is default unity stuff). It seems I should of kept it in.

My screen wraps prefabs where placed in quickly. They need to be positioned better to give a more real screen wrap effect.
After the castlevania room. The spawn point is in a dumb place and since you are pressing left to get into the boss room, you are extremely likely to walk backwards a room. Sorry about that.
Boss, Hands have too much HP for the length of the game. It has 10 HP each and after watching I feel it was wayyy too much. Maybe 5 seems right.
Spinny hands attack has a RNG component on the right hand which makes a "safe spot" never the same area. I will take that variance out.
RNG on type of attacks, I may change it to PRNG so the probability to attack the paws increases if you get bad RNG.

Finally OMG finally. I almost died every time you went back to the main loading screen because that "Reset Data" button was there.
Seriously one push of that and your save was gone. I put it in because it was easier to test things but seeing it on your screen scared the crap outta me.
More than likely I will remove it and put a difficulty setting in.

Any comments on my comments would be welcomed if you have any more questions.

Zurai:
Hey  :azoCheer:

Im glad you watched the VOD and take the criticism seriously. Actually all of your explanations make sense
and for every problem I mentioned I had the same reason in mind but I have a hard time explaining it like
that :P

I really can't add much to what you said. For the spike/collision problem:

I don't know if unity offers this option, but in Gamemaker you can differ events between "Step event" and
"End step event". The code which you initialize in an "End step event" is always executed at the end of a frame.
So if you have the option for this, you could handle it like that, that all the stuff which is pushing you out of a block
an repositioning the kid, is put as a "Step event", so it's happening at the beginning of a frame. And the collision detection with a lethal
object could be handled in the "End Step Event" (or however it is maybe called in unity).

We had the same issue in Gamemaker when a spike is on the same height like a platform or a block and this is the
solution Seph and Lemon (I think) came up with. Maybe it helps you  :atkHappy:

I hope I could help you out a bit with my comments and looking forward to the next release :FrankerZ:

RegalPrime:
Tested a real game vs mine, I had a hard time telling control differences. I guess I've been away from playing them for too long :/
I rewrote a chunk of the 2D controller tonight and it should calculate the key inputs instantly now. I seems to be able to short hop faster now but the movement controls I need to test more. Im not ready to do a update yet so others can feel it out.

Sooo, I spent the night doing maths in my engine and then searching the web about certain issues Ive been having in Unity annnnnnnd hmmmmm.
I come across discussions about certain oddities I also have been having and I found a possible problem going forward.

I created an exact ground check within one pixel below the character and it wont detect it even though their positions are the correct X pixels apart (if you calculate offsets and whatnot). Even if 2 colliders are touching each other there is a small cushion that are maintained to deal with calculations of them bumping into each other. When they touch each other, both colliders may move to deal with the collusion. Sadly, this is why a spike a few pixels under ground can be touched when jumping or running into a wall.
This same issue is why you can clip the side of a platform and not fall even though you normally would.
There are apparent physic settings to help deal with this issue for the 3D colliders but not for the 2D colliders (these are newer to unity).
They say edge colliders can deal with this but placing them exactly in the editor is pretty awful (no snapping function) and creating them during runtime via script is pretty awful.

Post I found about this
https://www.iforce2d.net/b2dtut/ghost-vertices

I really like the idea of making this work while still moving the guy via physics based forces, but doing so offers this challenge.
Removing physics based forces might fix this, but you loose so much of the power that Unity gives.
I will have to think about this and search some more tomorrow. Might have to make a test controller from scratch to test exactly how this can be fixed.

Yagamoth:
Greetings,

I really like what you've done so far with this project. In a small (unfinished) project with a good friend we also ran into the problem with exactly ground detection because of the "skin" of the colliders. Ultimately we decided it would be better to use our own physics, despite losing that much power from Unity. Overall the precision was more valuable than the power of Unity - I imagine that might be a similar thing for this project. (Please note, I'm only marginally experienced in Unity, my friend did most of the work of this ^^; )

I have only skimmed through the thread very briefly and read the last post. In any case, I'd be highly interested to create a fangame via Unity if you were to release the source at some point :)

- Yagamoth

RegalPrime:
About time I do an update regarding what I have done the past few weeks.

Most of the game changes I listed above have been put in and pending the next version of the game I will list the exact changes. Next version release will be soon and add in most of the below changes as well. Because of theses massive changes to the underlying scripts, dont be surprised if something goes wonky. Maybe a few days to test.

Much like I was complaining about in my last post and what Yagamoth said is true about Unity. There is a small buffer of about 1.5 pixels (0.75 pixels per object) that cushion 2 physical colliders (trigger colliders dont have this buffer). I spent the majority of my time writing another script that calculates very exact area collider checks for Ground / Wall / Ceiling. I could now see how far I was from an adjacent object when I was near it and thus calculate this buffer. In 3D colliders, they have an option to lessen this buffer, but the 2Dcolliders do not have this option as of yet. I have the buffer as a variable and thus can change it easily if something would come up later. Only bypass would be to write my own collider classes, but that seems like a ton of work and then again I loose the power of Unity.

Listed as a complaint from the game. Physics seems to make you touch objects within another object even though you never actually touch it. For example, walking over a spike that is inside a block is fine, but jumping on that block will cause you to die (I would guess that during the physics calculations, the character is temporarily inside it and thus you die). Now that I have my area checks, I calculate warnings to my move / gravity when it is within a certain range of a solid object and have it move the shorter distance to right beside the block. Soooo, for now it seems that problem has been fixed (there might be some fiddling with the code, but its a vast improvement). My prechecks are fairly small area (~20pixels) because of another problem with it grabbing information from other objects behind the one I want, but when I figure that out, I can increase the check range.

Changed how Button presses were done. They should be more immediate. Hopefully this should fix the unresponsiveness. The first playthough after I changed the code was a trainwreck. I was ramming into the sides of spikes and my jump timing was off (so at least something has changed).

I spent a few days writing a 100% transform movement character controller (ie always move via positional movement). Having the aoe checks made this possible. I did this because I would know that 100% the character is moving / falling / jumping X pixels. I put both the physics based and pixel based on the same screen and they both jump and move the same speed, which is a good thing.

As for Holding right after loading from a save / a screen doesn't work.
When a scene is loaded, Unity automatically calls  Input.ResetInputAxes().
This resets all keyboard inputs, which means from scene to scene it will not remember your key presses.
Each screen in my game is a separate scene, which is pretty stupid, and not efficient, but easy to setup. A real game would have multiple screens in one scene and load / reset the objects when necessary. Doing this would allow key inputs to be maintained. I am not at the point in this engine where I want to put a lot of time into efficiency. Getting the base things to work comes first. Reloading the same scene over and over would be first to fix and thus respawning would be fixed when being in the same scene.

So, as for the engine, I will continue to work on it even though the dream of 100% pixel perfect while maintaining physics based movements is a bit far off due to engine collider limitations (either that or I will have to write some extensive collider scripts which would break much of the interaction I have built up in the other scripts). Hopefully, things are a bit more solid now and the guy moves better.
I wouldn't expect its perfect yet, but I know I am getting closer each time.

@ Yagamoth
Let me know what you have planned.
I would be willing to release it fairly soon to interested people (which would include all of the game screens), but you have to understand that it is going to be messy and not organized the way I would like to release it to the public. You would also have to understand that it is possible that there would be massive changes in the future that would make future versions of the engine not work well with certain scripts you have created. At least basic room layouts should be fine due to tags and layers.
I still need to go through every script and see how well they held up against other scripts I have wrote (My camera script script works really nice but I know it needs to be rewritten to be more efficient, stuff like that). Some code I wrote months ago, seems like child's scribble now, just because of the things I have learned.

Navigation

[0] Message Index

[#] Next page

[*] Previous page