Wednesday, June 25, 2014

[S&K] Some progress made

Despite doing very little in the previous days of the game jam, some sort of progress has been made. We have an ally that says "hi" a lot and an enemy that moves entirely randomly. Something is more than nothing.

We also have art of ninjas that will eventually be in the game:


Tuesday, June 24, 2014

[MMc] OpenHeist map loading and rendering done


Map loading, tile sets, and the API for changing tiles at runtime are all complete. I halved heist::TEXELS_PER_METER from 96 to 48 in order to better match the scale of Monaco tiles at 1080p.

Although I will continue to add both cosmetic and utility functionality, all major functionality for OpenHeist is now present as the major parts of creating a data-driven, multiplayer game are now working.

The API changed remarkably little in the past 36 hours. Most of the changes that were required went into supporting the map, which was ill-specified in the initial API. Mike's idea of treating map cells as a grid of subclass-able objects to better support game-specific state was a very good one, but required a funky factory pattern and more obscure C++ syntax to implement. The codebase grew from 1200 to 1900 lines since the jam began.

As specified in the documentation, the development roadmap for the engine is now:

  1. Implement collisions with map
  2. Specify spawn points in the Mission
  3. Make player character creation follow the factory design pattern
  4. Implement map line of sight 
  5. Specify overlay text in the Mission
  6. Implement GameApplet::drawTileShadow



Sunday, June 22, 2014

[MMc] OpenHeist maps specified

Maps and tile sets now have an API and parsers. Maps consist of multiple elevations. Each elevation has two layers: the "floor" under characters, and the space in which they can move (or not, if there are walls!)

Maps are drawn in a text editor using two characters for each grid cell:


The numbers running along the top and left edges are required. They let the engine know how big the map is and help the map designer when editing.

Because different games will need different per-cell properties, the map cells are all subclasses of heist::CellBase that are created by whatever function is registered as the server::App::cellFactory. These are server::Cells by default. When a cell is changed on the server, it automatically sends a message to the client notifying it.

The map, tile set, and tile parsing code is all implemented and compiling but not connected to the loadMission function. Once I have connected those and made a first pass at rendering the tiles you will be able to see your maps in-game. I recommend making maps and tile sets now based on the examples so that you can debug them once the renderer is connected.

[MMc] OpenHeist Object Rendering Complete

Object rendering is now complete in OpenHeist. This allows for a full scene graph, player and non-player characters, zOrder sorting, and non-character objects. The Luxembourg example game takes advantage of the non-rotating animation option to keep the heads upright as the character direction arrows spin:


I also added a sprite debugging view, which is enabled by default in Luxembourg and can be toggled from the GApp::debugWindow (push F11, and then the icon with the switches to access this). It dims the screen 50% and then draws an overlay of the bounding box and coordinate system for each heist::client::Object:


I'm going to tidy up a few more features for object rendering and then move on to the map. The documentation has been updated to include more information about the coordinate system. The key points are:
  • Everything is scaled to render as if the screen were 1920x1080
  • 96 texels per "meter" (blocks will be one "meter" in the map)
The online documentation is fairly out of date at this point, so be sure to build the local documentation using Doxygen from the library source code.



Saturday, June 21, 2014

[MMc] OpenHeist update

Menus, joining a game (local players only), multiplayer, audio, controller and keyboard support, and choosing characters are all 100% implemented and tested. Remote players are 80% implemented...don't try remote multiplayer yet.

The code is all in place for having characters move with dead reckoning and to have characters render with a full scene-graph render (as white boxes), however...they aren't moving. Messages are flying back and forth between the client and server, but I don't see the actual position state changing on the client. I'm debugging this now but welcome insights if anyone else wishes to step through the code in the debugger as well. Incidentally, the characters aren't appearing on screen either, but that will be easy to fix once it is possible to move them.

Once character movement is working, I will implement map loading and movement constraints. Maps will be specified by text files, with a separate key mapping ASCII characters to tile names in the .Any file for the mission.

You can see the full engine TODO list in the main page of the documentation, in implementation order.

[MM] Pet Pandemonium Design

Game Name:
Pet Pandemonium (working title)

Team Members:
Michael Mara, research scientist at NVIDIA, instructor at Williams College, graduate student at Stanford University

Setting:
2010's Greenwich, CT

Mechanics:
Destruction + Stealth + Advanced Sound System + Somewhat Orthogonal Characters
  • Goal is to cause maximum headache for the humans
  • Character have extreme strengths + weaknesses
  • Full Stealth; when humans see you go to full escape mode.
  • Humans alerted by noise, noise reflects off walls
  • Points for property damage + inconveniencing humans
Player Characters:
You know what? I'm proud of this. 10min total for four characters, in ink even. Dog didn't even have reference!

Dog
: Big. Causes lots of damage. Least number of movement options. Makes lots of noise. Not terribly bright.

Cat: Quiet. Acrobatic. Can jump on tall furniture to get at expensive things.

Hamster: Small. Can crawl in walls (if hole is found). Cannot do much damage, besides chew cables.

Rabbit: I dunno. Eats carrots? I'll be happy to implement the first three by jam end. Wait, no! Telekenetic. Has psionic powers. Makes sense...

The one map for this game jam, I will be implementing is a McMansion with a large family.

Plan of Action:
  1. One character on screen moving using controller.
  2. Working walls.
  3. Items that can be destroyed
  4. Points for destroying items
  5. Goal outside of level; game ends
  6. Report score (GAME JAM DEFEATED!)
  7. Two characters on screen moving using controller
  8. Dumb human AIs that cause game to end when they see character
  9. Make sounds when breaking things.
  10. Have people hear things based on distance and come to see.
  11. Stop, reevaluate, make further plans


Machinis Ludo V: Cooperative Jam begins!

Good luck to everyone with your cooperative ARPG heist games!

Some advice:

  • Work in short sprints
  • Focus on mechanics first
  • Start small and playable, and then add features
  • Post regularly to this blog with screenshots of your progress, photos of your environment and notes, and inspiration
  • Feel free to post to the blog with questions (about OpenHeist, Git, C++, G3D)
  • Keep your build working (compiling) at all times
  • Use report() instead of assert if there's a way to recover from the error
  • Remember to look at the visual studio console for report() messages
OpenHeist:
  • The detailed change log is here
  • Morgan will post about major new features or API changes on this blog
  • Submit Git Pull Requests or e-mail Morgan to merge your code into the trunk


[MMc] Luxembourg

Game Name:
Luxembourg

Team Members:
Morgan McGuire, professor at Williams College

Setting:
1950's noir

Mechanics:
Monaco + dialogue:
  • Switches
  • Limited range & melee combat
  • Item power-ups
  • Stealth
  • Dialogue trees
  • Collect coins
  • Main treasure/switch per level
  • Timed actions/recharge
Player Characters:
The Mastermind: Uses the power of the most-recently touched player character.

The Thief: Upgraded sneak and lockpick skill. (Like the Hacker in Monaco)

The Grifter: Extra dialogue tree choices, deployable white ferret pet. (A bit like the Pickpocket in Monaco)

The Engineer: Can enable/disable mechanical switches. (Like the Hacker in Monaco)

The Doctor: Can heal without a medpack, including himself.

The Muscle: Can attack without a weapon. (Like the Cleaner in Monaco)

The all-white characters and 4/2 male-female split were inherited from the base OpenGameArt assets that I created the characters from. I'd like to adjust that for better representation, but implementing game mechanics is a more pressing need during the jam.

Luxembourg is the sample game for OpenHeist, so I'm sticking fairly close to Monaco so as to have a strong gameplay reference. The game and characters are largely inspired by the A-Team and Leverage TV shows.

Friday, June 20, 2014

ThEph - Dan and Jamie Monaco Game Jam Idea

Dan Evangelakos mentioned that a lot of video games focus on shooting and killing because they like to focus on scandal - for instance in Monaco players work together to perform robberies.

So as we sat surrounded by Williams College, we thought - what's more scandalized than cheating?

In ThEph, players representing different majors can work together to steal problem sets, test answers, and even cutting edge research to complete their degrees and become successful in their field.

Students from each major will have individual powers - Math majors may have the power to distract Professors with complicated proofs, Computer majors may hack computers, Chemistry majors can use sleep vapors, Biology majors can release lab animals, and so on - their goal to retrieve the desired booty without raising too much suspicion, and escaping with absolutely no detection (being caught red handed would be an automatic violation of the honor code). Other characters would consist of faculty members walking around, doing work, chatting with other faculty, and constantly looking out for dishonest students. Approachability of these faculty will be measured in coffee levels displayed on the screen, coffee items may be found and offered to faculty to increase their happiness.

We would also like to restrict players to one item that can be used just once - limiting ways the players can retrieve information and therefore making it more of a puzzle game.

The environment will clearly be Science Quad, simplified to wall and hallway tiles.

Can't wait to keep you updated with the progress of ThEph, make sure you bring your mirrors - I hear the lasers in the Physics laboratories are pretty tricky to navigate.

Machinis Ludo Proposal (Game name to be determined)

Hello! we are Kelly Wang and Sam Donow, two rising juniors at Williams College working in the Graphics Lab over the summer.

Our game idea for the Cooperative Game Jam starting tomorrow is basically a heist game with different characters with unique abilities trying to pull off an assassination/heist. As of now, our game is still in the planning stages so we will just give a general outline here, but the premise of our game is such: a group of ninjas from a close-knit village are the sole survivors of a village raid by assassins from a rival village. Your small group is trying to get revenge on the enemies who killed the rest of their village.  

It will most likely end up being similar to Monaco, except the role of the player would be to catch the murderer(s), who is always running away from you. Perhaps the longer the murderer avoids you, the more opportunities he has to call for backup, and so the number of enemies on screen increases as time goes by. So, you must at the same time chase down the murderer, setting traps for him along the way, avoid getting killed or caught by the backup, and loot the enemy village or the fleeing enemy's pockets to get the funds to rebuild your own village.

Potential Roles:
Hitman
Trap setter
Treasure Collector
Guard/Lookout
Diversions person

NPC characters:
The enemies who destroyed your village
The bodyguards who come to attack you

Standard Abilities:
Stabbing with a sword
Throwing shuriken

Special Abilities:
Stealth/disguise (Diversions or Trap setter or Treasure Collector)
Speed (Hitman or Guard)
Strength (Guard or Hitman)
Teleportation (Diversions person)
Jumping (Hitman)

Items:
Coins 
Katana (close combat swordsman for the Hitman)
Smoke bombs/Mines
Shuriken
Nets or rope for traps
Armor
Special shoes that make you faster

Maps:
Outdoors- Forest, Caverns, Village streets
Indoors- Village houses, Tunnels

So there's a rough plan for our game, but of course as we begin implementation and actually begin writing code, we will get more into the game and will begin adding more detail! Our goal is to end up with a (somewhat finished) playable game and of course, build our skills in programming and game design.