Leaderboard

[14:19:09 | Edited 14:19:15] ExcessJavaScriptPurger: I need breakfast [14:21:24] Bug Catcher: You can have mine D E L I C I O U S

Use as you will, forum avatar, speech box in game, etc, I don't care. https://www.dropbox.com/s/8u37ultdvtpke61/LEGO%20Island%20Portraits.zip?dl=0 See more in update 2 post. See more in update 3 post.

Updated some things and added another character.

You're a special kind of individual. Never change.

I finailly got to work on some expressions for Wrench; the Nitro racer has been added!

Well hey, there is already four of us using the avatars, why don't we have more?

Thanks. I spiffed one up a little

Awesome. Long live dogface!

[9:36:29 PM] Will Kirkby: christ [9:36:32 PM] Will Kirkby: I've just realised [9:36:42 PM] Will Kirkby: I'm never gonna be able to visit my grandfather ever again [9:37:33 PM] Pereki: I'm sorry for your lo - [9:36:49 PM] Will Kirkby: without having that f****ing fleentstones theme in my head [9:37:44 PM] Pereki: ...oh

...lo and behold, a new update is available! Looks like mostly minifig parts and such, but I'm not complaining.

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: 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? 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.

Always, and not really. At least not the models part. That's interesting. The World.wdb file you included is 1763[dec] bytes larger than mine. Anyhow, this is great, here's a screenshot of the island: