Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - RegalPrime

Pages: 1 [2] 3
16
Engines / Re: Unity Fangame Engine - 1-23-15 GameUpdate and Engine Release
« on: January 23, 2015, 04:08:25 PM »
The whole collider issues was one of the main reasons why I haven't released the engine. With solving a majority of these issues + having a workable alternative character that works well (the pixel movement guy), I've found there's no reason to not release it in its current state.

There is still a lot of old items in the engine I wish I had time to rewrite or even add, but for now it is stable enough.
- Uploaded and downloaded and tested to make sure I could open it and whatnot.
- Seems everything is in order
https://www.mediafire.com/download/x1w70hkaq8b11y8/RegalPrime+-+UnityEngine+v1.1.zip


Updated the engine and released game version 1.03
- There are 2 downloads, one uses the physics guy and one uses the pixel based movements as the main player
- Pixel guy moves via transforms and requires almost no collider buffer. Only con is the inability to go up slopes
- Physics guy moves via physics forces but requires a larger collider buffer to remain stable. Increased collider buffer makes the player collider fatter
- Update includes what was listed in the last post + below
- Most of these deal with the aftereffects of messing with collider settings

Hill climbing works on physics guy again
Distance to wall calculation updated to deal with edge colliders
Distance to ceiling calculation updated to deal with edge colliders
Climbing works while upside down
De-childed the character if they are on the treadmill when the individual object recycles itself

Moving platform fixed
- It wasnt that much of the collider size, but the value used to determine when the player was above the collider
- Changed this to a public variable and increased the collider box. This way it can trigger earlier yet still calculate correctly

Reloading a scene with an animation of a dead unit cause a bug - Fixed (forgot to reset the IsDead tag)
Sliding down an edge collider - Am assuming some aftereffect of changing the collider buffer / penetration for penalty values (Fixed)

Found a bug that deals with some weird combination of pressing and releasing the jump button multiple times within one? frame. Happens very rarely.
Need to pinpoint what is actually the cause before attempting a logic fix.


Basic Tutorial
Simple tutorial to cover a few things
(click to show/hide)

17
Engines / Re: Unity Fangame Engine - 1-15-15 - Collider / Scripting fixes
« on: January 15, 2015, 11:53:12 PM »
Hmm, didn't know it was that long since my last update. I probably said this above somewhere, but I really hate programming the more complex back end stuff for a long period of time, but it seems that's all I have been doing since the last update. Also, took some time to learn more about the inner workings of unity so I can program smarter.
No engine / game update, but I am working on a testing room I can use to test some problems / get feedback and might release that later.

Did some research on when unity polls key inputs and when the screen is rendered and changed how key inputs are done again.
Updated and cleaned up both movement scripts. After updating my pixel movement script I found a logic problem where even when not moving, the script was grabbing no movement as an input for that frame. This could cause a one frame delay when actually wanting to move. Knowing when the frame renders now allowed me to clean up the scripts and fix the weird snapping that happened at times when getting close to a wall.

Made the velocity and pixel movement scripts the child of the 2dcontroller and thus can be used interchangeably in the engine. Rewrote the parent to be more generic and encapsulated most of the variables. Was worried about getting this to work right, but the pixel based guy script interacts with all the game objects like he should, so I guess it worked.
IN SHORT, there is a prefab for the physics based movement and a prefab for the pixel based movement character. Both can interact with all of the other objects in the engine without having to change any other scripts.

Put a line of code in the spawn controller so that I can force which guy spawns through the entire game

After having some time, I finally found the new settings to change the size of the collider buffer (came in with the newest patch).
Previously, the default setting caused the player to have a 1.5 pixel extra buffer when "touching" another collider (ie a wall or even the triggering of a deadly object). This buffer made the character much fatter than its normal collider size and caused some weird issues (poor accuracy of jumping / bonking head early / etc)
The settings now allow to go down to 0.01 pixel buffer (a pretty big difference)

This is good HOWEVER, this buffer is used in the physics to help calculate collisions of solid objects. The physics guy collides with corners of certain square objects very weirdly when the buffer is set extremely low. He will kind of bounce off of edges a bit. I am not sure if there are settings that can increase the accuracy of these collisions or the rate in which they are calculated. The good news is that the pixel movement based character does not have this problem and no longer has this collider problem.

Of course, having lost this buffer, some of my objects started acted weird at times (falling through moving platforms and whatnot)
I spent a bit of time updating some major scripts. I haven't had the time to test many of the other object interactions to see if they held up.

I also took this time to figure how and when colliders trigger so that I can create more accurate "deadly objects"
Previously the spike's edge collider was just thrown on "by eye," but now I have a better idea of what to do next.
With that 1.5 pixel fatty buffer before, objects triggered before they should have and were inaccurate, so I shrunk the collider size to compensate. I no longer have to do this and I need to change it back.

Serious update on CalculateChecks script (used to calculate the distance between 2 object's colliders)
- This script is used to detect when the character is grounded and near other solid objects (for movement / gravity reasons)
- AoE calculations to detect wall / ground / ceiling / pits are now generic and will know how to calculate the offsets based on that objects current settings
- Took out the need to have separate code for if the object is flipped / if facing a certain direction / scaled a certain size / etc
- Increased the accuracy of these checks (there was a few places when the character was on the edge of a platform, but this script said he was not grounded and thus played the falling animation and caused him not to be able to jump / refresh the jump)

- Updated the formula to calculate the distance to a wall / ceiling / ground object to deal with all of the variables in one formula
- Calculating the distance to the ground for an edge collider was updated as well (distance to an edge collider for wall / ceiling are not in yet)

AI script now uses check surroundings script to detect walls / ground / etc (same script that is used on the main character. CalculateChecks.cs)
- Added pitcheck to the script to detect if there is a pit in front of the object (used to tell the AI to turn around when patrolling)
- No longer need the offset objects on the AI gameobjects, which should simplify things a bit.
- AI acts more stable because there is no need to manually set the offsets on the gameobject.

Climbing changed to detect walls so there is no studdering / wiggling when climbing and humping walls (also Uses the CalculateChecks.cs script)

Teleport in room script - maintain offset was bugged and fixed.

So, overall, a lot of progress in fixing some major problems that were plaguing the core of this engine (those colliders :/).
Next thing to fix is the aftermath of shrinking that collider buffer and its effect on interaction with other gameobjects (will involve going through most of the prefabs / scripts that interact with the character). Also need to figure how to make the physics movement guy collide with corners better when the collider buffer is set very small.

18
Engines / Re: Unity Fangame Engine - 12-21-14 - New Gooey
« on: December 21, 2014, 01:42:37 AM »
https://www.mediafire.com/download/slyxbav7kimpf3a/I+Wanna+Help+the+Cat+v1.2.zip

- New GUI system hype !! -
Took me a bit of time to figure how to use it, but I am getting the hang of it. I am also glad I waited instead of learning the old system then learning this one.

Created a new Loading screen using the new GUI. It look nice and crisp and allows for me to change design and whatever without totally breaking the connections anymore <3
It is pretty plain at the moment, but it is a lot better than the old version.
(click to show/hide)

Created a HP Bar GUI + prefab. The HPModule script can use this and it works well displaying the objects / enemies hit points.
Has various options on when to display the HPbar / speed of hp removal / etc.
- Enabled the option to show the HP bar when the bosses paws are hit.

Replaced the basic label script with the new GUI system. Signs and character chat boxes look better. I didn't go overboard creating boxes. Just a simple bordered square that can be expanded upon later. A lot cleaner to work with compared to the old script based GUI.

Created a game over screen using the new GUI. It looks 100% the same, but it needed to be updated.


Finally got around to totally rewriting the camera script. Whereas it worked well before, it was a huge ugly inefficient mess. After sketching out the design, the rewrite went smoothly.
Also updated the script that triggers the camera manipulations when the player trips a spot. This one had a few problems just because I totally changed how the camera script worked from before, but now I think it is all fine.

Save point added an option to reset the default camera position on trigger, which is helpful when resetting the camera on larger scenes (where the camera follows the player).

Put the 4 scenes added last patch into the main game scene lineup.

- Stuffs -
I am a bit disappointed in not being able to smoothly access preventive measures when using physics. Physics are calculated all the time (when there is free time), whereas my preventive checks are calculated once a frame. Most the time the guy will move very well and other times you notice a bit of a snapping effect when running into a wall. I mean its better than dying to objects inside of walls, but I need to dig more into how to do this better. I will probably flesh out the 100% transform 2d-controller and see how it works in game. Sadly it will not have the power to move up slopes and I will have to change a few things if that happens (will have to figure how to do slope climbing later I would guess).

I have been cleaning up the engine files as of late (when I haven't been programming) and am getting to the point where I am feeling better about releasing the engine to the public.
As long as people understand the state the engine is in (not perfect), I have no qualms about releasing it in a somewhat messy state.

19
Engines / Re: Unity Fangame Engine - 12-08-14 - Update + Download Link
« on: December 08, 2014, 03:08:38 AM »
https://www.mediafire.com/download/a9awltjiqgw7fhi/I+Wanna+Help+the+Cat+v1.1.zip
Found some last minute bugs and got them fixed (that Reset function on the boss screen messing up again).
If you tested the first version, let me know how this version feels. There are still a couple of things I wish I could smooth out, but things are better than before.
If you haven't tested this game / engine yet, feel free to this version. There is a scene select on the main loading screen, so you can jump around to any place in the game.

Ooohh, also the new Unity version was just released this week. Which means I can update my version (hopefully nothing breaks)
They added in the new GUI stuff, which means I will have to watch all the tutorials and start testing it out. When I get things settled I can update the main loading game screen.
It should be a lot easier to create and design with the new patch. Seems like a fun mini-project.


Well, it is time for the new game / engine release. I will end up being gone all next week so I worked on getting this put out this week.
The amount of backend things I have changed, I would bet there are some bugs somewhere. I ended up adding in a few things I wasn't planning, but the game should run a lot better now (I'm sure its not 100% perfect, but its a big improvement).

** Update Notes **
I put back in the default unity pregame screen to allow for changes in resolution size.
It also has options to change the button settings, but do so at your own risk.
I have not messed around with that window and I have no clue how it interacts with my in game settings.

Platforms pull less when jumping through them (horizontally)
Vertically is still a bit pully though.

Torch pickup / drop is now the X button.

Changed how Button presses were done. They should be more immediate.
Hopefully this should lessen the unresponsiveness.

The below were added to detect when the character is close to a solid object and will move them a shorter distance to prevent the physics bug (where you could clip a deadly object in another block and die)
- Added in ground check
- Added in wall check
- Added in ceiling check (no preventive movement checks yet)
-- There is still a small possibility that you will clip a ground object when falling (you fall way faster per frame than moving), but it is an extreme improvement over the default.
-- This is because the AoE ground check is not as big as I would like atm due to another problem that arose (when I fix that, I should prevent this from happening)

Reset Data on the Loading Scene is no longer an option
- Difficulty options were added in instead (easy / medium / hard)
- Items without the proper difficulty permissions will be disabled
- Nothing in this game uses the difficulty option, but the option and script have been written

Boss Room - cant go backwards a screen
Boss - Spinny hands attack - No RNG on the attack, there should always be a safe spot.
Boss - Paws have 5hp each. 10 was just too much.
Boss - I noticed the death timer on the projectiles was too high and objects were hanging around too long.
-- Changed the death timers based on each attack to the smallest time needed for an object to leave the screen (less objects active at once, less calculations)

Object Pooling put in the new object spawner script (has a variable to disable it if needed)
- This effects any screen with constant spawning of objects (including the boss)
- Objects are now reused instead of constantly creating and destroying themselves (this should increase efficiency).

Object Pooling added to shooting script (reuses bullets)
I think the spike treadmill uses object pooling now as well (Im sure there are others as well).

Added the Reset() Event to every script
- This allows one script to call the Reset() function on all available scripts that are loaded in the scene
- The Reset() function is added to each script that needs it and will change the script back to the initial settings / position / etc
- Instead of constantly deleting and reloading the same scene (and its objects), using this will allow the scripts to reset themselves giving the illusion they have been reloaded
- More efficient, but there is the possibility that some of the Reset() functions could be wrong and thus have bugs.

Reloading the same scene will now call the Reset() Event instead of deleting and reloading the scene (and off of its objects)
- This will allow for key presses to be active when constantly reloading on the same screen (this however may not hold true between scenes)

Commented on every script and sorted them all out

Object pooling went in ok, but the Reset() event on some scripts was a pain (ie the boss / spinny room).
Im sure it is a lot easier to write a script from scratch with the Reset() event in mind instead of modifying an already existing script
It wouldn't surprise me if a few bugs might show up now.

Scene select is available on the loading page - This is for the people who want to jump to a certain scene to test (or just want to browse through my game).
Just move the slider bar to the correct scene number and click "Jump to scene"
Using the jump to scene will use either your current used slot or slot 1 by default.

It gets fairly old writing the back-end scripting so I took a few days off and wrote a nifty background effect.
When this script is triggered, it sends a shockwave-like color changing effect outwards through out the valid tiles.
+1 test scene - Has a few of these trigger objects on a empty scene with different variables set to give a feel of what this script does
+3 new scenes using this script - Created a simple gimmic involving this script.

For ease, I created a button on the loading screen that allows you to jump to these new scenes.
For now, they are in the game, but not attached to any other scenes (they are actually after the "you win scene". After I find they are bug free, I will put them somewhere in the middle of the game.

Picture of the first new scene
(click to show/hide)

20
Engines / Re: Unity Fangame Engine - 11-22-14 - Update
« on: November 22, 2014, 02:34:09 AM »
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.

21
Engines / Re: Unity Fangame Engine - 11-10-14 - I Wanna Help the Cat - Pre-Release
« on: November 13, 2014, 04:06:41 AM »
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
httpss://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.

22
Engines / Re: Unity Fangame Engine - 11-12-14 - Information
« on: November 12, 2014, 02:42:27 AM »
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.

23
Engines / Re: Unity Fangame Engine - 11-8-14 - Game so close
« on: November 08, 2014, 03:02:02 AM »
Hmm I feel bad not posting an update for so long. Ive been adding levels and doing minor scripting (a few oddities poped up)
Finally hit the point I figured I need to make my levels look better and I added lightning and shading. Then I put in backgrounds because I was sick of looking at that blue background.
Picked out some music that hopefully isnt awful :p (5 songs)

I think I hit the point where I dont need to showcase any new prefabs and Im at 36 real screens (there are other transition / simple screens that aren't worth counting. Unity says 44 screens total in the build). Sooo, where does that leave things? I am testing right now to deal with any big issues that may arise. Hopefully one of these playthroughs my OCD wont catch something. I can pass the game in ~40mins, so I suppose it would take others longer since they dont know the inner workings of the game.

After I get things settled, I will post the game here for anybody to test. I didn't go overboard on difficulty and hopefully it is "balanced."
This was more of a test on how the engine is working and it brought up a lot of oversight in certain scripts.

After that, the game will be released, then back to engine programming (and hopefully its release sometime thereafter).

Screenshot time. At the start of the week I updated the look of every screen.
Here is a 3xView of the transition for a climbing screen I did.
First screen was simple drag and drop stuff (typical basic guy screen)
Second, is the alternate sprites
Third is the shading / lighting (ya, you can pick up those torches).
(click to show/hide)


Game released
See first post for more information.
https://www.mediafire.com/download/k5r3hnyyp501or0/I_Wanna_Help_the_Cat.zip

24
Engines / Re: Unity Fangame Engine - 10-28-14 - Version 1.06 - 1/2+ of new game done
« on: October 28, 2014, 03:19:44 AM »
Having fun working on the new game except when I hit writers block and cant think of how to design a screen :/
Other than that, doing some lighter scripting. A few objects didnt interact well with each other and I will have to deal with it sometime. I think I have the solution, but you never know if changing one logic will break something else later.

Spike treadmill updated more. Idea is still the same but it spawns the objects using their collider / hitbox (instead of the sprite size) when calculating the spawn offsets. This also makes it easier to place the prefab. Snap the prefab to the ground or ceiling and snap the start / end objects along the ground and the objects spawn perfectly.

Spike chopper script created. Its a simple script that makes an object slam to the ground then go back up. Has options for start delay / up-down speed / etc etc stuff

Started making object spawner script scripts (ie using my super script from a while ago to make secondary scripts extremely easily)
Color change script - Simple script that changes the color randomly of an object it is attached to. Also has the option to set the size of a color vector and set colors to spawn through (instead of randomly picking colors, you can configure it to loop through a specific set of colors. All of this is simply done through the editor). Also can use this vector and change the alpha to make a fade / unfade effect

I had quite a few oneshot spawners in my object spawner script and I created another script + prefab to use them more easily. The short of it is, if you need some object to spawn In a direction / at the player / a wavy line / a random spray / a directional spray / circle burst / single object follower / single object bouncy, you just drop this object into the editor, set the variables, and it works. Can have X sets or just constant spawns.

Reverse gravity (flip character) was added. Was pretty easy to put this in surprisingly. Has a weird interaction when you manipulate the guys stats (ie low gravity / +-speed / jump speed). I think I know the problem and put it on my list but for now, those wont be on the same screen lol.

I updated my time change script. Has options to increase / decrease the game speed over X time. Also has the option to maintain relative speed (ie even if the world speeds / slows, the character will still move the same). I just made a pretty crazy screen using this script, was really simple yet fun.

Im at ~15 Rooms created in the game so far. Not really sure how many more to go. My plan is to keep going until I run out of scripts / prefab (each different type of prefab will get a few screens). Kinda funny the more levels I make, I end up rewriting or adding parts to the script or making totally different one I wasn't planning on. Guess its a good thing though.

Screenshot ... maybe later.

25
Engines / Re: Unity Fangame Engine - 10-18-14 - Version 1.06 - Tons of little things
« on: October 19, 2014, 12:07:18 AM »
Not going to release an updated game this week even though things look different.
Working on making all new maps and dont want to release it with only one completed (screenshot below).

Started cleaning up my list of smaller things to do since I got the AI script done last week.

Added in a game timer and death counter (game timer is only in seconds, no use calculating time every frame and I can change to minutes / hours / days during display later).
Worked on cleaning up the Gamecontroller script to incorporate the new items.
I wasnt going to mess with the file loading screen but I needed to add in death / game time, so I changed a few things.
Changed the File Selection screen to show deaths / timer. The labels and buttons scale based on screen size.
Was hoping the new GUI system would be released from Unity soon, but I shall wait some more.

Secret string added to the Gamecontroller to differentiate between save game files.
- Im not sure if this was the correct way to do this, but previously any save file would work no matter what I would do in the game (ie extremely generic save file)
- Now, there is a secret string added to the gamecontroller that it must match in order to load the data from a saved file.

Added to the Area modifier script to deal with movement speed change and other variables regarding triggering (move speed / jump / gravity / max fall speed / etc)
Searching around and I think I found the settings for water and I added those to the area modifier - water prefab.

Added code to allow for enabling / disabling of autofire.

Updated / redid the Objects via waypont script (used in moving platforms)
All of the platforms prefabs (both jumpthrough and sticky) have been updated and the triggers are more exact.

Added spawn bouncy object to the Object spawner script.

Warp in room script updated
- Warp in room changed to give the ability to keep the offset of enter / exit to allow this prefab to be used in screen-wrapping
- Previously, when the player entered the trigger they were spawned to the exact exit point no matter the point of entry.

Added the spike treadmill script / prefab (you know that, spike goes up / moves across the ground / then goes back into the ground thing)
- Has settings for speed / spike spawn rate. Starting point / Ending point are empty gameobject that can be placed anywhere.
- Can twist / spin the prefab any direction and it will work (ie, spikes going along the ground vs going up the wall is nothing more than rotating the parent object)
- Has the option for the movements to be based off of global / local transforms (global would make it so that the spikes always are facing up while local would be facing up relative to the parent objects current rotations).

Redid scene 3 that showcased the warp in room prefab (Screenshot below)
Those ninja star things spin (bottom middle ones spin along the y-axis and the right set spin along the z-axis)
(click to show/hide)

Previously, each of my scenes showcased a prefab in the simplest of ways. Redoing the room caused me to find an oversight in how one of my prefab was scripted.
So it seems I will be redoing all of these simple crappy rooms and making them a lot more complicated / harder.
My goal is to end up with around 20 screens of medium difficulty
- maybe 2 screen per important prefab
- So 2 dealing with the warp in room prefab, 2 dealing with water, 2 dealing with movespeed / jump trigger, 2 with traps, etc (just to test how they hold up)
- Im sure I might need more screens if the prefab is more complex

Add in the boss I made before and I guess I can release my first game with this engine.

It has been going through my mind that I might possibly somewhat kinda maybe think about getting close to doing a limited release of the engine to those who are interested.
Have been thinking about what I really need to finish up on in the engine. Much of the major items are complete.
Making a game myself using what I have built will give me a better idea.
- Even this week I have started going through and reordered / renamed scripts / prefabs to be more consistent. I also need to comment the scripts better.
- Also making a general use guide will take a bit of time as well (how the engine is setup overall).
- Im not in a hurry, but these are some things going through my mind.

26
Engines / Re: Unity Fangame Engine - 10-10-14 - New Version 1.06 - AI and Stuff
« on: October 10, 2014, 06:18:28 PM »
1.06 Uploaded and main post updated
If you have some time, feel free to download and try out this new version.

Finally put the finishing touches on the ground / flying AI and worked making a few types of monsters prefabs.
- I grabbed a character who had flipping / shooting / walking sprites and used him for the ground AI test (from Majyuuou King of Demons)
- Added a death sprite for the kitty
- Added the Raven from castlevania 4 to use for the flying AI test

Since I had to make a new room to showcase the AI objects, I decided to grab a super mario world sprite sheet and use that (it looks pretty nice and was easy to add). I thought it would be hard to put all the AI monsters in the same scene and I didnt want to make a HUGE room to fit them all in either. I ended up making buttons that spawn the particular monster in the center of the scene when clicked. The 8 clickable options are shown on the screenshot below.

Screenshot of the new AI room
(click to show/hide)

I also added in the Castlevania 4 spinny room I created last week into the game (see previous weeks screenshot)

- Reordered a few scenes
- Im sure there was some other scripting stuff that came up and was changed

27
Engines / Re: Unity Fangame Engine - 10-5-14 - Monster AI Scripting - Week 2
« on: October 05, 2014, 03:17:38 AM »
Was really hoping to get a release update for this week going, but completing all the AI scripts just didnt happen.
Well, I mean they did get finished in the rough sense but I had no time to do some hardcore testing on how well it would hold up in different circumstances. Overall, the air based AI took a bit longer than the ground AI and I ran out of time.

A general overview of what the AI does and the variables that are editable on the gameobject
AttackRadius - Anything less than this distance the scripted object will attack the player. Default attack is a simple "leap at player" action.
PassiveRadius - Anything more than this distance the scripted object will enter in a passive state and start patrolling.
Any gap between the 2 radii causes the object to move towards the player.
Setting these variables would allow for passive mobs / patrolling mobs / following mobs / aggressive mobs / etc just by setting the different radius (dont want it to attack, then set attack radius to 0 / etc).

Has the option to jump up blocks if moving and one is in the way
MoveSpeed - The speed at which the object will move when trying to reach the player

PatrolArea - The distance on either side of the object it will patrol. If set to 0, the object will only turn around when it hits the wall or a drop off is in front of it
PatrolSpeed - The speed of the patroling object. If set to 0, the object will enter an idle state.

Default attack action variables
JumpSpeed - Speed of the jumping object
JumpPower - Jump power of the object
DelayBetweenJumps - The time between jumps

Shooting attack based variables
ShootWhenAggro - Selecting this will cause the object to shoot a preloaded gameobject forward when in attack range (this replaces the leap-at attack action)
ShootAtPlayer - Setting this to true, will shoot the projectiles at the player when in range
ShotSpeed - Speed of the shot
NumberOfShots - Number of shots per set
ShotDelay - Delay between each shot
ReloadDelay - Delay between each set of shots
ShotConstraint - The monster will only shoot when the player is within this constraint (think of it as being in the guns sight range). Being outside of it will cause the monster to move at the player.

The flying monster AI needed to be done in a separate script and took longer than I hoped.
The flying AI is similar to that of the ground based, but movement / dive attack is handled differently. Most of the other code had to be redone to deal with a flying based object.
The generic variables are mostly the same as the ground based AI and not worth listing again.

Finally figured how to reuse the generic animation controller I created (fleshed that out this week also, and I hope the logic holds up). Was able to RIP a sprite, create the different states (idle / attack / movement animations) and plug it into the generic animation controller and the script just made it work. No hassle / no mess. Going to have to go through the other sprites I made previously and update them. It is a lot easier to make fully functioning sprites now.

More coding to do, but I got a lot done.
If I get the AI cleaned up this week, I will try to not start something new and work on making a few maps to showcase the new monster AI types.

28
Engines / Re: Unity Fangame Engine - 9-27-14 - Generic Monster AI Scripting
« on: September 27, 2014, 02:11:52 AM »
Just a post update this week + a screenshot
The time it takes to bundle it up and make sure the game works every week takes some time, and I feel it wont hurt too many feelings if they cant download this every week (especially when the new content isnt very visible in game).

I felt it was time to make a screen via ripping the sprites from another game to see how it goes.
I took the spinny room from castlevania 4.
(click to show/hide)

It worked out fine but it needed monsters so I found a good castlevania sprite sheets and worked on creating simple prefabs + animation controllers for a few monsters (you can see which ones i made in the above screenshot in the lower unity window). Added in random spawn Medusa heads to the map for the section in the middle and it looks nice. Upon ripping the medusa stone shot animation, I added a bit to the GUY script to allow for easier addition of other types of shots.

After making a few monsters prefabs I made a simple AI for one (hopper monster), and then upon doing the next monster I found myself making a separate AI for it. It kind of felt redundant doing this for every monster every time so I started working on a generic monster AI that can be just added to any monster and have variables to set how they would act (more complicated monsters, like bosses, would need made-from-scratch scripts).

I figure I would need a melee type attacker script / shooter type script / and a flyer type script to deal with the basic types of monsters. All of these are tied into a generic animation controller so that the correct animations are selected automatically when the monster does a certain action.

Right now Im working on the basic melee type and have patrolling / move twords player / leap / attack at player all based on AoE range (all have variables that can be set in the editor to tell when / how fast / distance). This still needs a lot of work, but it should be useful later so I wont have to make so many similar scripts for every monster added.

Made a new walking animation for the pixel cat, kinda looks crappy because I did it pixel by pixel myself but it got the job done. Put my generic AI script on it and now i have a crazy cat following me everywhere :p I guess disabling the attack part of the AI makes it good for NPCs as well.

29
Engines / Re: Unity Fangame Engine - 9-19-14 - Legit Cat Boss
« on: September 19, 2014, 06:27:31 PM »
- Game Uploaded and main post updated -

Wasnt sure how much I could get done with being gone, but after I started working on a boss, I found myself pushing hard to get it finished for todays release. This boss uses the object script Ive been working on for the past 2+ weeks and the HP module from a few weeks before that. Its a pretty legit boss, not that difficult (i guess I know how everything works so its a bit easier for me), but it shows that many of my scripts are working well and are useful.

Overall the creation of the boss went pretty smoothly. Some of the combination scripts I recently threw together need a bit more work.
- The boss could easily be a single animated object + any number of projectiles, but I wanted to stick 100% with using my object script
Screenshot of the boss
(click to show/hide)

Boss Info - This is how the boss was built and acts and thus contains spoilers.
Id prefer you test out the boss before reading what is below, but I know some are not interested in downloading a work in progress every week.
(click to show/hide)

30
Engines / Re: Unity Fangame Engine - 9-XX-14 - Weekly Patch Delay
« on: September 08, 2014, 03:59:43 AM »
So that script from last week, ya, Im still working on it and its bigger and stronger than before.
I feel there is no real reason for me to upload the new "game" because it would look much the same.
Also on the same note, I will be gone this week for 5+ days (away from my computer :/). Im not sure what I can get done, but Im hoping to rework all of the screens soon to be more legit, like a game. Maybe the release 2 weeks from now that will be a reality.

- Minipatch notes
Added a nice color changing of the projectiles. Nice smooth transitions too, not the swap X object that is a color with Y object of another color. Of course unity did not like the default red apple because it tints and color change the existing color (was like shades of crap and brownish crap). Made a simple White Apple and colors look wonderful.

Simplified coroutines / combined some of them / made functions to call the coroutines / overloaded the functions for user simplicity.
Made a 2nd script that uses the first script function calls to create multiple of these objects and manipulate them on the screen.
It worked out well, simple and clean.

This is a simple scene I made (just for testing some things). If your into this type of thing the copy / paste code is below
Multiple objects being manipulated independently based on time.
Also, since this object in created in a function call, it too can be called on a timer using the "invoke" command (a simple way to subdivide animations).
(click to show/hide)

hmmm Maybe a new screenshot - I think I can handle that
Running the game through the editor - Those pretty shapes :p
(click to show/hide)

Pages: 1 [2] 3