Scripting and DSLs

Scripting and DSLs

    

    We recently watched a GDC video put on by developers from Moonshot Games about Scripting and DSLs (Domain Specific Languages).  Immediately, I was interested, since this year our GDW group is using the Squirrel scripting language for our gameplay logic.  Damian first started off by talking about how some programmers are against scripting and deem it as "lazy", when it is actually quite the opposite.  Scripting is a very powerful tool, and incredibly useful, especially when you are using it for gameplay logic.  I have experience with scripting and always found it to make things much more fluid, organizes things better, and allows you to code gameplay much faster.  This is due to not having to hardcode everything, but rather build the underlying engine, and then "exposing" this classes/functions so that you can then call them within script.  Now understandably, certain things are best done in hardcode (like the engine), but I believe it is much more efficient for gameplay to be done in script.

    He then went on to talk about Component and Systems Soup.  Component soup is basically when you have many different components for your game like physics and animations being used within your game.  They are usually done in both hardcode and script, and can create quite a mess.  

    System soup is similar to component soup, but is on the systems level.  These subsystems can have this component soup within them, and then be called by script or hardcode, which creates an even larger soup.  This makes it even messier.

    He then went on to how a typical code workflow looks.  The engineer designs the the framework within hardcode.  It is then handed off to the designer who implements it within script and designs the game and gameplay, and makes it work.  It then goes back to the engineer who focuses on making it fast and efficient.  Finally it then goes back to the designer to make sure that the code still does what it was originally intended to do.  These last 3 steps can be cyclical, going through several iterations before it is finally done.

    Then, another programmer started to talk about DSLs (Domain Specific Languages).  DSLs are languages which are strong at solving a specific set or class of problems.  Some DSLs are SQL, XSLT, Verilog, and Python.  These range from specific to generic in terms of their degrees of specificity in terms of specialization.  There are 3 principles which pertain to our application of DSLs: 

Principle #1- Code cleanliness and the effects of mapping the code directly to the problem space

Principle #2- Elimination of bugs which are caused by irrelevant concern or problems which do not directly apply to what we are trying to solve

Principle #3- Removing excess overheard; increasing productivity by eliminating details that do not pertain to solving the problem.

    He then moved on to how syntax for DSLs would look.  As you can tell, the key is the minimization of expressions, and straightforward, clean syntax.  Something that really got me interested was the line of:

Bad:   player.health -= weapon.get_damage();

Good:   damage player with weapon

Using syntax like this makes it incredibly easy to understand and write code for what you want to happen.  This form of syntax I think is incredibly powerful, and would allow people who can't code, to be able to have some input within the design process (on the programming side).

    He then ended it off with the benefits DSLs have on the entire team.  This goes to show you that when used correctly, DSLs can be an incredibly powerful tool, and help out when doing any sort of programming within games or software.

    In conclusion, this was probably one of my favourite GDC videos that we watched thus far.  It divulged a ton of information on scripting and DSL languages, which is something I am quite intrigued by, being a strong scripting proponent myself.

Insomniac Games GDC Presentation: AI and Navigation Meshes

Insomniac Games GDC Presentation: AI and Navigation Meshes

    In class, we had a video presentation from Insomniac games and there AI and Navigation Meshes which they use within there games, like Resistance and Ratchet & Clank.  He talked about how adding in navmeshes allows to solve problems in constantly evolving worlds, and adds more life-like AI for NPC's.

    He starts off by talking about how the implemented navmeshes in Ratchet & Clank: Deadlocked for the PS2.  These nodes were made by the designer, and then were used as nodes for the A* algorithm.  He then talked about navmeshes and their use in Resistance: Fall of Man, which was a PS3 launch title.  These navmeshes were also designer laid, in maya.  They then had tools which built a convex poly mesh for runtime.  The volumes were again, used as nodes which were navigated through by the A* algorithm.

    He then moved on to how they corrected cornering, for a smooth continuous motion.  They implemented a Bezier curve for modified smoothing around corners.  Curve Tangents were ensured within the NPC mesh, so they applied the bezier algorithm within the pathfinding.  They NPC would then follow along this corrected path, allowing for a much seamless and realistic movement around corners.  This helped avoid the look that a character would be on "rails" and making rigid course correction.

    Then, the topic moved onto custom links, which detailed jumping, ladders, and other environmental objects which the AI could use to navigate through the level.  Originally, this was done with point-to-point links, however, the problem with this was that it was unfriendly to changes, does not fit nicely with the A* algorithm or smoothing and causes issues with dynamic objects near the links.  How Insomniac tackled this was by creating custom-clue-boxes, which would denote an action that can be taken, and outfitted with custom-clue-edges.  These edges could be represented within A* as nodes.  This would then allow an NPC to approach an area, then receive information through these custom-clue-boxes on what action can be taken here, and follow through with said action.

    Finally, he went into how they generated their nav meshes.  The first thing they would do would generate world geometry into a voxel grid.  Then, they would build navigable voxels, filter and smooth them and then erode the resulting navigable voxels.  In their third step, they would build watershed partitioning.  This is done to indicate region boundaries.  They would build the distance transforms, making each catchment basin a mesh chunk.  In the fourth stage, they would trace the catchment basin's contours, forming the nav mesh chunk's boundary edges.  In the last stage, they would triangulate/tesselate to create the nav mesh.  The issues they ran into however, were undesired nav-meshes.  To fix this, they created custom override polygons, which would negate the undesired nav-meshes.

    In conclusion, I found the fact that they continue to evolve navigation meshes from what it is today fascinating.  I'm very interested in the advancement of AI, both in games and in other applications, and look forward to what they will be implementing in the next gen.

Games and Artificial Intelligence (AI)

Games and Artificial Intelligence (AI)

    Artificial Intelligence (AI) is creating or simulating intelligence within characters, robots, etc.  There are mainly 2 different types of AI, Traditional, and Game AI.  Traditional AI is when everything is solved through logic.  If given a statement or choice, AI will come to the conclusion via steps to solve the task at hand.  Game AI is when actions and reactions are based on proximity, states, and action-based programming.  This are things like, when an NPC hears a noise, they will walk towards where they last heard the noise, or hitting an alarm to alert the enemy guards.  This produces realistic actions and decisions.

    

    AI determines how a player moves, their abilities and when to use them and what decisions are to be made based on the circumstances.  Good AI allows the player to feel immersed in the game, and makes them think that the characters are actually making decisions.

    There are a few different forms of game AI techniques.  Seek is when the NPC seeks the player.  This is done through taking the position of the player and calculating the distance and direction of where the NPC needs to go.  This creates a realistic look of a character trying to find the player.  Flee is when the NPC runs away or moves away from the player.  This is done by finding the position and direction of the player, and calculating a direction opposite of the player.  Flock is when multiple NPCs seek to swarm together and either patrol or search for the player.  This is done by defining radii around the NPCs, and when they enter eachother's outer radius, they know to join and face the same direction of the group.  There is then an inner radius that describes the cushion of space to be maintained between each NPC.  You can add a repulsive force to move the NPC out of this circle if the inner circles of the two NPCs intersect.

  We are always looking to improve AI, in both games and traditionally.  We as a species are fascinated by our own intellectual power, and are trying to reproduce it within a non-organic form.  Where this goes from here, no one knows, but AI is a fascinating field to study.

Cameras in Games

Cameras in Games

    Camera and Camera systems are incredibly important in games.  Obviously, the most important fact is they allow a window into the world for the player.  They also however, can affect feeling, or give add a dramatic effect.  

    In god of war, there is extensive use of camera systems.  Programmers put the camera on a rail and boom system.  There is a min and max distance defined and maintains a certain distance from Kratos as you play.  When you activate triggers or quicktime events, it moves along this boom to a minimum distance from Kratos and either maintains it's translation, or re-positions itself depending at what point it is at within the sequence.  You then get up close and personal with the action going on as you play.  This gives you these great visuals, like the one above, as you are about to rip this guys head off.

 

    Then you get 3rd person camera systems like that in Mario 64.  This camera has static definitions of where the camera can be.  You can switch between this predefined distances, but does not incorporate the "cinematic" style that you might achieve with games like God Of War.  This camera system is purely focused on giving you the information you need, and less of giving you and in-your-face style of interaction.

    Fez incorporates there camera system to create a unique mechanic.  From first glance, it appears to be just a standard 2D platforming camera.  However, what makes Fez one of a kind is that they incorporate 2D graphics within a 3D world.  With the press of left or right triggers, it rotates the world (or camera) on the Y-axis and opens up another dimension of the world.  The designers were able to implement this unique use of the camera to develop a one-of-a-kind mechanic.

    You also have first person camera systems.  This systems are best used in FPS games and games where you want the player to view the action from the character's point of view.  This systems allow the player to feel engaged in the action, and allow for dramatic effects like the blur you see above.  In Amnesia, it also allows the designer to add more elements which will make the player feel tense and fearful.  For instance, going around corners in a 3rd person system would let the player take a sneak peek without actually having to walk around.  In this system, the player must go around, allowing the designers to add more surprise tactics to frighten the player, especially since it is happening right in your face.

    Regardless of which system you use, it is important that it matches your style of gameplay and gives the player the engagement you want.  

Navigation Meshes

Navigation Meshes

    In this blog, I will talk about Navigation Meshes.  Our last chunk of lectures have been on Navigation Meshes, how they work, and how you can implement them.  To put into simple terms, navigation meshes, or navmeshes, are basically areas which are mapped out, and then relied upon by bots and AI to determine where they can and can't walk.  They are really helpful in determining pathfinding for AI.

    Pathfinding in games is far from "solved", as you can see in this video: http://www.youtube.com/watch?v=lw9G-8gL5o0#t=35, but navmeshes help solve some of the problems that you find with pathfinding techniques, such as waypoint navigation.  Navmeshes also allow you to describe large areas, which allow for much better AI decision making, with less effort (as opposed to using waypoints, which could need a ridiculous amount in open areas).

    Navmeshes also will allow course correction, which is something that can be difficult or impossible with waypoint navigation.  With waypoints, you would need to cast a whole bunch of new points around the obstructing object, which could intern, make your pathfinding much slower.  With a navmesh, you can simply raycast against the obstructing object and make a course correction.

    Navmeshes can also describe interactable areas for AI.  The picture above me shows a navmesh marked with a green X.  This navmesh tells the AI that they can jump on an object and enter a new navmesh (located on the top of the object).  

 

    They also make it easier to determine paths for different characters (different heights, size, vehicles).  Normally, you would have to introduce a new set of waypoints for a character to follow, and a vehicle to follow, since vehicles are much larger and would not be able to hug as tightly to buildings or objects as characters can.  With navmeshes, you can simply adjust the distance from the object based on the size of the object, and then you can build 2 different paths using the same mesh.  This makes it a robust tool when determining different paths for different sized objects.

    Navmeshes are a great pathfinding tool, and there are many navmesh generators out there, so they are easy to implement as well.

Voxel (atom) Engines

Voxel (atom) Engines

    So what are voxels?  Voxels, or atoms, are volume elements which represent a value on a plane in 3 dimensional space.  In lamens terms, it's a very small element or cube.  Now, voxels are incredibly small, and work exactly like atoms do.  Basically, how humans are built up of very small atoms, that are bound together to form us, voxels do they same thing.  Hence why they are also called atoms.

                                                             A Tiger sculpted using voxels

    

    Since you are building everything out of really tiny atoms, you can do some incredible things.  For instance, you can break away layers of a brick wall without having to re-render the wall.  You can also imprint tire tracks into the ground without having to apply a texture.  Check this video out to see some really neat tricks and advantages of using voxels:

                                             http://www.youtube.com/watch?v=_CCZIBDt1uM

    The downside is the fact that as you get close to the terrain or objects, it becomes out of focus.  The other problem is if the voxels are too big, geometry can become very blocky looking.  

    You can also see large landscapes and some sculpting with voxels here:

                                             http://www.youtube.com/watch?v=VYfBrNOi9VM

    Notice again, that as he gets extremely close to the geometry within the level, it starts to become out of focus and blocky.  However, from a distance it looks incredibly detailed and realistic.

    Voxels have already made an appearance in video games, although in a much smaller and less detailed way.  For instance, it is used in 3D dot game heroes to produce that awesome retro feel.  It is also used in Crysis in combination with height maps to produce their terrain system.

                                                                                              3D dot game heroes

    

    In short, voxels have a lot to offer to games, and I believe that as hardware advances, you will start to see voxels being implemented more and more as detail and realism becomes more apparent in our games.

Week 2 - What is a Game Engine?

What is a Game Engine?

  In our second week, we started to talk about what a game engine actually is.  There are many different types of game engines (Unity, Havok, Unreal) and each engine can handle different aspects of the game (Havok - Physics and animtion; Unity - Phyics, animation and rendering; Ogre - Rengering).  Engines deal with the core elements and calculations for your game, such as: data structures, timers, memory management, resource management, compression/decompression, encryption/decryption, math utilities, file I/O and other utilities.  

  The great thing about engines, is the ability to reuse them for different games.  You can take one engine, and build multiple different games around it.  Now, obviously tweaking will need to be done to get the desired result for whatever you may be using it for, but it saves you a whole lot of time, especially since you will not need to rewrite a completely new engine for each game you develop.

  As you can see with the above image, there are multiple different engines talking to each other, but each engine can be taken and used in a different project (again with minor tweaking).  This is one of the many attractive qualities when using engines.  You will also notice that each engine has a specific duty.  One might handle animation, and another scripting.  You can develop "complete" engines which handle everything in one package, but many games use an already developed engine which may handle a specific task, and plug it in or build additional components to develop something entirely their own.

  We also touched on scene graph's which are considered the core of an engine.  Scene Graph's allow us to organize objects, primitives, allow grouping, group transformations and effects.  Their job is to feed geometry to the renderer, which is later rendered to the screen.

  Finally we went over subversions and UML diagrams.  Subversions are important to monitor, since many programmers will be working on an engine at one time, so it is important when submitting your code to identify what code version you are working on, and what version is currently in the repository.  UML diagrams are incredibly helpful when you are working with engines, especially when you wish to identify which systems you want communicating with eachother, and what those subsystems contain in terms of functionality.

  For my next blog post, I will be covering singletons, and how managers can organize create efficient communication within the subsystems.

First Week

First Week

  
    Well, we had our first lecture for Game Engines.  Since it was the first lecture, most of the class was used for dealing with administrative stuff and course structure.  After we were done with that, we got into what we will be learning about and what we will be doing.  I have to say, once we started talking about the course, it got me really excited.  We will be using Havok as our physics engine, and Ogre for our graphics and rendering engine.

  
    These engines will help out greatly in improving the quality and mechanics within our game.  Before, we had to create our own engines from scratch, which was invaluable in providing us with knowledge of how engines work.  The caveat to this is that since we have such a short amount of time to create our game, our game engines lack the more advanced functions that these third party, pre-built engines have.  It also takes up a lot of time having to program in the basic engine functions like collisions, animations and physics calculations.  With these engines, we can now focus on adding more gameplay and creating better and more enjoyable game mechanics for our games.

    Now, with all that said, I still enjoy developing my own engines and I believe that learning how to build an engine and the basic functions that go into engines should be learned before you go using pre-built engines.  This will then allow you to understand what is going on within the engine and allow you to better use the engine to it's full extent.  It will also allow you to use the engine as an extension to/or a plug-in for your own engine.

    Now onto my game idea.....

    My game idea would be a puzzle game where you are a mouse with a solar staff.  The staff manipulates light and dark energy.  Each level would hold several different puzzles which would need to be solved by channeling these energies.  Some passages of the level might only be accessible when day turned to night, and vice versa.  You could change the time of day by using the necessary light or dark energy on a stone, situated in a central room.  From there, you would proceed to solve each puzzle until unlocking the final door.  These puzzles could be anything, from putting weights on switches, to completing a circuit.  Once all of the puzzles were solved, the door to the next level would open up.

    Entities apparent in the game would be a main character entity, as well as enemy entities.  Items within the game would be the solar staff and the different puzzle items (things like blocks to fill holes, wires to complete circuits, etc.).  The main feature of the game would be the ability to control dark and light energies (solve puzzles, change day to night, unlock passageways). 
 
    I think these features, mixed with the Havok and Ogre engines could produce a quality and enjoyable game to play.