Saturday, June 8, 2019

HBV Microbe Pathfinding Script

I thought that using a way-point system would be ideal for HBV particles to navigate arteries, because at the time, it seemed to me that setting up collision volumes for the arteries would be a nightmare. I then thought that a navmesh could work, if I generated the navmesh geometry along the artery curves in Houdini. This would be ideal for a top-down game, but not any other type of 3D game, especially in VR, if the HBV particles can only move along 2D axes. So, I'm opting for a more natural method of path-finding--using ray-casts to detect the walls. I found a way to achieve 3D path-finding using ray-casts. This would be ideal for a space shooter, or microbe game where there needs to be multiple agents navigating and floating around. Some sort of simple way-point system could still be useful in conjunction with ray-cast path-finding for the viruses to navigate through the arteries. I realized that setting up collision volumes isn't going to be nearly as tricky as I originally thought, as long as the collision volumes are large enough and close enough to the arterial walls for the HBV ray-casts to detect them, and the ray-casts are long enough.

There are sections of code commented out because they are non-functional, or used for testing. The script is still under development, but it lays a foundation for a microbe path-finding system for my Master's Thesis game. It is unclear what exactly my thesis game will be, but one thing is for sure, it will concern an environment of blood vessels to be traversed by hepatitis microbes via path-finding.

This is what I have so far:


As you can see, the HBV particle avoids collision meshes in order to reach the goal, the cube. In the script, some of the commented code is for alternate raycasts that are cast on all sides of the HBV particle instead of in front. The ones in fromt are ideal for avoiding walls, but the ones on all sides may be ideal for avoiding other particles, additional testing is required to determine this.

Here are my scripts:



Saturday, May 25, 2019

Visualizing Paths between Waypoints, Having Agent follow Path on Navmesh

I fixed an error in my code from last week. I changed "UIStart" on line 58 in "AIWaypointNetworkEditor" to "UIEnd," a simple fix. Now, when the "Display Mode" drop-down in the inspector is changed to "Paths," we can see a path drawn in yellow from the two selected way-points.




The agents now move from way-point to way-point, in order, beginning with way-point 0, then continuing down the chain. The ones that started away from way-point 0 move toward way-point 0. The local avoidance system is working, so that agents traveling along the same path do not collide with each other. The navmesh is used to calculate the optimal path from way-point to way-point.

Here is the new NavAgentExample script from this week, for getting the agent to follow paths between way-points via the navmesh:



Work on this will continue next week.

Saturday, May 18, 2019

Unity AI: Baking Navmesh and AI Waypoints


This week, I fixed the enemy character's AI. It now pursues the character and fires at random intervals, as it it supposed to. I want to make this a soldier character. The script is currently set to fire at where the player was a moment ago, rather than constantly be set to fire at where the player is every frame. I think that there is potential to develop this into an interesting game where the player is a superhuman character that can easily avoid the shooting reflexes of well-trained soldiers.


More importantly, I got into using a navmesh, setting waypoints, and programming in the Unity Editor. Learning to program GUI in the Unity scene view can be useful for creating tools for game development. This particular tool let's us visualize the pathways between waypoints that the AI character will be navigating between while on patrol or finding/pursuing the player character. The pathways are not where they should be because the editor script is not finished. I think that using waypoints to move AI agents through 3d space can be desirable. Depending on what I do, I may use this in my thesis game project. When this is done, the red box character should be able to navigate between the buildings to find the player.


Here is my updated code below:










Sunday, May 12, 2019

I did spend a substantial amount of time this week learning about Unreal C++ programming and Unreal's API. However, I have made the decision to focus solely on Unity C# for the remainder of my time at Drexel. I'm beginning to learn about coding AI for games in Unity 3D. Below are the scripts I wrote this week for programming a simple AI to attack and shoot at the player, while also remaining a certain distance away. I may build upon these scripts in future weeks in the scope of this course.

The first thing I did was begin coding a very basic 1st-person character controller, to be built upon later:


Next, some very basic enemy AI that pursues the player when the player gets withing a certain distance, shooting at the player. It will also stop advancing on the player when it gets within a certain distance, and even back up if the player gets within a certain distance of it.


Lastly, is the enemy's projectile shooting script, which will be built on later:


Sunday, May 5, 2019

Week 05: Jumping Right into Unreal C++!

Making the switch from Unity C# to Unreal proved to be very challenging, like learning an alien language. Sure, Unity and Unreal are both modern game engines that do almost exactly the same thing. The arrangement of their interfaces (in terms of graphical UI) are almost identical. The main difference is that one engine is for making high-end games, the other one is for making low-cost, low performance games. C# and C++ are both derivatives of the C language, so one may assume that making the jump from Unity C# to Unreal C++ is very easy. It is not. Unity C# is very minimalistic, all the programmer needs to do is write some include statements, declare some variables, and maybe write some functions. A newly created script in Unreal C++ comes with more moving parts right out of the box, already integrated with the engine, and requires more use of C++ syntax that is not required to create a script in Unity C#. Overall, coding in Unreal C++ has more complexities that Unity C# does not have.

That being said, I have no tech demo available for this week. I have merely managed to make a game object move in four directions, forward, backward, left, and right. In future weeks, I will focus on creating a more elaborate character controller, and perhaps moving NPC characters, and scripted events in a game environment.

Here is my code.