Jump to content

Interesting Title Goes Here


McJobless
 Share

Recommended Posts

I'm going to ramble for a bit; if you're looking for a game, piss off and come back in 6 months or more.

 

This is a progress log/diary for a little something I'm going to start doing. I'm going to keep coming back with information and screenshots whenever I make something happen. Read on for more info.

 

So, I'm always ripping on other fangames...I guess I need to go ahead and prove my worth, huh? Before I start on what's going on, let's get a few thing straight. Either read the spoiler if you intend on posting, or be labelled a twat forever-more.
 

Spoiler

 

1. I've fallen out of touch with ye olde LEGO game modding.

When it comes to modding, what I want to do is see how far I can take a game's engine, and try implement crazy new ideas. Sometimes, tight rules and limitations make for a refreshing challenge, but that's simply not the case with something like LegoRR. I don't like RTS games, which means that I'm not capable of building challenging levels that match the gameplay style, and G.O.D.S. simply lacks a lot of features I would have liked in order to turn the game into an Adventure game. I'm also aware that the amount of people with copies of LegoRR is dwindling, and that says nothing of people who can actually run it without issues (I have to use a VM nowadays).

 

I own many of the other LEGO games, but as far as I'm aware, they either lack enough tools/content for me to fiddle with, or they're too restricted to do things I want to do. Even the Tt Games are not of interest to me; they're fun to poke around, but about the most complex thing we can do is create new characters that have to share animations with other characters.

 

2. I've got a lot of work in the next 5-ish months.

These are absolutely my final two college terms, come hell or high water. One class is easy, but Character Design will be a dedicated amount of work since I'm behind everybody else in terms of skills (really terrible at art). I also will be going out to find work, since I need money and an out-strategy post-college. This project isn't here to be work; it's a hobby. If I want to quit, I'll quit. Because this is a hobby, the idea is that I'm doing this to include more work on my portfolio, improve my skills, and ultimately let off a little Steam whenever my "real" work is frustrating me. That may mean I make decisions that are best for my portfolio, but not necessarily for the end product.

 

3. I'm not the best programmer.

I'm still relatively a newbie. The other day when we were diving into some LEGO MMO code (LeoRPG, look it up), there were many elements I couldn't understand (and it's not just because the code was badly written). It's going to take me longer to achieve something things than others, and I may occasionally need to restart so I can do things better. That's okay. I just don't need people making unrealistic expectations of my work beforehand.

 

4. I'm not building a game to sell.

I'm fully intent on just making something. I'm not ready to sell games yet, and it probably won't be that way for a while. That means I likely won't be thinking about polish or the amount of content; I'm really just trying to shovel in ideas that I want to be able to make. This also might mean that if there is a final, public release, it's absolute garbage. Don't say I didn't warn you.

 

 

Now that's all out of the way...McJobless, what the f**** are you doing?! That's a great question, and here's the two phase, idiotic and baffling plan that I've been thinking about for a while.

 

 - WHAT AM I DOING -

 

Phase 1: Make a "World of Mechanics"...

I know it sounds absolutely ridiculous, but carefully follow along. The first goal of this game is to practice programming game functionality. The best way to do that? Copy other games!

 

That might sound a bit cheap, but hear me out; every game we have today is built off the backs of the work from those before us. You couldn't have Halo without Wolfenstein, and even World of Warcraft has roots in Chess. Learning to read and implement previously made mechanics is a fantastic way to experience the process of making them from scratch; the difference is that you have a very clear, replayable example of what you want to achieve that you can study. You look for all the tiny rules, bits of polish, and even try making changes and improvements.

 

There's one game I've wanted to remake the mechanics from for a long goddam time. That's my favourite game, Ratchet & Clank 3: Up Your Arsenal. The game has a wonderful mix of third person shooting, platforming and puzzles. The actual mechanics that go in to these games are small, manageable pieces that link into each other, which is great for learning and playing with Object-Orientated Programming. Just today, I sat down and jotted down a page worth of work on how I'd organise the various weapons, gadgets and enemy items in a hierarchy of objects.

 

This will not be easy, it will take a long time, and there will be a lot I don't attempt or give up on. For example, I will likely not try and code Ratchet's animation system, or the Plasma Whip's physics system. I also imagine I'll give up on the Tyhrranoid AI at some stage (in a developer commentary, Tony Garcia noted that he developed a pathfinding system called "Seeker" that handled most cases without hardcoding), but the important thing will be trying. I have a lot of resources at my disposal; multiple versions of the game with multiple saves spanning different levels, the PS2 emulator, YouTube Let's Plays, the Developer's Commentary, the Wiki and much more. It's just a matter of getting to work.

 

If you asked me; the ultimate goal of this phase is not just to straight rip Ratchet's mechanics, but to start building a library of mechanics from multiple games which I could turn into generic libraries that I could import into future projects. I'll likely start finding other games that I might want to borrow mechanics from (such as KotOR's dialogue and reputation systems), and I might even come up with my own stuff to build (I want to really refine my own localisation system I've built).

 

Phase 2: Make a LEGO Game with those mechanics...

Here's the real knife twist. I've blabbed on a lot about how much I don't think anybody else has made a good "LEGO" game. Maybe I should prove I can make one? It'd also be nice to actually create a decent LEGO fangame, since that side of the fanbase seems to be lacking...

 

I'm not making any plans for this before I know what mechanics I have at my disposal. The idea here is that I can switch entirely to design, pick some mechanics I think would be a good fit for the LEGO values, and then start producing something. I'm not expecting anything amazing from an aesthetic perspective (I'm not an artist or an audio designer, mind you), but so long as I can nail the game from a mechanics stand-point (and maybe even throw in a half-decent story), I'll be content.

 

Now, this phase is the one I'm really not putting any expectations on. I may not even get here in the long run. It's just a long term goal that's supposed to get me motivated and practising for what I can do. At the end of the day, I may go on to make my own game that I can sell, but I don't see why I should discuss it this early on. This is just another far and off goal to think about it amongst the other work.

 

- HOW AM I DOING IT -

 

Well, this is essentially project start, but it's not like I'm completely empty at this point.

 

I've already produced the basis for one mechanic in Unreal; there's an enemy weapon that's used frequently in the game which spawns a large number of missles around and at the player from the sky. The issue I have with Unreal is that...it's not that great for my purposes. I have no clue where to start with the C++ intergration, and Blueprint is just too painful to go back to after months of working with typed code.

 

That's why I'm now jumping to Unity; I reckon that if I can really push my C# skills, it's going to make the eventually planned transition to C++ a lot simpler. C# might lack constructs like pointers, and may have additional features like Lists, but the logic is really what I'm testing, and at the end of the day it's much closer to C++ than other languages.

 

I'll be starting with the weapons. They have shared properties, so I can develop a class structure, and each weapon has its own unique mechanic to deal with; there's nothing super complex, but interesting little challenges that will take some time. I also figure that I can build these items without player interactions just yet, and I think the player would be a very complex system to deal with (and I don't plan on using Unity's prefabs; I need to learn how this stuff works for myself).

 

The good news is that the weapons have pretty particle effects, and so I'll be ducking into shader code at some stage; that'll hopefully make for some pretty screenshots. Because I have access to services like Mixamo, I might just be able to put in some rough animations and other polish to better help my work, but I'll consider that kind of stuff low priority.

 

Any time I make headway, I'll post here and on the Blockland Forums. I'll also be posting code snippets for the experienced coders to pry and laugh at, and the young coders to learn off. I'll do my best to comment. Screenshots and videos will be a must, as that forces me to produce more and work harder.

 

- WHEN DO I START -

 

Well, it won't be bloody tonight, I tell you that much. Since this week is preloaded with the Disney-Pixar Masterclass and my overdue Character Design homework, I'll hopefully start on Monday afternoon with a simple weapon, such as the blasters or shotgun. Feel free to nag me about working on this more; I'll need it.

Link to comment
Share on other sites

Fluffy Cupcake
1 hour ago, McJobless said:

Either read the spoiler if you intend on posting, or be labelled a twat forever-more.

  Hide contents

It's going to take me longer to achieve something things than others

 

I have just established my proof of read.

;P

Link to comment
Share on other sites

Lind Whisperer

...since I'm behind everybody else in terms of skills (really terrible at art).

Look up Mark Crilley -

https://www.youtube.com/user/markcrilley/videos

, or

http://www.amazon.com/Mastering-Manga-Mark-Crilley-drawing/dp/1440309310

. You'll be glad you did.

 

I'll be looking forward to seeing what you make. I can't promise anything - my own next few months/years are quite full as it is - but, if the right time presents itself, I'd love to help work on modeling/building/design for some sort of game*.

Spoiler

 

23666457799_a187f508b9_z.jpg

24893776206_fd64e41851_z.jpg

 

 

 

*#thatspacegame is still in progress, but...life.

Link to comment
Share on other sites

  • 2 weeks later...

So, it's time to talk about some of the initial design challenges of this project. Because I've been carefully planning out my work before starting, I've realised where a lot of difficulty will lie. Firstly, here's an overview of the code classes I've planned which I think I'll need. Right now, this is only for ACTOR types (i.e. objects that are spawnable in-game).

 

rqWGHkO.png

 

That's probably very complex, but keep in mind that it's not finished. There's still many scripts I need to plan out for specific world objects, and I haven't even detailed the System/Data scripts yet that handle all the behind-the-scenes code. For the time being, there's some key things I want you to look at:

 

Issue 1: Splines & The Grindrail Problem

A spline is essentially a "curve in 3D space", In laymen's terms, it's an invisible line that another object can follow. These are frequently used in applications like Cinema 4D or Maya to make certain characters follow a specific path when they're animated, but lines themselves are also used in 2D programs like Illustrator to make text flow in a specific direction or what not.

 

Default Unity doesn't have support for Splines like engines such as Unreal. This isn't necessarily a bad thing, except for the fact that the Ratchet & Clank games use a lot of them to define how different objects get from Point A to Point B. The good news is that making a simple spline should be easy; the Spline class will require several Vector3 "points" that form your line, the speed that the object should travel and the object that is attached to the spline, and then the code will just interpolate the "attached" object between each point once it's triggered. That's simple, right?

 

Well, it gets complex with Grindrails. In Ratchet & Clank, there's a rather famous mechanic called "Grinding", where Ratchet jumps onto a hard edge and will slide across it until he either jumps off, reaches the end or is forced off. Grindrails are allowed to defy gravity, and the player is often required to jump between two adjacent Grindrails, which plays a special animation and attaches Ratchet to the second Grindrail with the same speed as he was originally going. The issue comes with the fact that simply interpolating Ratchet across a spline (which are used for rails) will prevent the player from being able to control Ratchet's speed, direction and jumping, and it will also stop Ratchet from making the appropriate jump animation when he is hit by enemy fire while on a Grindrail. Since this is a major mechanic, it needs to be addressed.

 

The solution I'm proposing is "Movement Modules"; these are interchangeable classes that handle specific parts of character movement. The idea is that the Grindrail Movement Module is built to specifically interface with the Spline class and can pass/receive data from it in order to make additional judgements about how Ratchet should move. For example, if the player presses forward, the Standard Module would move you forward and play a specific animation, while the Grindrail Module will simply increase speed. Similarly, the Grindrail Movement Module could interrupt and freeze the Spline's interpolation functionality if Ratchet freezes or cancel it if Ratchet is jumping off the rail.

 

Issue 2: Seeker

Tony Garcia developed the Seeker system supposedly to solve a lot of issues with Ratchet & Clank's AI design. Specifically, each level had an entirely different AI system coded specifically for it. Seeker was supposed to be a nice generic AI system that, with a few hardcoded scenarios, could handle most problems. The issue for me is that...I don't know what "Seeker" is. Instead, I've decided to tailor Seeker to what I think I'll need, which is a condition-evaluation system.

 

What I'm specifically getting at is that there will exist an enum with a list of possible events. While AI units can individually make judgement calls on small items (such as "Is there an object directly in front of me that will prevent me walking forward?"), every time an AI unit completes a task it can pass back to the Seeker class. Seeker will then determine (for the individual AI calling it) what condition that AI is in, and return the enum value. Each AI unit can then act according to the enum it gets back.

 

Obviously, I've never programmed AI before, so this is probably way off from a correct solution, but I think I'm on the right track. Theoretically (in my mind), an AI works by sorting through tasks; it completes or cancels a task, evaluates what further works need to be done, and either gets a new task per conditions or then defaults to an "idle" state (which in my framework would be taken from the level, as AI in some levels might need to act differently to other levels when they have nothing to do). Each AI can handle collision checks and basic avoidance locally on a frame-per-frame basis, but since some condition checking might be really slow, it'd be good to only do that when we really need to.

 

The one issue I've thought about is pathfinding; I assume this is the hardest issue of any AI system. My idea is partially derived from Unreal; the developer can place collision volumes that are keyed to a specific "Channel ID" which AI are linked to; when an AI unit or Seeker is preparing tasks, they will lock all their tasks to inside the relevant collision areas. For example, if an AI unit wanted to move to get a better shot at the player, they would need to choose a random position that isn't just clear of an object, but also falls within the valid collision spaces.

 

One condition I've been considering is "What if an enemy was to move outside their valid collision areas?". Right now, I think the easiest solution is to kill them; this could potentially solve enemies getting stuck below the ground or out of an arena preventing the player from continuing forward. It's something to deal with in the future, however.

 

Issue 3: Multiplayer Replication

One concept I haven't even considered yet is Replication; i.e. the ability to replication objects and data on multiple connected clients. Ratchet & Clank 3 has an Online, LAN and Splitscreen Multiplayer mode, and while they're not the real meat I would assume most players and developers would be interested in making a multiplayer shooter out of the Ratchet mechanics. This mode was in development for the full length of the Singleplayer campaign mode (I'm fairly certain), and while this is rough speculation, I'd guess that a lot of it was written using adjusted Ratchet & Clank 2 code. That's not a bad thing and it doesn't change much, but multiplayer in general means special considerations need to be made.

 

One thing to consider is how much data is being transmitted every tick (a tick is a single send-and-recieve transmission of data between a client and the host, which are measured as ticks per second in the form of Hz; i.e. Counter-Strike: Global Offensive uses a tick rate of 64Hz). If you send more data than either the incoming or outgoing bandwidth can handle, the latency increases and this causes lag, which all know too fondly and which we all want to avoid. That said, if you only pass critical data (like position and what weapon the player just fired with), you can start having problems where the players exist in two different versions of the world. Ratchet & Clank 3's multiplayer maps feature some dynamic prop elements, including the standard crates, bridges which can be destroyed for a tactical advantage, and the worst of all, AI.

 

There's a lot of issues in networking with reference to security. For example, if you allow every client unrestricted read/write access to replicated data about a player's health, any client could cheat and change that value to be more or less. A lot of data replication involves read-only values, and the host handles most processing to keep things fair. This is where the big issue is; what is Ratchet & Clank 3's server model? How is a fair Host decided, and what data is allowed to be replicated? In the example of the bridge destruction, is the entire animation state replicated over network, or does the client simply get a message that says to destroy the bridge? What happens when a player joins the game after the bridge is destroyed and misses that message?

 

I've worked with networking in Unreal, so I've got a few solutions under my belt, and Unity does have a giant chunk of Networking-related functionality built-in, which means that all I really need to do is sit down, plan it out, and actually play a few rounds in the real game to see how the model feels in the real world.

 

Issue 4: Spherical Worlds (and the Grav-Boots)

Referred to as such by the Ratchet & Clank developers, this physics anomaly is like a much smaller scale of the Earth. Almost all video game levels are planes with elevated or lowered terrain, and this is usually the ideal design approach as it makes physics calculations simple since jumping and weapon projectiles don't need to adjust to the curvature of the terrain. This doesn't apply to the Spherical World levels, which will likely make me rip all my hair out.

 

Before we get onto Spherical Worlds, let's look at the Gravity Boots and metallic surfaces. The Ratchet & Clank games have several unique paths that require you to use the Gravity Boots; these allow you to remain attached to the metallic surface of a path even if it means you'll be walking upside down or in other weird configurations. It sounds simple, right? Just turn off the "Affected by Gravity" property of a character's physics component. This, however, causes an issue: Ratchet & Clank supports double-jumping. Even one jump is an issue, but two? In Ratchet & Clank 2, the solution was to disable jumping. In Ratchet & Clank 3, the player could jump once and still snap back to the metallic surface. In either case, if the player leaves the metallic surface in mid-air, the game will attempt to right them before they hit the ground.

 

None of this is simple, but it's not impossible either; just a lot of tweaking. The problem I'm most worried about is more present in Spherical Worlds, however; as I mentioned above, when you have a spherical world, projectiles need to defy gravity and remain attached to the curvature of the terrain. This also means that lazers need to bend into a curve. Unique to Spherical Worlds is that every object cannot fall off the world, no matter what point of the world you stand on.

 

Thankfully, I'm not the only one who has dealt with this challenge; there seems to be a few tutorials and example code bites which I can learn from where people have grappled with similar problems. I'm certainly not looking forward to it, though, and it seems like the Ratchet & Clank developers didn't enjoy it very much either.

Edited by McJobless
Forgot to add some detail about a fourth problem.
  • Like 2
Link to comment
Share on other sites

It's great to see you are planning ahead.

Most immature people, like myself, would dive into a project and when any issues cropped up we would not be prepared to face it.

 

 

You haven't just decided to work on mechanics over aesthetics in the first stage, but you are looking at potential issues before you even begin work, and calmly thinking it over until you reach a sane solution. This is clever.

I can tell that this project is in good hands, and I sincerely wish you the best of luck with this.

 

--Ben24x7--

  • Like 1
Link to comment
Share on other sites

Dazzgracefulmoon

You have a better mentality than a lot of big budget kickstarter projects do, but I'd guess that's also to do with the fact that you don't think that throwing money at it will solve everything. While your project might not be anything completely astounding, it's nice to see that you have a very logical mindset about this.

(also ratchet and clank 3's my favorite PS2 game of all time so I'm always intrested if there's any vague inspiration from that game)

Link to comment
Share on other sites

  • 2 weeks later...

So, as part of an interesting challenge for myself I've been working on my own little AI system:

 

c6c395da7f3a67207cfba589621b4a0e.gif

 

Quote

So, you might be going, "Ben, that looks f****ing stupid and probably fake you lying c***. How the f**** is this thing an AI?" Well, I didn't study AI systems at all, so I've just been working completely from scratch on a concept I've had in my head. I'm going to study AI algorithms soon, once I feel like I've reached a point where I need help.

VacBot, the cute little yellow cube, is based on this task-based system I've been working on. Aside from the fact he's extremely simple (he can only move forward and left), he also doesn't yet implement all the functionality I want for my AI system, but right now the way he works:

1) On the first update, he gives himself a task to complete ("Move Forward", assigning tasks will later be completed by another system).
2) Every task returns a bool on if it's complete or not (for example, Move Forward will only be complete if he's reached the end in this instance), and Task Manager uses the return value to say if we need to re-add the task to the task list so it can be processed again.
3) Every time we do a Move Forward task, a simple raycast is done in front to determine if there's an obstacle. If one is detected, the Move Forward task returns false and instead manually adds the "Clear Obstruction" task to the list.
4) Clear Obstruction performs a move operation to the left and then does three raycasts to determine we're not touching anything. I'm using only three because this example means he's only ever going to be going forward.
5) When Clear Obstruction finally stops repeating, the system will auto-assign Move Forward to the task list, and the cycle continues until it reaches the goal.

This thing is AI because it's dynamic. I can add as many obstacles as I want at any point, and he'll (almost) correctly handle that. There's a LOT of work to go from here, but I'm super happy I got the basic roots of task-based AI down (using delegates, since Unity/C# don't support function pointers).

EDIT: Should be noted; the task-list is a stack. The idea is that higher priority tasks are added at the top and completed before lower-priority tasks. In the end I'll likely change this, but the behaviour is working well for now. I'm also using single-parameter delegates for my tasks, although I will likely change this to be zero-parameter, instead using class variables where possible. I'm still working out the semantics as I go.

 

The Seeker-system isn't yet implemented, but this is good progress given that I've never touched AI systems and never had to design something this complex before. I'm super excited by where this will go in the future.

 

As another note; a lot of things have to change within my plan, but that's good. There's a few unnecessary classes, but also a lot of missing ones. I'll be posting updates in the future about the implementation plans.

  • Like 2
Link to comment
Share on other sites

So, this post is going to be less about new contributions, and more about some additional theory and explanation. I've learnt and discovered some stuff, and I also want to clarify some of what I've written.

 

>PROJECT GOALS<

 

I want to make it clear that the goals of this project have probably shifted, the more that I get to work on the thing. Originally, the idea was that this project would be a "World of Mechanics", so to speak, and that I would be building a library of different mechanics from which i could build new games with. I'd also be producing a LEGO fangame towards the theoretical end (whenever that's supposed to be), using the library of mechanics. Very clearly, this has changed.

 

The more that I study Ratchet & Clank (and various programming AI systems), the more that I realise a few things:

  • Ratchet & Clank 3 is a MASSIVE game. We're talking hundreds of subsystems working together, with thousands of very specific, careful design decisions to ensure a smooth experience. There's such a workload, I'm simply can't see myself replicating other games in the near future.
  • The other Ratchet & Clank PS2 games are so close, I can implement them as well. At least, all of their gameplay elements; there's minor tweaks made to values, some new weapons and gameplay features, but there's no sweeping overhauls and even things like the AI act fairly similar. I might as well just stretch for the first 4 since there's not much additional work compared to the output.
  • This franchise is so goddam interesting from a development perspective. I never expected the kind of things I'm seeing in this franchise and that's what's keeping me motivated to do this "project".
  • I'd like to try and see what it would take to fix the things that bug me. There's no doubt some problems with these games, and it'd be interesting to see if I know how to resolve them.

Now, I must stress; my goal at this point is not "remake the Ratchet & Clank games for the PC". I don't have the graphical or audio assets, let alone the rights to use them, so the experience would only be a third complete. The goal I have so far, however, is to produce a nice framework of the Ratchet & Clank franchise mechanics and systems, for my own learning. I feel like building a public framework, even if I never complete or if it pales in comparison to the actual products, would still be a great boost to my experience and look attractive to potential employers.

 

I doubt I'd turn these mechanics into a LEGO fangame at the end, but it'd be pretty cool to take the knowledge I have from this experience and put it into another type of game.

 

>AI SYSTEMS<

 

So, in my last post, I talked about AI in very general terms; I didn't really explain how AI systems worked or what the end goal for my system is. I'd like to delve a little deeper and break everything down for you guys.

 

THE BASICS

Artificial Intelligence is a massive field spanning many extremely intelligent scientists and programmers, and while real life AI is a very intense field, video game AI tends to be a little bit simpler to process. AI for games is about developing characters or entities that contribute to a player's experience. Specifically, Game AI have two important components; they must be able to perceive the world around them, and they must be able to dynamically respond to the world around them.

 

Now, depending on who you ask, AI is generally designed as Finite State Machines. Some will disagree and say that FSMs are part of the AI but not the design itself, but I digress. If you're not familiar with state-machines, you can think of the simple example of a light bulb. A light bulb (without a fader or similar) can only be ON or OFF. These are two unique states, and they both have a transition into each other (the surge of power as the light comes on, or the opposite as it goes off). A state machine is essentially a selection of "states" of an object, and the rules about WHICH states they can transition to, and HOW they will transition. State Machines are generally interpreted as if-else statements or switches in code. As a note, the fader I mentioned above would not be its own state; it would be a variable of the ON state; the light is still on, it's just displaying less light in the atmosphere. The point is that different states are usually about the behaviour, not the appearance.

 

While this is not an exhaustive list, AI tend to have a few states, including an IDLE state, an ATTACKING state, a MOVEMENT state, a SEARCHING state, a RETREAT state and a DEATH state. Each state can transition between each other (except DEATH, which commonly is the end point before an AI unit is removed from memory), and they all have a set of behaviours which differ from other states (for example, an IDLE state might just be to play some idle animations, while attacking involves shooting a gun). If you were to play a game now, you can probably yourself determine what states the AI exist in, and might even be able to pinpoint the second that they change states. If you're really clever, you can probably even determine the factors that allowed them to change state.

 

Another consideration for AI is the system itself; you can either make independent or "hivemind" AI. Hivemind AI are AI units that think and act as one; a controller takes in sensory data from all the units and the world, and then broadcasts to all AI units the actions to be taken. This is commonly the AI type used in RTS-style games, where you have groups of units working under a leader. Independent AI, on the other hand, each have the ability to sense and act based on their individual context. This lends itself to multi-threading. Years ago, computers were only capable of running a single "thread" at a time, which is basically a chunk of work that the computer must do. If the computer can only do one thing at a time and you have a lot of AI units, it can take an extremely long time to process everything and the game would run slower. Almost all PCs of today support multi-threading, whereby using multiple CPU cores and special techniques (such as hyperthreading), we can basically multi-task and speed things up.

 

PERCEPTION (SIGHT) AND PATHFINDING

I mentioned perception; many intelligent Game AI have the ability to "listen" to player sound and even touch or taste, but the main perception we refer to is sight. Most of us know of terrible stealth games where once the AI sees even the smallest slither of us, the alarms blare and our cover is blown. Sight has forever been the leading sense of our Game AI, and it's very closely tied to the problem of pathfinding. I'm going to attempt to explain how both conceptually work.

 

Firstly, let's talk quickly about sight. In real life, we have these things called "eyes", which read in light data for our brain which processes and then "displays" it to us, in the process unconsciously recognising the elements that we see (for example, you know that you're looking in front of a monitor and you know that thing below your hands is a keyboard, but you don't physically think that, it's all unconscious thought behind the scenes). We can't replicate this process for our Game AI, because the physical rendering that you see isn't technically "real" per say; it's the result of a bunch of maths from all the game logic which is sent to the video card and turned into images on our monitor.

 

Game AI, and everything else in your game world, are just bytes in memory. If you're somebody who programs or has studied how computers work then you likely knew that, but even if you didn't you probably can already see the challenge we face; how do I make a bit of data "see" other bits of data in this false world?

 

The good news is that there's a heap of solutions. We can keep track of the positions of all game objects in the world, both on the object themselves and in separate arrays/lists that the AI units can refer to. Using math, we can compare the position of all objects in the scene against our AI and we can also compare our AI unit's rotation, to see if they're facing the right way to see an object. We can also use a thing called "raycasts", which basically makes a fictional line from a point (in this case, our AI unit) out into space (until it reaches a specific length), and if the line hits anything on the way, our AI unit is told what it hit. Either of these are valid solutions, and generally you use both depending on the circumstances.

 

Pathfinding refers to the ability of the AI to go from Point A to Point B in your world without colliding with anything else in the process. In a game with nothing but flat-space, it's not a terrible issue, but in most modern games, there's so many objects littering the world (such as fountains, steps, rocks, crates etc) that our AI can very easily run into an obstacle, and we end up with something like this:

 

into-wall.gif

 

You've probably seen this issue in a game before. The problem is that, as we discussed before, AI can't really have eyes, and therefore they don't have any way to actually perceive what's in front of themselves. While we can see what's around us, actually moving without bumping is a new issue. Let's have a little thought experiment here; how would you move around in the scenario I posted earlier?

 

Vnpy6Wt.png

 

Even in such a basic scenario, there's still a multitude of choice. Some brilliant minds have laboured at the problem, and there's a variety of solutions. The general rule of thumb is that you want to use a combination of these to solve different kind of problems, but here's just a few that you could use:

  • Crash & Turn: The simplest system is to simply point an AI unit towards the destination. If it hits something, rotate it in the direction that's closest to the target that doesn't point towards the obstruction, and if that's not at all possible, simply turn in a random direction. Move forward and continue until you reach the destination.
  • Forked: Move towards the target until you reach a fork in the road; go a random direction and remember that the fork exists. Keep doing this until you reach the target or meet a dead-end, at which point you go backwards to the previous fork and try the other option. If all paths are exhausted, quit.
  • Node-Based: Similar to above, except the pathfinding is done before the movement. The AI unit uses an algorithm (such as the blitzing fast A*) to find the quickest path from A-to-B, and once it's located they follow that path. Depending on the programmer, you may choose to re-evaluate the path every once-in-a-while to check for dynamic obstructions (such as other AI which might cross your path or the target moving), or you can simply let the AI unit go until it reaches the destination and then evaluate a new path.

The last one is called "Node-Based" because the algorithms that were designed (about 8 of them in total, likely more) all work by utilising these things called "nodes". A node is essentially a point or space on your game-map. Nodes can be laid out like a grid, a tree hierarchy, or in any way that you desire. From our examples above, RTS games tend to use grid-based nodes, while FPS games will use a tree or linear node system. Furthermore, nodes and certain parts of the pathfinding process are precalculated during the game's development in order to reduce the amount of work the final game does.

 

Part of the pathfinding development process is to remember that Game AI shouldn't be perfect; the hard part is to make the AI realistically flawed. This is why pathfinding systems usually include some form of randomness and errors, and AI are allowed to drift from the straight lines that our pathfinding systems generate.

 

MY SYSTEM

So, now comes the point to explain what my solution is, and how I've interpreted the needs of the Ratchet & Clank game's AI system.

 

To me, AI works a bit like you parents when they hand you a list of chores; you'll be given a task at a time, you go off and do those things in order, unless something more important comes up. Now, each task has its own sub-tasks (for example, in my house doing the laundry requires you take the washing down off the line, fold the washing, put it in piles, place the piles in the correct rooms etc). AI has a set of tasks as well, although we typically think of them in terms of state behaviours, as I mentioned above in the FSM talk.

 

Ratchet & Clank have a few theoretical AI types; idle, follower, standard and patterned. Before I explain them, just remember that these are theoretical, meaning the physical implementations of these don't need to strictly follow these rules; they're just my idea of how the AI might work and how I might categorise AI.

  • Idle AI as basically what it says on the tin; they can react to the environment (such as the Q-Force in the Command Deck of the Starship Phoenix as they talk to each other) but they don't really move or die. They still count as AI because they parse incoming data and can make decisions in order to choose while Idle animation and what sounds to play.
  • Follower AI are stuff like Skidd in the Aquatos escort mission or the Troopers on the Phoenix; they exibit IDLE and MOVE states, but they can't die or attack. They're generally background pieces and don't really interfere or interact with the gameplay. They still need to parse input in order to avoid enemies/the player/other obstacles while moving, and decide which position they wish to walk to. That said, they likely FOLLOW a preset node-path.
  • Standard AI can exhibit upto 5 states (IDLE, ATTACK, MOVE, RETREAT, DEATH) and represent the bulk of AI you meet in the game. I say "can" because each unit differs; there's actually only a few units that retreat, and some enemies like the turrets can't move anywhere. In these cases, their "behaviour tree" (a logical plan I work with while designing the AI that represents how they assign tasks) would simply ignore states that they won't use.
  • Patterned AI are like Dr Nefarious and other Boss types. They follow the conventions of Standard AI, but they also have much stricter rules about their behaviour and typically work in patterns (for example, Dr Nefarious while use the same three attacks with the same timings until his health drops below a certain point, at which point the patterns change). For this reason, they're far less dynamic than Standard AI will likely rely less on Seeker (more in a second), instead using their own perception systems.

Each state would be represented by a set of tasks inside the code. The State Machine isn't a physical construct that I program in; it's just a way of representing the logic of how my AI units respond to different situations.

 

Now, as I said before, states are prioritised; you do each one at a time, and anything of higher priority goes "on top" per say. We also break larger tasks down into smaller subtasks. The way all this is represented in code? Well, there's a beautiful construct in the C# language (and most programming languages) called a "stack". A Stack is LIFO-structure; that is, the last element in is the first to go. It's kind of like having a large stack of papers; you can't get the paper in the middle, you need take the ones off the top until you reach the middle.

 

My system works by throwing tasks into the stack one at a time. A single function is responsible for looking after the stack and running tasks that are inside the stack; when the "Event Manager" is called, it looks to the first task on the stack and runs it; that task then does it's business and returns a true or false value to represent if it needs to be put in the stack again (because the task is not complete). The reason for this is because of stuff like timers or movement; games run at 60 frames per second, and the code is executed one time per frame. If you moved a character in one frame, they would appear to teleport all over the map very quickly! These kinds of tasks need to be spread out so as not to break the time flow. Tasks determine if they need to be repeated or not by checking a list of conditions, which might involve some simplified pathfinding or math depending on the task.

 

Now, how about sub-tasks? Well, tasks can place other tasks in the stack. This means a "parent task" could put its children tasks into the stack in the correct order (the ones that need to be completed last go in the stack first), and on the next frame the AI unit starts running those subtasks. To take the washing example above, a task called "WASHING" would put the tasks "PLACEPILES", "SORTPILES", "FOLDWASHING" and "COLLECTWASHING" into the stack, and then return false as it doesn't to repeat (since its children are in the stack, and they can return true if the individual steps need to continue).

 

Now, as a quick aside, tasks have the ability to abort execution. That is, tasks have their own if-else/switch statements, and if they determine that something is wrong, they can just quit without doing anything and not repeat. This might be needed if, for example, the AI reaches the player before the node they were originally pathing to.

 

So, the last questions...how do we get tasks and what happens when the stack is empty? Well, I've mentioned Seeker a few times. I said in my second post that Seeker would be a condition system that each AI can ring home to. Seeker is the answer here. Basically, when the Event Manager sees the stack is empty, it will execute the Seeker system. Seeker then checks a huge list of rules and conditions (including doing the advanced math/item checking for pathfinding), and returns to the AI Unit with a message in the form of an "enum" (which is basically making your own type of variable with named values), which could be anything from "RETREAT_SCARED" to "FIND_AMMO". Every AI unit's individual Event Manager can then choose how to interpret the message it gets back, whether that be ignoring irrelevant ones (such as an turret ignoring retreat/move messages) or adding a task/list of tasks to the stack. While I haven't decided the rules list that Seeker checks or what enum values will be available, I believe the concept is solid.

 

That there is the gist of my approach to the AI system, as well as Game AI theory in a nutshell. The field is a lot bigger, and the challenges a lot tougher, than I make out but hopefully this overview is a little more clear as to how this will all come together in the end, assuming that I don't change things as my knowledge increases in this filed (which will likely happen as there's a lot of places for this system to fail or be improved).

 

>RESEARCH<

 

Part of learning how to do anything is research. In my case, I'm heavily researching the Ratchet games. That doesn't mean just playing them and taking notes, or scouring the Insomniac Museum(s), but it also includes looking at web documentation. In the past, I completely broke down the Ratchet & Clank developer commentary series into very large note documents with images and my own commentary, also taking stuff from the comment sections of the videos, which I'm finding super handy now.

 

I'd like to give a single specific example of how research can help me, however, and this comes from a "glitch" video someone produced:

 

 

If it's not clear what happens in the video, when the player returns to the start point he can see Ratchet (the primary player character), with odd proportions and mimicking the moves of the current player character Clank.

 

Now, I also want you to be aware of the Bombs-Away minigame, a scrapped minigame featured in the Insomniac Museum as (barely) playable which would have been a clone of Bomberman, in the same way that the Qwark Vidcomics were Megaman and the Hacker puzzles were just Tempest. While I don't have footage on hand, you note that when you start the game, the Qwark figure inside the game mimics your inputs, except with jump redirected to "plant bomb".

 

The reason I mention these two? It's very clear, at least to me, that the engine for Ratchet & Clank is designed for playing as a single character. In order to get around this limitation and allow you to play as other characters, they parent the camera to another mesh and have the mesh copy the animations of the player character. For collisions, UI, weapons etc, these are all played around with in the game normally anyway (Ratchet has many different states, unrelated to AI states, that affect the way you control him and what he has access to) so it's likely there was no bodgery necessary to make this work. It also points out that minigames, if not clear, are just standard 3D scenes like you would normally experience with Ratchet, with the camera made orthogonal and parented differently and the UI/Control Inputs changed.

 

I've learnt a lot more by seeing glitch videos, such as how a lot of the game's meshes use simple planes, but the point is that this research is really helping me dive into how the developers approached this game, and it's giving me inspiration on ways to follow suit or even improve upon the original work.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.