Wednesday, June 25, 2014

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.

Tuesday, June 24, 2014

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:

Sunday, June 22, 2014

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.

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.

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.

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

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.

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.