xg - post-jam polishing

I spent a few more hours last night and tonight making and adding to the game various image assets to polish the UI. I also tweaked the scoring a bit and made a few other UI dynamics changes (e.g. the avatar reach is only show when placing a charge or within reach of something that can be picked up / moved). It looks MUCH better, and the various images make the play much more intuitive.

Finding and/or making and.or adapting those images is a seriously time consuming, finicky process. In retrospect, glad I decided to skip that and use simple placeholders for the jam time limits. However, post-jam it has paid off to have spent a bit more time during the jam making sure it would be easy to insert images and animations later - that kind of thing is a pain to retrofit.

Still need to get a real image for the flag, figure out some better background images for the various control areas, make a decent rectangular button image, and so much more... but not tonight.

Sam - "Final" Post

After many trials and tribulations, the concept for my game (4D pong, which in theory was to have cool features with manipulating time and such) did not really come to fruition - I got a lot more familiar with G3D as a platform for designing games, and will be more capable next time around, but at the end of my work today I managed to make 2 paddles with movement and a ball that bounces between them, so I got somehow. Congratulations to everyone who "won" the game jam, and good luck for any who are still working. I may at some time return to my game and make something finished out of it, but that is highly unlikely to happen before the games are to be presented on Tuesday.

ATMS - Cameras and Audio

I brought the tutorial camera down closer to the ship to be more cinematic and then added and tweaked audio.  You can now tell the wind direction and relative speed from just listening with stereo headphones.

- Only show tutorial messages on the chaseCamera
- Clean up directory structure
- Isolate dependencies so that the game can be distributed standalone
- Make the pause menu cancelable
- Finished sailing tutorial (10 gates, all points of sail and controls)
- Fixed reflection rays going offscreen
- Point wind arrow  on compass INTO the boat
- Battle-cam (top) vs. sailing cam (low)
- Pan wind sound left to right based on heading
- Adjust wind sound volume based on apparent wind velocity
- Play a sound when crossing a gate

The tutorial is now done and fairly polished.  Next steps:

- Cannons!

  - Ball entity creation

  - Parabolic arc

  - Destroy on hitting terrain || water

  - Sound effect

  - Create splash in water

  - Detect collision with building

  - Particle trails

ATMS - More UI work

I'm continuing on and will probably have a more interesting game by Wednesday, hopefully with multiplayer. This afternoon was lots of UI work to improve controls and instructions.

Done:

- Title/menu screen tuning
- Remapped keyboard keys: ASD left stick, +- right stick, arrows are D-pad, and ESC is START
- View controls
- Pause menu
  - Resume
  - Restart mission
  - Abort mission
- Menu drop shadows
- Move programmable pipeline drawRect2D to G3D
- Move signedPow to G3D
- Add G3D::Scene::remove and override in World to support object destruction
- Allow choice of gates in tutorial
- Tutorial popup text boxes on gates

Next:

- Finish sailing tutorial

- Point wind arrow INTO boat (thanks, Chris)

- Targets (anchored ships, shore targets)

- Cannons!

- Abstract everything about the player, to enable splitscreen multiplayer

  - e.g., player1Ship

  - add a Player object that the ship references

  - make tint/materialpose a property of the player

The Finish Line

The INNOVATE 2013 jam is officially over!  About half of us won the jam and all of us clearly learned a lot. Many of us are close enough to keep going a bit and polish before the closing party, including I think me, Mike, Nigel, and Sam.

Please post a link to your game here or e-mail download instructions to everyone if you don't want to publicly distribute it.  I'll start a summary post with an image of everyone's game...just edit that one to add the description of your game.

We'll have the wrap party to play each other's games Tuesday 3pm-5pm in TCL217 (Corey and Dan will have to participate vicariously).  That's during the first lab session for CS/ARTS 107: Creating Games, which means that students from the class can come by as well.

Mike and I should be able to run our games from of our laptops, and all of the web games can run off lab computers. We'll set up logistics for the rest by e-mail.

This was a lot of fun.  Thanks to everyone for participating.  I'll host an INNOVATE summer jam as a followup.  Post comments with what you liked or would change about the structure of this jam.

Corey - Won't Finish Tonight

I'm afraid that I won't be contributing a working game tonight.  I ended up wiping my design and restarting this afternoon with something else.

My previous puzzle design had too many possibilities.  I was struggling to figure out generic parts to build.  I knew I wasn't going to put in anywhere near 48hrs so it was a poor decision to choose a design that required the extra pre-production.

I see many final updates which is very encouraging!  It seems I've relegated myself to the systems engineer class of developer over the years.  Perhaps, I'll be effective at making games again ... one day!

Dan - Post Mortem

Well that was fun. 

You can play the game HERE and source code can be found HERE.

The game is hot seat, so first player controls the left hand character, second player controls the right hand. 

Each player takes ONE turn at a time.

Pressing the FIST fires an attack (after a short delay).

DRAGGING your character makes them jump around.

Clicking the timeline changes the time in the game.

 I couldn't program in an end game check, so if it looks like there is nothing left for you to do, that's probably the case. Victories, however, are fleeting... someone may change the past.

Extra: There are bugs. I had to resort to mutation when dealing with the time travel collisions, sad times. Anyway, that led to bugs. I'll try to iron them out in the future.

Michael - End of Game Jam Report

• Projectile rendering vastly improved.
• Health bars (not picture)
• No more negative health
• Sounds(!)
• Improved collision detection

More details to follow once I rest.

Jonas - Conclusion

It works! It's not a finished product and it turned out more like an exploration game than the epic man vs. sea creature duel that I envisioned, but you can swim around and shoot things, which is pretty cool by itself.

I gave up on a realistic cave generator after spending a good five hours trying to get unity to generate its own meshes. Day two was spent creating a new system to carve caves out of a dense 2d field of columns. Day three accounts for most of the gameplay elements, namely swimming around, turning a flashlight on and off, and shooting harpoons into walls. Sadly, I had no time to implement any sort of enemy whatsoever before the time limit, but I plan on adding one in the future along with some sound effects and bubble particles.

Here it is, just before the time limit: https://dl.dropbox.com/u/23521465/Core.zip
(a/w/s/d/arrowkeys to move, left mouse to shoot, right mouse to change item, escape to pause)

Philippe - Final Report

I have completed my goals for the weekend, including some playtesting, and hereby announce my submission to the 2013 game jam complete! I'm looking forward to you all helping me break the game later this week, but in the meantime, here are a few screenshots!

As I mentioned earlier, I am no artist. But I've grown rather fond of the circles and squares in my game. In the last picture you can see all the major players: (from left to right) Ammo Drop (Light Brown), Wolf Zombie (Brown), Fat Zombie (Large, Gray), Green Zombie (self-explanatory), The Player (Blue), and a Normal Zombie (Small, Gray). The black squares are obstacles that are generated randomly on each play-through, and the light blue area is the player's attack range.

I've had a lot of fun doing this game jam and I look forward both to playing everyone's game and to continuing to add content to my own game. Good luck!

XG - that's a wrap

Spent the last 1.5 hours improving the UI a bit (more info, prompts, etc.), adding simple instruction/help info, and fixing a couple bugs. Calling it done for the jam - I've uploaded the latest version.

I'm definitely planning to continue work on this after the jam is done, but not at quite the same pace :)

Hoping to swing by the graphics lab in a while to see the final frenzy :) Any particular dinner plans?

Moving to Hawaii Time

I'm switching to Hawaii Time, which is five hours behind ET.  This gives me a five hour extension, allows me to pretend I'm not freezing cold, and encourages playing of the Magnum PI and Hawaii 5-0 theme songs.

Some quick gameplay footage. So much work to do still! Right now the GUI are just keys, which I want to change to little buttons around the character. Then I want to add some random movement to the opponent because I don't think I can manage to get this networked and running by the end of the hackathon.

Michael - T-minus 6 hours (or so)

Alright, now that I've caught up on sleep a little bit, it's time for the final sprint. Let's revisit my original list:

Follow camera

XBOX controller free roam space-flight

Brakes/boost system

Simple Projectiles

Health system

Move to 3-Torus (!!)

Minimap(!)  (Decided against it's inclusion)

Split-Screen  2-person Multiplayer

Particle System / shaders to look better

Homing secondary projectile

Completely hacked together network multiplayer

Powerups

Make everything look good

Not bad. My new list looks something like this:

• Improve collision detection (build a Tri-Tree for the asteroid?)
• Fix lighting (weird behavior when looping around torus)
• Draw projectiles in a sane way (and make it look good)
• Swap in better models
• Make secondary projectile heatseeking
• Better health display
• Better victory screen
• Name the game
• Pause screen
• Auto-restart game after victory.
• Countdown
• Optimize rendering so we can see farther?

Networked multiplayer/powerups/destuctable asteroids/ship building all on the menu for post-game jam.

ATMS - Menus

I've been working on the menus to actually be able to enter and exit the game.  The main menu is now functional, although "controls" doesn't do anything.  It responds to both keyboard and Xbox360 controller #1.

There are also no missions except for the tutorial.  If I blow past the 5pm official jam end I still have hopes of being able to implement splitscreen multiplayer.  My standards are probably too high with regard to my concerns about synchronizing water for network or large-scale multiplayer: Mincraft multiplayer was completely buggy for about a year and that made about $40M in sales at the time.  It is probably OK if my ships tilt slightly the wrong way in multiplayer.  Although, a coder has to have standards...

I have to now implement the in-game pause menu, which is what will allow the player to get back to the main menu after winning or losing the tutorial.

I just added the line of code in App::onInit:

    escapeKeyAction = ACTION_NONE;

This is a sign that the game is becoming polished.  You can no longer quit the program from an arbitrary point by hitting ESC.

Done this morning:


- Title screen
- Generic menu class
- Main menu
- App modes: MAIN_MENU, PLAYING, PAUSED
- Can exit from the main menu
- Can launch the game from the main menu

I'm now entering total hack mode, where I'm no longer trying to architect elements robustly or tweak the appearance of graphics (which is why the main menu is so dark--the text is drawn with the fixed function pipeline and I can't make that bright enough to bloom).

XG - .01b done

I've got a working game! Of course, it falls far short of what I'd like it to be in many areas (graphics, sound, various mechanics...), but it's completely playable (for its one extremely simple hole) and gives you a score and everything. I did take the time to add a few UI enhancements - e.g. the charges now show how big the explosion will be (both in the caddy and when placed), which makes it much more playable.

For now, I give you Explosion Golf v .01b.

I think tomorrow I'll try to add a couple of sand traps and then make the terrain affect movement and ball bounce.

Time spent this evening: 3.5 hours
Time remaining: 1.5 hours

Forecast: sleepy

Michael: Game Jam Beaten

I have a working game done, with over 17 hours to spare! Pretty much every aspect of the game is rough around the edges, from the wonky control scheme, to the placeholder projectile graphics, to the shoddy winning screen, to the lame score display, to the complete lack of sound, to the very strange and inconsistent collision detection, to the need for two XBOX controllers to be plugged in for anything to run properly.

However, I have a multiplayer split-screen game with winning conditions. I declare victory and will set aside tomorrow to polishing the roughest parts of my game (and naming it, perhaps).

Morgan - Title Screen

My game is called "A Thousand Moonlit Seas", which is the ending phrase from a poem I wrote to run during the title sequence.  Above is the title screen that goes behind the main menu.  It is live and 3D, with water ripples reflecting the title and moon.  Here's the animation:

The font is Fell English SC (open font license), which I've been using for my design doc.  The two ships in the harbor are the ships from the game with the sail meshes removed, and the dock is the in-game dock model as well.  

In the distance you can barely see a house and lighthouse on one of the islands.  I generalized the game renderer and simulation enough to be able to handle scenes like this, where there are no player-controlled ships.  The ships in the harbor are not regular in-game Ship instances because I haven't simulated anchoring yet--if I used real Ships, they would drift away!  The moon is a photograph of the moon from NASA, mapped onto a quad and placed in the scene.  If I move the camera, you can see how this is all set up to look right just from the one viewpoint:

Now, back to actually making the game...

Michael: Split-screen (almost)

The depth buffer doesn't seem to like what I did. I'm off to debugging!

Michael: Multiplayer

Multiplayer on the same screen. I will be forking my game at some point to flesh out an asymmetrical version, where player 2 has to play like this, from player 1's perspective, but in return gets a stronger craft.

Corey - Level Concept Intro

So, I've realized that I've bitten off a lot when it comes to level design for my game.  My options for environment ideas made it really difficult to come up with ways for the user to play.  Instead of messing around with all of the level options, I decided to narrow it down to some basic movement and priority choices until things are ready to expand.

The goal of the game has also narrowed down to a room or level escape.  You have to guide your avatar towards the open tile.  As UI/display was not my main concern, we're going to deal with grids and icons/sprites until much later (unlikely to get much attention).

I give you the intro tutorial level design.  This actual level may change in the final release if I get to spend time working out the balance between options and environment.  Keeping it simple allowed me to actually progress in development.

Here is how you would read that layout.

• Orange - User's Avatar
• Arrow - Facing direction
• Light Gray - Wall
• Green - Open Tile

None of the environment tiles have any reaction.  The only property for the wall is it prevents the avatar from moving forward.

The user is given these choices for movement:

• Move 1 tile at a time
• Move the entire length open at a time

The user is given these choices for movement:

• Move left or right into open space first
• Move forwards or backwards into open space first

It's very simple, but perhaps so is the point of a intro/tutorial level.  I don't have a fail condition set so the user could loop endlessly in places or randomly hit the goal.  That's fine for some puzzles/levels although perhaps a repetition limit should be set.  The next few tutorial levels would include title types that have fail conditions such as not being able to move forward.

Corey - Most Uninteresting Update

I was feeling left out of the freezing cold up in the gfx lab, so I decided to snag the points for most uninteresting screenshot.

I hope this clarifies my confusing puzzle rules and game mechanics laid out in chat last night.

Morgan - Victory Screen

You win a game jam if you make a game...we hope that everyone will win.

I just completed execution of my backup plan, which was having a "race" game in which you sail through some gates in order.  This might make a nice sailing tutorial level for a full game later.

In the video below the ship sails through three gates and the game then displays the victory screen.  So I'm now guaranteed a technical win on the jam. 

Now on to more interesting features:

- Time/points
- Get unstuck when run aground
- Choice of gates
- Appropriate sounds
- Title & instruction screen
- Ship roll with waves
- Targets (anchored ships, shore targets)
- Cannons!

Completed in this session:


- Added wind sounds
- Added knotmeter to compass
- Detect hitting the gate
- Change gate material when they are traversed in the correct order
- Change G3D to use fully-qualified mesh names in the material pose table

- Implemented running aground

- Winning and show win state

Michael: Toroidal Rendering

Toroidal rendering works for the most part, though I need to tweak my culling to be correct and optimize the rendering for regular object and projectiles. I'll tweak that a bit now, but next up is the minimap. That'll be a design challenge.

Hi Everyone,

I'm Erica Moszkowski, a sophomore planning to major in CS and Econ. I took Creating Games (CS/ARTS 107) with Morgan last semester. I'll be working with codeheart.

For a while, I've been interested in the idea of creating a puzzle game - so here's my opportunity! I'm drawing inspiration from games like Rush Hour, Tetris, and Cut the Rope, since those are games I like to play (but, obviously, my level design is going to be much more primitive for now). I'll be implementing piece-placing mechanics as well as an environment that presents time challenges to the player. Each level requires the player to keep a flame alive by protecting it from rain, wind, falling objects, and lack of oxygen.

I'm primarily concerned about level design, since I have absolutely no experience designing playable yet challenging puzzles. I'm planning to start by implementing very simple puzzles, with the hope that I can combine mechanics to create more interesting ones.

Here we go!

Lab || Gmail Party

We've been using a running gmail chat session.  If you're logged into gmail, just IM anybody else to get invited to it (I'm not going to post everyone's email address here!)

Here's the view from in the graphics lab right now (come on down if you're on campus).

Mike rocking the spaceships. The big screen behind him shows the
blog with an autohotkey script forcing it to reload every minute.

Michael, knee deep in Java.

Erica arrives

Morgan, writing this blog post.  Recursion!

Philippe joins us, deep in thought.

Michael: Now to the fun part!

I have some not-completely-wonky free-flight controls, an okay placeholder camera system, placeholder graphics everywhere, and a fairly powerful weapon system that allows me to reload parameters from files on the fly (ideally, there are some kinks). Now to implement the fun part: moving everything to a 3-torus.

Morgan - Gates

I'm very close to having a playable game.  The gates are in for a solo race against the clock game, but I still have to make them correctly track traversal.  If I can quickly work around some of the bugs that I'm stumped by right now then I should be able to complete a basic game and start working on more interesting parts, like actually shooting cannons at targets instead of just sailing alone.

Sailing through the gates, with a small cluster of houses on the hill at left.

Accomplished tonight:

- Draw water everywhere in the world to help with coastline tuning
- Set up Photoshop for heightfield rendering
- Model the world
   - River
   - Islands
   - Add buildings for scale and texture
- Place gates in world
- Show gates on minimap

xg - BOOM!

Well, things are exploding, in a good, intentionally-when-I-press-the-BOOM!-button way.

It doesn't look like much on the screen shot, but that orange circle is the explosion from one of the 'driver' charges, and the white dot to the right of it is the ball, which is moving from the kick the explosion gave it. It took a while to tweak the numbers so the ball speed decays appropriately on bounces, and I stuck some data in ball movement that won't be used until later features. I definitely had to stretch my brain a bit to figure out the various vector math, but I think it's OK at this point (the physics definitely falls in the emulated rather than simulated realm).

Once it was working, I lost some time to moving the ball around with explosions :) It's certainly possibly to queue up several charges with time delays to give the ball multiple kicks in a single detonator press (i.e. 'stroke'), but it turns out that it's actually pretty difficult to guess times and distances off the cuff - this game has a lot of room for skill development.

With this done I can definitely get a playable, though limited, game working by the end of the game jam. I'm around step 30 on my dev plan (with a bit of bouncing around the order), and the minimal game emerges around step 35. Once I'm at that point I'll have to decide between implementing more game mechanics or adding prettier assets (images, sounds, a help/directions screen,...minor things like that...). Which way I go will depend on what kind of mood I'm in when I get there, but I give it 2:1 odds that I'll end up working on the mechanics - I expect the kind of assets I can create and use/implement in an hour or two won't greatly improve the play experience.

time spent coding this evening: 2.5 hours
jam time remaining: 5 hours

forecast: BOOM!

Morgan - Designing the World

Mike convinced me that I should continue using Photoshop instead of making an in-game terrain editor, so I'm painting the heightfield for the world in Photoshop.  The loading time for a game scene is only about 1s, so I'm just reloading the entire world rather than making the heightfield (a G3D::HeightfieldModel) hotswap.

The current heightfield for the world. This is a mixture of a
distorted real-world map of the Caribbean and a lot of
Photoshop Render Clouds filters.

Here's a neat trick: with two filter levels, Photoshop can be set up to show clearly where the waterline will be on this heightfield, making it easier to shape the coastlines.

Here's the world seen from above, oriented to match the view in Photoshop:

And here it is after an hour of editing:

Debugging shot taken while flying low with the free camera.

Michael: And so it begins...

First note that I am in the GFX lab until late tonight and will readily welcome any game jammers.

Now:

My "Design Document" (if you play fast and loose with that definition):

Multiplayer Space Dogfight Game, played on a 3-Torus. Inspired by Star Wars Rogue Squadron III, and old F-22 flight simulators I played growing up.


3-Torus: A cube with identified faces, analagous to a square torus in 2 dimensions. Two sides with identical labels in the figure are *exactly the same position in space*. Kinda like pac-man: if you go off the left side of the screen, you come in the right, except for 3 dimensions.

Wishlist in rough priority order

• Follow camera
• XBOX controller free roam space-flight
• Brakes/boost system
• Simple Projectiles
• Health system
• Move to 3-Torus (!!)
• Minimap(!)
• Split-Screen  2-person Multiplayer
• Particle System / shaders to look better
• Homing secondary projectile
• Completely hacked together network multiplayer
• Powerups
• Make everything look good

Simple right?

Battle of the Minds - Art Assets

Sadly, I didn't get a chance to look at the codeheart source, that's going to slow me down a bit. In the mean time though, here are some art assets.

The images used for gameplay are below.

1. attack below
2. attack right
3. attack up
4. jump
5. stand

 The images used for scenery are below.

Finally, a quick mockup of what the scene might look like. The two kids would transition in and out of the scene so as not to be a distraction once their imaginary fighting starts.

I've got to work on the contrast a bit, it's a little hard to see the fighters. 

Suggestions and critiques welcome!

Hardcore48 Starts

It is 5pm Friday, so the Hardcore48 track has begun.  We officially end Sunday at 5pm ET.

Mike will be in the Graphics Lab most of the weekend with the blog on the big screens.  You're welcome to come in any time and work there for camaraderie.  Please post frequently so that we can see what everyone's up to.

Good luck everyone!

Dan Fast - Intro

Hi, I'm Dan Fast, a Williams College Alum and a previous graphics lab kid. I focus on k-12 education technology, worked at a nice little startup called Memrise, and am now developing educational games on my own dime. This jam sounded like an awesome chance to see what Williams students have been up to and to work next to some great programmers (although I don't think I'll be able to make it up to Williamstown).

I'm afraid my C++ was never very good, so I'll be working with javascript and codeheart. It also takes me a while to get into a coding groove, so the 48 hour challenge sounds like the right way to go.



As for the game design.

I have been obsessed with the idea of timelines in games after learning about the simulation loop oh so long ago. I want to design a fighting game (like street fighter) where instead of each player choosing actions in real time, they instead inject their actions at any point into a timeline. Each player has a limited number of actions (10?), players make actions simultaneously and cannot make a new action until both have moved, actions can invalidate future and previous actions (but precedence goes to the earlier action). 

To speed up development each player is going to use the same fighter. To make the limited number of actions more viable (and to borrow a note from Dota 2, my one true love) each action will have a long cast time and refresh time. Health is going to be low, maybe even one hit to kill, because dying doesn't actually mean the end of the match. The player could theoretically inject an action earlier in the timeline to avoid or invalidate their death. 

The only action that doesn't really fit into the timeline view is x-axis movement. This action is continuous, which kinda sucks for the whole design scheme. Instead of continuous x movement, I'm going to try letting the players teleport to x-locations for their movements. I don't know if it'll be a step function between x-locations, or linear, or whatever just yet, going to test and see.

Concerns

I'm having a lot of trouble imagining the game play. Balance is going to be a serious issue. Maybe the players will just dodge each other the whole time.  Maybe a dominant strategy will appear immediately. The GUI is going to be horrific... I would love some thoughts on the matter, but when it comes down to it, what better way to spend a weekend then to see what happens?


Story

I have spent a lot of time teaching little kids lately. Have you ever seen two boys get into an imagination fight? 
"I use my laser gun on you!"
"Well, uh... before you used your laser gun I turned on my invulnerability shield"

Plan

I have 5 hours to make some assets and to familiarize myself with the codeheart code base before the hacking starts. After that, it's all timeline and GUI work.

I hope to see a lot of blog posts and Google Hangouts. It'll be great to have some other hardworking programmers for inspiration.