Machinis Ludo 2 Summary

---

Operatives: Hidden Agenda
by Morgan McGuire / Casual Effects
created using 3DS Max, Photoshop, G3D Innovation Engine, codeheart.js, MSVC 2010, mongoose, libqrencode
about 1200 lines of C++, JavaScript, and C-like data files and 30 MB of data files.

iPhone View

TV View

O:HA is a multiplayer-only cooperative spy game. It is a "virtual board game" in which each player has a private view of his or her cards on a smartphone or other browser and all players share a public view of the board. Play proceeds in (slow) real-time, with actions taking both real time to initiate and to execute.  The design goal of keeping resources private is to enable traitor-like play.

I caught the flu and did not complete my game during the weekend, but hope to follow up on it, maybe during the next jam!

---

Cannonade: like lemonade, but with cannons..?

by Edward Powell

Created using  G3D Innovation Engine, Bullet Physics, GameDev-UK.net GameLib, MSVC 2010, Blender, Paint.net, Vectric Aspire

Required 11 novel classes and a lot of mods to my game lib!

Waves of increasingly fast aliens are trying to overrun your fixed gun emplacement - how long can you hold out? Cannonade is an old-school first-person shooter using physical, relatively slow moving, bouncing, projectiles. The emphasis is on careful shots and judging the trajectory of both your grenade and target.

Didn't manage to get as far as explosions and the collision detection hook from Bullet is definitely not quite right, but I have made a good start. The bullet integration has been done as part of an independent game lib, so hopefully I'll have plenty of opportunities to re-use and refine the last few days work in other projects.

---

Disorient: The Engine

by Nigel Munoz
Created with: LWJGL, Slick2D, Adobe Illustrator
DL: http://tinyurl.com/c2rd9db

I didn't get to make a game in the exact sense. Instead, I managed to create a very shaky engine.

You can run around a randomly generated map and shoot tiny pellets.

I did however achieve my primary goal, which was not getting sick. (Sorry, Morgan.) Secondarily, I achieved my other goal, which was to experience game development within the Java enviornment. (Not terrible.) With practice, here's hoping my next Java game will end up better than this one.

---

Game 1 (I never actually thought of a name for this...)
by Sam Donow
Created with: HTML5, JavaScript.
DL: https://dl.dropbox.com/u/34972177/game.html (along with instructions to use up down arrow keys and the 1 and 2 keys, which I was too lazy to implement a directions screen to tell people about)

I made some form of a game, it came from a rather half-baked idea, but at least it was completed in the end. I did, however, at the very least manage to finish something, which is more of an accomplishment than I had with the last game jam, and I got to achieve my primary goal, which was to get some experience using JavaScript, and also some experience with designing a game, something which I had not done before.

Anyway, its a very simple game: you fly through a cave, and try to avoid hitting the cave and the yellow-square enemies; the only "good idea" I really had was in how I generated the caves, which are the only part of the game which has more detail than being just a rectangle.

---

Constellations: Graphs in the Sky
by Philippe Demontigny

Created with: codeheart.js
Link to Game: graphics.williams.edu/hosted/constellations

Constellations is a puzzle game that presents Graph theory in a fun and interactive way. Players learn about concepts such as connected graphs, degrees of vertices, and bipartite graphs, then apply what they've learned to solve puzzles that encourage mathematical thinking and experimentation. Constellations is unique in its "Challenge" puzzles of which only a handful have solutions. Finding the challenges that do not have defined answers forces the player to create logical arguments for why a solution cannot exist, which is the basis of a formal, mathematical proof.

I hope to eventually add enough puzzles to this game to cover an introductory course in Graph Theory. At the very least I want to implement some "Traverse" puzzles that work with predefined Graphs.

---

Castle Siege
by Dan Fast and Arjun Narayan

Created with: codeheart.js
Link to Game: https://s3.amazonaws.com/castlesiege/play.html


Castle siege is a game where a player directs their forces to capture an opposing player's castle. Heroes (the characters in bright yellow) attract troops and can move around the map by being dragged and dropped. 

We did not finish the game jam in time and plan to take the Wolfire path of continuing to work on it. Hopefully a playable version of it will be ready in a few days. 

Hope everybody had a great time with the jam!

Machinis Ludo 2 Ends

We're wrapping up the jam at 6pm ET.  Thanks to everyone who participated and congratulations to the winners who completed a game!

I'll make a summary post for everyone to edit and describe their game in a moment.

I'm not among the winners this time, but am happy to be alive and starting to recover from my "cold", which I now think is influenza.  I updated the mobile client graphics for Operatives: Hidden Agenda. Players can now  see actions for the selected card and have a view of all objects in the room.  Right now the objects on top of the room are just available as buttons to act as targets, but on seeing the UI I'm rethinking that.  It seems logical that if you want to drop something then you should drag it to an empty space in the room, and if you want to take something then you should drag it onto your private portion of the screen.

[Edward] Final version

Well here is the final(ish) version. Loads of time squandered trying to get some simple textured OBJs out of Blender and into the game – why is this bit so flippin’ hard?! Anyway, as a result, I ran out of time on the tanks ,so the enemies have had to stay as not-very-menacing collision spheres I’m afraid. I’ve still got a major problem with missed collisions – although my son likes the fact he ‘gets away with it’ quite frequently! I *think* this might be because I check for collisions each frame, and simply miss the precise moment when objects are in contact? Suggestions on how best to resolve this from any Bullet physics gurus our there would be gratefully received!

Still, it is *basically* a game and officially the first one I’ve written since moving back to C++ after XNA bit the dust last year, so I’m pretty pleased.

I’ve put the final build up on https://dl.dropbox.com/u/34670572/Cannonade.zip for post-jam discussions. Any feedback welcome, but I haven’t tested it on anything but my dev box so be warned: it might kick your cat and steal your milk…

Cheers all, E.

[Sam] "Done" with something of a game

The very limited scope of my idea for the game resulted in being able to finish up fairly quickly, as things that proved to hard were just ignored. The only idea that I had that was fully-baked to begin with was that I would have a randomly generated side-scrolling cave:   that was accomplished in full. At first I thought I would try to implement cool enemies and weapons and things...but that kind of fell through. Nonetheless, I will consider it a success as I before this I had neither created anything novel that could be considered a game, nor done anything that wasn't incredibly trivial using javascript.

As the game is now, the player (a purple square) files through the cave (up and down arrow keys are used for movement), trying to avoid the cave and the enemies (which are yellow squares, I will call them "ghosts" on account of the fact that they can move through solid rock on account of laziness for generating smarter movement), and the player accumulates score as time passes and additional points as enemies go off screen, enemies spawn more frequently as time progresses. The player also has 2 special "weapons": an invisibility/invulnerability cloak activated by pressing '1', and a turbo activated by pressing '2'.

tl;dr: controls are up/down arrow keys for movement, 1 for invisibility cloak, 2 for turbo.

game is here: https://dl.dropbox.com/u/34972177/game.html

As something that could be called a game exists, I will call this more successful than my last game jam attempt. In the future, the following things may or may nor be implemented/fixed:

-A bug where the player randomly dies from "colliding with the cave" without actually colliding with the cave some times (DONE)

-Somewhat smarter/potentially varied enemies.

-Better enemy spawning speeding up method (DONE)

-Graphics that are slightly more detailed for player/enemies

[Nigel] Ending early. Presenting: Disorient's scraps.

Yep.

http://tinyurl.com/c2rd9db - Download it here. If you happen to have Java 7 installed, it probably won't work. (A fun feature of the game library I used.)

So ultimately, I only able to create a "thing". In this "thing" you can do the following:

• Walk around a randomly generated map.

• Shoot at nothing.

• Spin around as fast as your mouse can move.

• Use your scroll wheel to fancily change your weapon slot.

• That's it. 

I couldn't get bullet-enemy collisions to work. This is probably due to my shoddily made collision engine. Next time, I will be sure to use something like Box2D to save me the pain of having to debug a collision engine.

So yes. I now (somewhat) know what game programming in Java is like. I need to practice more.

[Philippe] Done! Presenting: Constellations

Hello everyone! First of all, I apologize for not providing continuous updates. I needed to finish the Game Jam before tomorrow (Sunday) so it was a bit of a hustle getting everything done. However, I can finally say that I have finished my game, and I am quite proud of the result! Here are some screenshots (with minimal spoilers!)

 

 

 

Here are the features included in the finished product:

1. 5 Puzzles, each featuring multiple solutions and detailed feedback on incorrect solutions
2. 3 unlockable Challenges, some with solutions, and some without
3. Detailed instructions on how to play the game
4. Support for iPad and iPod Touch (Theoretically)
5. Includes the following topics: Connected Graphs, Vertex Degrees, Cycles, and Bipartite Graph

My idea behind the puzzles was to give the player the opportunity to explore the ideas of graph theory through touch-based challenges. Most of the puzzles feature multiple valid solutions, and players are encouraged to try and find different ways of drawing graphs. In doing so, I hope that the player will notice patterns that lead them towards general conclusions and insights. The unlockable challenges were my attempt at encouraging the player to seek mathematical certainty. Since only some of the challenges are unsolvable, the players must convince themselves that a challenge has no solution; the game will not tell them. This forces the player to find reasons to support their claims, which are the makings of a Graph Theory proof.

Some challenges I faced along the way:

• Writing algorithms to check solutions was especially hard. Since I wanted to allow for multiple solutions, I couldn't just compare answers to stock solutions. Instead, I wrote algorithms to test whether graphs were connected or bipartite, and then used these functions to provide feedback in the game. The bipartite algorithm in particular was challenging, and I had to go through multiple iterations before I was confident that my it worked the way I wanted it to.
• I had limited space in the game to explain topics and puzzles clearly, and it was especially challenging choosing the right words to make my message easy to understand. I had my family and friends playtest the game and give feedback, which I then used to improve upon my explanations.
• Although I coded methodically, I did not comment sufficiently until the very end, which made my code very convoluted. Going forward, I want to make commenting second nature, so that I don't end up with a jumbled mess in the later stages.

My goal for this Jam was to make a complete, self-sufficient game. In my previous creations I always focused heavily on the mechanics, and had to explain the controls and goals in person. Constellations features a detailed explanation of the controls and puzzles while also boasting a fully-functional user interface. While I had to cut back on many of my original goals, the final product feels like a real, publishable game (even though it only lasts around 30 min!).

Here is the link for the game! I made it using codeheart.js, so to play the game simply open the play.html file in any web browser.
https://www.dropbox.com/s/1wj2ixmhh9h7xns/Constellations.zip

Good luck to the rest of you; I'm looking forward to trying everyone's games!

--Philippe Demontigny

[MM] More objects, better placement

I improved the object placement algorithm and expanded the set of objects in the world. James Ernests' spy card game has blueprint-like plans for traps.  I started experimenting with making the board look like a blueprint, but stopped when the nice contrast of a relatively matte blue board looked good against the colorful tokens and white item chicklets:

The largest improvement to the object placement algorithm is making it check both ways: Does the new object occlude any existing one?  Does any existing object occlude the new one?

The server can now render cards for items dynamically and display them on the mobile client controllers. "Arthur Daniel" is the guy in the blue fedora above. Here's what the screen on his mobile device looks like:

Next Steps:

1. Add room on the bottom of the character tokens to display their stats and items
2. Allow the player to actually take the actions on cards
3. Distinguish skills from equipment
4. Refactoring to cleanup recent changes and reduce code size

Currently at 1024 SLOC, including data files (which are in the code-like G3D::Any format)

[MM] Object placement

The game now places objects in a room randomly with the constraints that they be visible to the camera and not overlapping another object.  This keeps the board-game feel without decreasing readability of the public screen:

Those white chicklet objects are what equipment looks like when it is in the world. When a character picks up an item, it will disappear from the world and be displayed as an icon under the character (I need to make a white space for the icons on the character stands). A card corresponding to that item will then appear on the player's private screen.

The only object so far is a pistol. I have a spreadsheet of objects and need to write a CSV -> G3D::Any converter to dump the rest of the objects.

That tile chicklet is the first thing that I ever modeled successfully in 3DS Max.  I created a box and then chamfered the edges to make it look like a real object and create a fine highlight rim.

I need to look at some real-world board games to build a good color palette.  I originally envisioned the entire board as gray and the chicklets as white, but that seems pretty boring.  I might have different colors for weapons, equipment, and props, or color or texture the board differently.

[Edward] Well I call it a game anyway…

OK, so it is pretty crude stuff, but I think this version has all the elements of a conventional shooter game. Health is diminished if aliens hit the base under the player position, when it gets down to zero the game simply reverts to a start screen. Any sort of grenade-alien contact kills the alien and increases the score – no explosions still I’m afraid. I do now have levelling-up when a wave is completely destroyed though. Each new wave adds another alien and the starting velocities get faster, but the score for each alien also goes up to compensate!

Notwithstanding Easter egg hunting and a family lunch tomorrow, I’m hoping I might still do a bit of tarting up of graphics and models before the deadline.

Is anyone else on track to show something playable tomorrow?

[MM] Refactoring

I've surrendered to illness.  I'm going to continue working on the game minimally this weekend because it is better than just lying here contemplating how horrible I feel, but there's no way that I can actually finish.

I put in some time refactoring my program to make some of the prototype elements work in a more "real" fashion. The code ballooned from 500 to 800 SLOC in the process, which makes me a little nervous.  This is code with a lot of threading to handle the network management and I'm also terrified of deadlocks.

The characters visible on the main screen are now actual custom G3D::Entity subclasses, not just visual placeholders.  The NPCs are Characters and the PCs are PlayerCharacters.  A PlayerCharacter is created automatically when a new client connects. The PlayerCharacter has a hand of Cards that are shown on the private display and a portrait shown on the main display.

Next implementation steps:

1. Draw the PlayerCharacters from a queue--right now everyone is the same character!
2. Put actions on cards.
3. Track game sessions and automatically restart the client when it connects to a new one.
4. Put cards into the room.

The gameplay is evolving towards real-time board game play, which is neat. This encourages sneaky actions, too--everything plays out on the main screen in public view, but if you do something during a distracting moment, others might not notice. Design challenges:

1. I need to keep most important stats and outcomes on the main screen. Otherwise everyone would just look at their own screen, which would thwart the shared experience.
2. When a character takes an action, he/she goes into cooldown mode.  How should this be presented in a real-time game to avoid it feeling frustrating, like you're just locked out?  
3. Cooldown times need to be long enough to encourage deliberate, tactical play, but short enough that everyone isn't sitting around waiting at the same time.  I want an asynchronous turn based feel.
4. AI, my Achilles' Heel in every jam!

[Edward] Last jigsaw pieces…

I’ve got the game-specific collision detection and response framework working now – although I need to investigate occasional glitches when my current method seems to miss one, which is worrying (I hate intermittent bugs).

In this video the enemy and grenade objects are responding to each other to ‘recycle’ themselves. The enemy resets 4 seconds after the collision (so we can see it bounce a bit first) and then begins its run in again. The grenade simply resets, ready to be ‘thrown’ again. In the last collision in the vid you can see my current bug – the collision definitely happens in bullet, but for some reason neither object reacts to it. :(

You can also see that I’ve added a tumbling action to the grenade. I think this looks cool (just shooting the cylinder without spin just doesn’t ‘feel’ right) but it also makes hitting things substantially trickier!

I *think* that game-mechanic collision responses were the last major piece of the jigsaw I need to produce a basic game, so now I need to put all the bits together in a coherent way. I’m going to start with recording a score and reducing health level when a grenade hits and enemy and an enemy hits the player, respectively. With these elements in place I can have a complete (if dull) standard game cycle. Assuming that goes OK, I will revisit the physics engine to see about making the grenades explode, as per my original idea, and fix that pesky bug.

I hope everyone else is doing OK - things seem to have gone a bit quiet…?

[Nigel] Oh crap, I somehow got nothing done aaaaaaaaa

Bleh.

Zoomed out map.

• Individual collisions are now implemented. (Player-Enemy, Player-Item)
• At the moment, exactly one brain-dead green enemy circle will spawn at a random location in each room. (Literally brain-dead, AI has not been implemented.)
• A (terrible) random map now generates. You can run around in it to your hearts content.
• The original plan was to have rooms spawn in clusters which can then be color coded to represent needed keys. Time may not allow this anymore. The current implementation is a completely random generation which follows a few basic rules.

I shouldn't have gotten lazy. Compromises must now be made.

Plan of attack:

• Get shooting and enemy death working.
• Make enemies walk towards you while you are in the same room
• Spawn more enemies
• Spawn gun ammo 
• Lock off one room from the player (i.e: exit)
• Hide key somewhere (Perhaps in an enemy.)

At this point, a very basic game will have been completed. A long Saturday is ahead.

[Edward] One step forward, two back…

My general policy of ‘code it first, ask questions later’ has bitten me on the bum this afternoon. Settling on an elegant way to detect and utilise Bullet collision detection in my game components has proved to be as fiendish as I had feared. My first decision was where exactly I wanted game specific collision responses to be resolved. I got hung up on whether to have a single collision resolver class (which had to know about all the relevant pairs of objects and what to do with them) or to allow game objects to resolve their own collisions. In the end I plumped for the latter, which seemed to produce a cleaner structure. I then just cracked on with implementing a technically interesting solution using proper events via Boost::Signals2. This allows a type safe subscription of multiple interested objects to each of my PhysicsObject’s collision events. However, now I’ve spent hours on it, I’m thinking that I don’t really need multiple objects to receive these, and it doesn’t really solve the other problem of distinguishing between the different objects that can be the source of a collision :(

Still I think I might have unlocked the ‘Bletchley Park Achievement’ for the most arcane line of C++ syntax by using a lambda in the subscription code:

m_physics_controller->SubscribeToCollision([&](Object3DPhysicsController* source){OnCollided(source);});

Can anyone top this?

I’m going to make use of SVN now and roll-back 3 hours of my life and re-implement this stuff using a simple ICollidable base class, from which interested objects must be derived.

Ho hum. Hopefully another video in the morning.

[MM] Virtual game board

Here's the current view on the public game screen:

Relative positions don't affect gameplay--characters are lined up jRPG style, with good guys in a line in the front and bad guys in the back.  

I intend to put cards for the objects in the room on the table as well, but haven't figured out how to balance readability of the cards with the virtual game look.  Maybe they'll just be stand-up objects as well and you'll only see the cards with object stats on your private screen.

The client and server can now synchronize game state correctly.  The server sends the client its full state about once a second, so that even if the client drops out for a while it will fully synchronize on reconnection.  I ended up transferring card images over HTTP and sync messages over Websockets because Javascript Images automatically handle asynchronous loading of images over HTTP.

Still very, very sick...going back to sleep now.

[Edward] You may fire when ready…

Morning all! Beer & curry actually has the opposite effect to the ‘recharging’ I had intended and so I only resumed work on the game this morning! However I have been focusing on turning yesterday’s physics ‘experiment’ into something that can become a game by Sunday. This vid shows where I am at now:

This may not look like a massive leap forward, but I’m afraid it has taken quite a bit of work ‘under the hood’ to get to this. I now have a launcher object (and first person camera) under control from either an XBox controller or the keyboard - fixing some input manager bugs on the way. The cylinder you see rendered is also now wrapped up neatly as part of a ‘grenade’ game component object, which also includes the physics management and game mechanic specific data (the details of this still to be sorted out).

You can probably see that I am currently re-using the same object each time fire is pressed. This involves safely removing, modifying and re-adding the object into the physics system – a principle that I needed to nail properly early-on because I will no doubt be doing this a lot to make use of physics objects in normal game play.

Next I need to align the grenade to the launcher when it is fired (at the moment you can see it just keeps its last orientation) and add some ‘enemies’ to fire at. Once these are in I need to tackle the big unknown of how to go about hooking the Bullet collision info to use for my actual game mechanics. Onward and upward…

[Sam] Some Progress

After beginning the jam and getting a couple hours of progress in today (spending about as much time learning how to use javascript, which I have used only very minimally in the past, as using time to make the game) I have finished the one part of the game I was somewhat sure about coming in (making random caves) and I have side-scrolling working also, as shown (at a slower pace) in the below gif:

Next Steps:

- making side-scroll loop infinite (not hard, but it will wait until tomorrow_

- making transition from separately generated portions less sharp (if I have time)

Other things to do:

- Implement actually game elements (a player that flies through the "cave", enemies, interactions between the two, scores, etc.)

So far, it seems like I am posed to be at the very least more successful than the last game jam: I at least have something working, and there is plenty of time left!

[Morgan] Persistent client-server

The client and server now automatically reconnect when disconnected.  I can turn off my iPod and then turn it back on later and they correctly sync.  Here's a screenshot of the server...the Cornell Box is one of the default G3D scenes just to give the renderer something to do,

and doesn't have anything to do with the game.  The interesting parts are the list of clients shown at the upper left and the dynamically-generated QR code on the right.

I use G3D::GUniqueID to assign a unique identifier to every resource in the system, which right now means cards and clients. This allows the server and client to refer to objects without having to deal with synchronizing namespaces.

I introduced a Graphic class that holds both a Texture (i.e., of a card) and the bytes of the message to send to a client to tell it about that Graphic. The server can use this to quickly send images to the clients.  The clients maintain an explicit image cache to avoid allowing the browser to manage it (since browser caches can be very small on mobile), but this has a serious disadvantage because Javascript doesn't have weak pointer class.  Every card is stored as a separate HTML5 image object, so there could be a lot of these in memory at once.

I also refactored the code because the number of global variables that I was accumulating in C++ was horrifying (a side effect of using a C-based webserver).  The full code base is about 500 SLOC, measured by counting semi-colons in the project.

TODO:

1. Have the server send the client a list of the cards it has
2. Have the server display the contents of the current encounter as cards
3. Put "use" button on the active card
4. Make an action on the client have some effect on the server

[Arjun + Dan] Preparation Work

I haven't started any of the actual game work yet, but I've had a lot of fun mucking around with real time javascript editing.

I'm saving up my 30 hours for Friday, Saturday, and Sunday morning.

For now, here's a view of what I'll be working with during the jam.

Hopefully it will pay off when we start tweaking magic constants for the battles.

[Morgan] Better art

Following an idea from Max McGuire from the Unknown Worlds game jam, I used images from public domain comic books at http://comicbookplus.com to improve my artwork.  Each player now has unique background art based on his or her character:

It is really hard to find images of women in old comic books who look like spies or soldiers instead of swooning schoolgirls (or Amazon warriors!)  I think that I can easily get enough art for my characters and cards by just continuing to mine the comic books, though.  I plan to draw weapons and in-game tools as silhouettes on their cards, so that should be easy.  The gameplay has not progressed since this afternoon--I'm just sitting in bed sick doodling on art.  

Next steps:

1. Assign (stable) IDs to clients 
2. Have the server send the client a list of the cards it has
3. Have the server display the contents of the current encounter as cards
4. Put "use" button on the active card
5. Make an action on the client have some effect on the server

[Michael] Start (and Finish?)

So I managed to squeeze 3 or so hours of work in on the game jam today, which might be the most I get :(

Since I did approximately 0 preparatory work (and in fact did some anti-preparatory work by half-implementing depth peeling for ambient occlusion in G3D and left it in a broken state on my local machine), most of my effort was on getting a copy of my last game jam game up and running, checked in to svn and linking to bullet. After that was successful, I implemented the ability to remove asteroids cleanly from the game world and now remove them when they have no health (my old game jam game had health for all collision entities, it just didn't do anything when asteroids had nonpositive health.) Added a score variable that increments with every asteroid shot, screen printed it, and voila, I'm "done" with the game jam.

It gets lonely when you are at 300 points from destroying all 3 asteroids, but continually firing makes for something that looks like art to me.



Level 2 implementation here I come (tomorrow maybe?)!

[Morgan] Multitouch drag & drop working

I seem to be coming down with a bad cold (I propose that we call this "pulling a Nigel" since Nigel got the flu right at the start of the last jam) and had a bunch of day-job work to handle today, so I'm getting a later start than I'd hope and moving slowly.

I just completed drag and drop of the in-game cards on mobile devices.  I hope to make the mobile device look more like...a secret agent mobile device...but for now it shows a briefcase to have at least some flavor.  Players can now connect to the game by scanning a QR code off the TV and then arrange their cards by touch.  Multitouch also works--I'm not sure if you'd want to move multiple cards at the same time, but it does work.  Selecting a card pops it in the z-order.

Not only is this "game" not fun yet, it isn't even a game.  I plan to make some minimal card game (basically, "War" or "Go Fish" equivalent) and then expand it more towards the rules I have planned.

My current design is to much more abstract than I originally envisioned.  Instead of seeing a map of the game, a series of encounters will arise Munchkin-style and the players will resolve them.  The encounters will follow a trajectory based on the mission theme instead of being random.

Coding half in C++ and half in JavaScript is a strange experience.  I have to try to keep in mind which changes require a restart and which simply reload on the fly. Syntax is an ongoing bilingual failure. The file named "G3D.js" might be heresy.

[Edward] Phew! Things starting to look promising…

I’ve finally got stuff on the screen. As always it has taken longer than I had hoped. But I’ve had to learn *a lot* about the structure of Bullet physics, plus fix *a stack* of bugs in my gamelib.
Anyway, this quick vid shows where I am at. The first two clips show G3D primitives which are synchronised with a sphere and cylinder collision shape respectively. In the second two clips you may be able to see some additional line geometry. This is implemented by a bullet debug drawer component which provides bullet with some G3D-compatible OpenGL drawing routines so it can draw its collision geometry directly – I was relieved to confirm that these match my own rendered geometry!

I’m definitely going to need to revisit and refactor *a lot* of what I have written today, but I’m trying to avoid ‘paralysis by analysis’ by just cracking on with coding whatever the first solution is that I come up with! Next on my hit list is to be able to manipulate a cannon object and actually fire some game objects out into the scene using keyboard or XBox controller.
But it is evening here now so first I’m off to re-charge for a bit using a mixture of beer and curry – this is the UK equivalent of the US developer’s staple diet of coke and pizza.

[Nigel] Bare Engine Completed

The player can now do the following:

• Move around; Colliding into the edges of the room.
• Look around; Looking at the cursor.

Also, a couple of basic visual ideas were set up:

• Camera movement occurs only after collision with an invisible bounding box in the center of the screen. This is similar to the implementation found in most 2D platformers. 

While the player is within the box, only the sprite will move. If the player attempts to move outside of the box, the map will move instead.

• This will eventually lead to smooth camera movement. The camera will smoothly accelerate/decelerate when map movement occurs. 

Now to get map generation going.

[Edward] Physics Schmysics

I *think* that I have a functional physics system component & some primitive-shape physics objects updating happily in the game loop… Only thing is, I currently need to use the debugger to ‘see’ any of the action! I’m assuming that new-fangled-modern-gamers will not be too impressed with imagining the scene from text trace statements of object positions (kids today are so demanding), so need to link the physics entities to some ‘drawable’ G3D primitives next…

Machinis Ludo 2 Jam Begins!

Let's jam!  The Machinis Ludo 2 game jam begins today at 10:00am ET  (timezone cheating is endorsed) After that, you have 30 hours to spend until 6:00pm ET on Sunday.

The McGuire Graphics Lab at Williams won't be open this time, since most people are working remotely  for this jam. Dan and Sam are welcome to host if they are here, of course.

To win, you have to make a game. It doesn't have to be the game that you set out to make, the best game in the world, or even a particularly fun game. The goals are to shake up our development schedules, focus on producing something to completion, and try out crazy new ideas that we don't usually explore in our daily work. Along the way, we'll learn new directions that codeheart.js and G3D should evolve in (although you aren't required to use those APIs), find bugs, and come up with lots of ideas for our next projects.  Good luck!

Post frequently with pictures to maintain the camaraderie and help inspire everyone.

[Edward] UK Kick-off

Thursday morning and I was underway at 10:00am shamelessly making the most of my UK time-difference (I secretly intend to blag it in my favour at both ends and hope nobody notices...) I used my VS2010 G3D project wizard to create the blank project successfully, and I have source-controlled everything from the outset - not because I am collaborating, but for those inevitable 'tear it up and start again' moments. Nothing to show but a nice cornflower blue screen and the window frame title as yet:

My existing library is all component based, so my first job is to create some wrapper Game Component classes for the Bullet Physics system, and create a base class for physics objects. To start testing these I need to add them to a Game Screen game component collection, which will ultimately become the main game play screen - all being well!

Good luck everyone. I will report back in a few hours...

[Sam] A Rough Idea

Title: ???
Genre: side-scroller shooting things and such
Platform: web? maybe?
Developer: Sam Donow

After a lack of success during the previous game jam, I will attempt to bite off an amount that I can successfully chew for this one. After having many ideas come to mind that would have almost certainly led to too much difficulty, or simply an inability to fully flesh out an idea, an idea for an algorithm for randomly designing cave-like maps for a side-scrolling game with a flying vehicle came to mind, so I will be going with that.

Though no particular games come to mind, the idea is certainly similar to other games that exist, the idea (as I have it now) would be that the player would be moving with an ever-forward velocity in a 2d-cave like setting, and there will be enemies that try to shoot at you and you can kill to get upgrades to a weapon of some sort.

So, though the idea seems for now to be rather half-baked, I think that I have thought things through enough that, while making the game, holes will be able to be filled and a final product just may emerge.

So, a checklist of things to do (which also may help to make my idea clearer):

- Implement what I have in mind for making the random "map"/"cave"/whatever

- Movement of the player in some logical way such to make the random terrain an obstacle while constantly moving forward, but a manageable one

- A weapon that can become better in interesting ways from defeating enemies

- Enemies that get harder as time in the game progresses


So, in as much detail as I currently have in my mind and totally devoid of images, that is what I am going to try to do, in a nutshell.

[Arjun + Dan] Faster Than Light + Game of Thrones

Working Title: Game of Rogue(likes)
Genre: single-player strategy
Platform: HTML5 web browser
Developer: Dan Fast and Arjun Narayan


Arjun and I are both gigantic fans of Faster Than Light and Game of Thrones, so we're going to try to make a game that mixes the two together. Of course, that's far too big for a game jam, so instead we're going to try to make a single battle instance of the game.

+

Game Concept:

Armies battling each other for a castle. They primarily move around heroes, who control troop flows. The goal is to take over/defend the castle.

Heroes:

Heroes change the attributes of nearby troops (morale, damage, health).

Heroes act as barriers, preventing the movement of opposing troops past them, but take damage.

Heroes can act as sources, creating new troops (these Heroes are referred to as Generals).

Heroes act as sinks, attracting enemy troops (also Generals).

Heroes operate special rooms, like moats, ballistas, treasuries, ravens, greekfire.

Castles:

The castle is the main environment. Underlying the castle is an undirected graph with edge capacities that troops can flow through. The graph can be changed in real time thanks to seige weaponry, fire side effects, or other stuff.

Castles guide troop movement and fire movement.

Castles have special rooms with special features.

Troops:

Troops are like fluid. They are created at a source and move around until they meet a sink. If a sink is “filled” to capacity it “breaks” (that mini-battle has been won). This creates a tipping point effect that cascades to the end of battle. The main challenge is an elaborate “dance” as the two sides respectively try and break sinks/keep the sinks from breaking.

Ex)

Troops have the advantage when moving from HIGH to LOW ground.

(Think of this as a positive increase in the edge flow capacity)

Barriers are temporary sinks (think buffers) on nodes. Heroes can act as barriers at HitPoint cost to themselves, or erect barriers (take time to construct and have a set capacity/damage limit).

Fire: 

Fire is like fluid. It is create at a source and moves randomly. Importantly it moves on a different graph to the troops. (adjacency without regard to walls, can cross floors and go directly up)

Fire has the advantage moving from LOW to HIGH ground.

Fire destroys barriers.

Fire affects the castle

Heroes can launch fire

Morale:

Wonder how to model morale. Maybe it is a hero stat like HitPoints?

Game Flow Summary:

A battle begins with the player moving their heroes and generals around their siege equipment. This stage will be removed in the larger rogue like game, as it will happen at the end of fights or at some other point in time. 
Once units are positioned, we launch the battle. Troops are generated at some rate and with some upper limit. The battle stabilizes as troops hit barriers, either doors, walls, the other front of troops, or a hero. Heroes disrupt stable borders by breaking morale. Fire disrupts stable borders. Key rooms (away from the normal flow of troops) also change the borders by mutating the environment. 
Hero micromanagement increases as they take damage, although they can fall back behind lines to heal. Falling back breaks moral however, and moral falls over time. Therefore, the offensive force has a limited amount of time to push forward.

Look and Feel:

We are copying the style of FTL at the moment, but from a cutaway side perspective instead of a cutaway topdown perspective.

Basic Goals:

- JSON representation
- Programmer art
- Undirected graph of castle
- Troop movement and flow
- Heroes
- Victory / Defeat based on killing all opposing heroes

Intermediate Goals:

- Castle art
- Troop art
- Hero art
- Fire movement and flow
- Mutating castle environment

Advanced Goals:

- I can't even imagine these right now

Todo list

I'm gonna work on a scripting environment to speed up the development process. Javascript IS a scripting language, might as well take advantage of it.

Tools

- github
- ace in browser editor
- codeheartjs
- angularjs