Saturday, August 10, 2013

Project Euler Language Challenge Blog

As was suggested, I made a blog for my continued work on the Project Euler Language Challenge, with an introduction, a table of my progress, and my first additional problem solved.

http://pelangchallenge.blogspot.com/

[MMc] Random Ship Designs

The jam is long over (and I lost!), but I'm having a good time following through with the random spaceship generator for Starlight 2:


Congratulations to Sam, Dan, and Mike, who all clearly scoped their impressive projects well and won the jam!

Friday, August 9, 2013

[Sam] Victory

With 4 minutes to spare, I reached my goal of 20 project Euler problems in different languages in 24 hours. I learned a lot of languages, some real, some not so real - but overall this was very fun, and I may try to extend this challenge to more (esoteric) language over longer stretches of time.

[Dan] Rasterizer Hindsights

so here at the end i have found some interesting issues things out about my rasterizer.

[MMc] Multiple ships

Multiple ships in Starlight 2, with detail views shown in popup windows.  30 minutes until the deadline.


[MMc] Modules and hexification implemented

Starlight2 can now properly construct a legal (but stupid) random ship from an image. Now it is time to interact with other ships, initially in combat. The time alotted for this is specifically 75 minutes, since the jam ends at 3pm today.

A Randomly-Constructed Ship
  1. Build GUI infrastructure for popup ship windows (equivalent to the main view in a traditional RTS)
    1. Window render
    2. Window draw
    3. Window resize
    4. Window close
    5. Zoom control
  2. Ship View inside the popup windows
    1. Draw ships (with zoom and pan)
    2. Show modules as plain hexagons
    3. Right-mouse pans view inside of a window
    4. Render module icons
    5. Find the module under a mouse
  3. Draw main view that shows a "realistic" universe (equivalent to a minimap in a traditional RTS)
    1. Integrate starfield prototype
    2. Overlay GUI
    3. Show ships
    4. Show free modules
    5. Draw paths
  4. Main view interaction
    1. Zoom control
    2. Right mouse pans
    3. Support selection of ships
    4. Provide waypoint GUI
    5. Warp-drive
  5. Modules & interaction
    1. Make hexification symmetric
    2. Drag within ship
    3. Drag outside ship
    4. Drag inside ship
    5. Click to activate module
    6. Target modules in other ships
  6. Simulation
    1. Compute dynamic commodities, e.g., heat, power, etc.
    2. Simulate attacks
    3. Trading (needs more GUI)
  7. Polish graphics
    1. Starfield background pan and zoom
    2. Per-user color
    3. GUI stylization: bloom, noise, ripple on hit
    4. Re-coloring of ships
    5. Clip module view to the actual window bounds
  8. Polish UI
    1. Clip the mouse to the window when panning, or hide the mouse and allow it to go outside


[Michael] Victory!

After a sleep that did not last long enough, I quickly refactored my code to compute and store only the form factors for a single patch at a time (which requires O(n) space as opposed to the old O(n^2)). This slows down computation, since we have to recompute form factors every bounce, but makes large scenes able to not take over my entire hard drive.

I then spent some time fixing bugs and debugging scenes. Note to everyone: Dabrovic Sponza has pretty awful tesselation, don't use it at all possible. But anyway, I changed one of the doors in Dabrovic Sponza to emit lots of light and let my radiosity solver run on a course tesselation for a few dozen seconds (it did direct + some of the first bounce indirect in that time frame), giving me:
I'm going to try on Crytek Sponza; then profile and do the easiest optimizations possible before 3. But I ran radiosity on Sponza and had a soft lighting image in <1 minute; so I win!


[Sam] Steady Progress

7 left, with 4 languages I really know left.
One lesson I have learned in the recent problems: I used up J far too early.
Anyway, now I am more so in "learn cool/interesting/reasonable language" mode than the "do crazy things" mode, on account of time...but Shakespeare and INTERCAL are still in my mind for future use if I get my 20 done.

Problem 11: PHP

Find the largest product of 4 adjacent numbers in a 20x20 grid

This wasn't too bad, other than PHP being hard to debug and me forgetting to put $'s on array indices.

https://dl.dropboxusercontent.com/u/34972177/PELC/e11.php

Problem 12: Go

Find the value of the first Triangle number with > 500 divisors

This language was, for once, fun to work with

https://dl.dropboxusercontent.com/u/34972177/PELC/e12.go

Problem 13: Common Lisp

Find the first 10 digit of the sum of 50 large integers

This was trivial in Common Lisp, though it could be hard in other languages...so I went with the trivial solution.

https://dl.dropboxusercontent.com/u/34972177/PELC/e13.lisp


[MMc] Module Design

I've been working on the programmatic design for the elements of the ship. Modules consist of up to seven hexagonal Features, themselves arranged in a hexagonal shape. Features have no variable state beyond their identification (i.e., they are enumerated values). Modules are randomly instantiated into the universe and are indivisible once instantiated. They can be damaged and torn/ejected/blasted from ships (and repaired), but can't be fragmented.

A module generates a mask for itself that is used for rendering borders and other effects. Because modules are rendered in computer-display style, it is appropriate that damaged modules use the mask to render "television static" noise patterns over themselves, as if the signal were breaking down.

Features are represented by icons.  There is a generic, useless Feature (let's call it CORRIDOR) that dilutes the value of a Module.  Some compound Features, such as ARMORED_THRUSTER, disproportionally enhance the value of the Module containing them.

Weapons can only target border tiles in a ship, so there is an advantage to packing them tightly and using armor on the periphery (this is intentionally analogous to walls in RTS games).

Some features have area effects, such as SHIELD and CLOAK generators.  One must use multiple instances to cover a large ship.

It is raining quite hard. Several motorists do not understand correct etiquite/legally required maneuvers at crosswalks, such as pausing their headlong rush to a damp collision-induced grave long enough to admit a pedestrian to cross, much less not drenching said pedestrian as they hurtle past unminding and, quite likely, unconscious in any higher-order neural sense. Nonetheless, I reached lab without (new) physical injury.

[MMc] Panning and Zooming

Pan and zoom work on the world map and in ship windows.  I had to add some extra hooks to G3D to support processing mouse events directly on a GuiWindow.  Usually we process events on GuiControls instead, so this case had never occured before.

  1. Build GUI infrastructure for popup ship windows (equivalent to the main view in a traditional RTS)
    1. Window render
    2. Window draw
    3. Window resize
    4. Window close
    5. Zoom control
  2. Ship View inside the popup windows
    1. Draw ships (with zoom and pan)
    2. Show modules as plain hexagons
    3. Right-mouse pans view inside of a window
    4. Find the module under a mouse
    5. Draw module icons
  3. Draw main view that shows a "realistic" universe (equivalent to a minimap in a traditional RTS)
    1. Integrate starfield prototype
    2. Overlay GUI
    3. Show ships
    4. Show free modules
    5. Draw paths
  4. Main view interaction
    1. Zoom control
    2. Right mouse pans
    3. Support selection of ships
    4. Provide waypoint GUI
    5. Warp-drive
  5. Modules & interaction
    1. Make hexification symmetric
    2. Drag within ship
    3. Drag outside ship
    4. Drag inside ship
    5. Click to activate module
    6. Target modules in other ships
  6. Simulation
    1. Compute dynamic commodities, e.g., heat, power, etc.
    2. Simulate attacks
    3. Trading (needs more GUI)
  7. Polish graphics
    1. Starfield background pan and zoom
    2. Per-user color
    3. GUI stylization: bloom, noise, ripple on hit
    4. Re-coloring of ships
    5. Clip module view to the actual window bounds
  8. Polish UI
    1. Clip the mouse to the window when panning, or hide the mouse and allow it to go outside


[Michael] Radiosity!

I modified G3D so that it supports vertex colors throughout the system, and by default uses them to add to the ambient light.

Then I made a mapping from vertices to their adjacent patches, and every time I iterate on radiosity I replace the color at a given vertex with a simple average.



Lots left to do, not the least of which is checking the radiometry. But first I'll continually run it while moving the light source to get a nice video, but then I need to modify the algorithm to allow me to load Sponza. Right now I'm taking the easy way out and computing the form factors for all pairs of patches in advance. This is n^2, so on scenes with a million triangles, this takes 4 TB of space... If I switch to only storing all the form factors for one patch at a time I can reign this in to be reasonable.

I'll start again after I wake up. Good night!

Thursday, August 8, 2013

so i took a little break but have gotten back to work. I have got the basic lambertian shading finished and have done a good deal of optimizations to decrease the time within the inner loop. After profiling i can say that the greatest amount of time is being used to make up for my sloppy way of making sure that my rasterizer can render from any camera position. I pretty much just translate everything into the cameras space at each step. As the render is now it cannot truly render cornell box in real time but is not to far off. Here is a video, while it may seem that it is rendering really fast, that is just the magic of the g3d recorder that takes the video and makes it 30 frames a second.

I will probably work a little bit longer tonight and then get some sleep and get ready for a hard day of coding tomorrow in my attempt to reach real-time. If i fix up the sloppy coordinate conversions and add a better algorithm to determine pixel coverage i should be able to achieve real time. 

Problems 7-10

Some more problems done...now my problems aren't dealing with ridiculous languages, its dealing with the whiplash from changing languages so quickly and getting confused on basic syntax for that reason, and more mundane issues...such as using floor instead of ceiling in my solution for #10, which let one perfect square slip into a list of all primes < 2000000.

Problem 7: Racket/Scheme

What is the 10001st Prime Number?

https://dl.dropboxusercontent.com/u/34972177/PELC/e7.rkt

Problem 8: Eyes

What is the largest product of 5 consecutive integers in <list of integers>

This one was trivially easy just by looking at it...not sure whether this one meets my "20" goal or not, as no programming was necessary

Problem 9: Javascript

What is the product abc of the unique pythagorean triple such that a + b + c = 1000?

https://dl.dropboxusercontent.com/u/34972177/PELC/e9.html

Problem 10: ML

What is the sum of all prime numbers < 2000000?

https://dl.dropboxusercontent.com/u/34972177/PELC/e10.sml

[Michael] Radiosity Update

So I spent the morning and a portion of the afternoon reading different sources on radiosity and implementing a new feature in G3D: automatic subdivision of triangles until a threshold edge length is met by all edges. See it here on the Cornell Box with a threshold of  0.45 meters (all edges are less than that).
The next thing I worked on was the "form factor" part of the radiosity algorithm (described here). It basically describes the fraction of energy that leaves one patch of surface and arrives at another, given that the energy scatters diffusely. I treat each triangle in the scene as a patch, and compute form factors between all patches. I then multiply the form factor by the visibility function (which I treat as 1 or 0 for now, depending on whether the center of the patches are visible from each other. To get more accurate results, I can either subdivide the triangles more or implement a stochastic approximation of visibility.

Anyway, I can visualize the form factors for any given patch. I diplay the patch values as GL_POINTS in the center of the patch. The red dot is the center of the patch I am currently visualizing the form factors for, and the other dots represent the magnitude of the form factor for the other patches paired with the selected patch. Brighter means higher form factors.



Note the values aren't purely form factors, I also combine with visibility before display: see how the back left is all black where the tall box blocks the line-of-sight to the red patch.

Finally, I actually implemented radiosity... I chose a progressive variant that evaluates a bounce at a time.

Here's a gif of 0-3 bounce illumination using this technique (displayed in the same way as the form factors... as GL_POINTS at the center of the patches).


You can see it starts out with almost everything black (besides a few patches in the top at the emitter, which are hard to see over the bloom of the direct light). The first bounce is direct illumination, and illuminates most areas (though not those in direct shadow. After the next bounce, you can start to see color bleeding on the sides of the boxes.

Next up: pushing the radiosity values out to vertices and doing a full render.

[MMc] Basic Graphics Complete

We broke for pizza and then reconvened to hack some more.  My iPod died--it had been playing for 12 hours straight! Here's the current rendering of Starlight2:

Ships in the starfield and popup GUI windows for inspecting them
The hexification isn't properly centered, but first I want to take on getting panning working correctly on the ship and main views to help with debugging. My task list, with completed items in green, is below.
  1. Build GUI infrastructure for popup ship windows (equivalent to the main view in a traditional RTS)
    1. Window render
    2. Window draw
    3. Window resize
    4. Window close
    5. Zoom control
  2. Ship View inside the popup windows
    1. Draw ships (with zoom and pan)
    2. Show modules as plain hexagons
    3. Left mouse selects, drags, and activates module
    4. Right-mouse pans view inside of a window
    5. Icon modules
  3. Draw main view that shows a "realistic" universe (equivalent to a minimap in a traditional RTS)
    1. Integrate starfield prototype
    2. Overlay GUI
    3. Show ships
    4. Show free modules
    5. Draw paths
  4. Main view interaction
    1. Support zooming
    2. Support selection of ships
    3. Provide waypoint GUI
    4. Warp-drive
  5. Module interaction
    1. Drag within ship
    2. Drag outside ship
    3. Drag inside ship
    4. Activate
    5. Target modules in other ships
  6. Simulation
    1. Compute dynamic commodities, e.g., heat, power, etc.
    2. Simulate attacks
    3. Trading (needs more GUI)
  7. Polish graphics
    1. Per-user color
    2. GUI stylization: bloom, noise, ripple on hit
    3. Re-coloring of ships


Problems 4-6

3 more problems down...one was in Ruby, which was easy/fun enough, one in Whenever, which is a ridiculous language except for when it is easy to write a solution in one line, and one is in Ook, a variant of Brainfuck. Despite how fun it has been to write brainfuck code, if I actually want to reach my goal, I am going to have to stick with more "reasonable" languages for a bit

Problem 4: Ruby

Find the largest palindrome which is the product of 2 3-digit numbers

https://dl.dropboxusercontent.com/u/34972177/PELC/e4.rb

Problem 5: Whenever

Find the smallest natural number divisible by the integers 1,...,20

https://dl.dropboxusercontent.com/u/34972177/PELC/e5.we

Problem 6: Ook! (Compiled to Ook! from Brainfuck)

Find the difference between (1 + 2 + ... + 100)^2 and (1^2 + 2^2 + ... + 100^2)

https://dl.dropboxusercontent.com/u/34972177/PELC/e6.bf

https://dl.dropboxusercontent.com/u/34972177/PELC/e6.ook


[MMc] GUI Built

Here's the plan, updated with the implemented portion in green.  Current rendering of the game:

Resizable, Skinned Windows and GUI Controls over a dynamic Starfield
  1. Build GUI infrastructure for popup ship windows (equivalent to the main view in a traditional RTS)
    1. Window render
    2. Window draw
    3. Window resize
    4. Window close
    5. Zoom control
  2. Ship View inside the popup windows
    1. Draw ships (with zoom and pan)
    2. Show modules as plain hexagons
    3. Left mouse selects, drags, and activates module
    4. Right-mouse pans view inside of a window
    5. Icon modules
  3. Draw main view that shows a "realistic" universe (equivalent to a minimap in a traditional RTS)
    1. Integrate starfield prototype
    2. Overlay GUI
    3. Show ships
    4. Show free modules
    5. Draw paths
  4. Main view interaction
    1. Support zooming
    2. Show ships
    3. Support selection of ships
    4. Provide waypoint GUI
    5. Warp-drive
  5. Module interaction
    1. Drag within ship
    2. Drag outside ship
    3. Drag inside ship
    4. Activate
    5. Target modules in other ships
  6. Simulation
    1. Compute dynamic commodities, e.g., heat, power, etc.
    2. Simulate attacks
    3. Trading (needs more GUI)
  7. Polish graphics
    1. Per-user color
    2. GUI stylization: bloom, noise, ripple on hit
    3. Re-coloring of ships


So after some work i have a functioning rasterizer that will render a simple scene like Cornell Box pretty fast. I was originally running into a but where i did not properly convert the points to camera space before projecting them onto the camera plane. This caused a weird error which looked like this.
After i fixed the issue it looks like this. The change in brightness is not from my render but from a change in the scene.
The shading might look pretty bad right now but that is because i am not focusing on it. What I want to do now is optimize the hell out of the rasterizer and then at the end I will deal with trying to make the shading look nice. right now it is just a simple lambertian.

View from the Graphics Lab: 24 hours to go

Sam

Mike

Morgan and Dan

[Sam] 3 Solutions

Problem 1: BrainFuck

Find the sum of all multiples of 3 or 5 less than 1000: (Answer printed in unary)

The code I actually wrote:
https://dl.dropboxusercontent.com/u/34972177/PELC/e1.bf

The more cool-looking version:
https://dl.dropboxusercontent.com/u/34972177/PELC/e1Unreadable.bf

Problem 2: Haskell

Find the sum of all even Fibonacci numbers less than 4000000

https://dl.dropboxusercontent.com/u/34972177/PELC/e2.hs

Problem 3: J

Find the largest prime factor of 600851475143 (First line is my initial solution, the second a better one James helped me find)

https://dl.dropboxusercontent.com/u/34972177/PELC/e3.jis

[Sam] One down...

Because of the difficulty of using it, I decided that problem number 1 should be written in BrainF. It took most of the morning, but I have succeeded at this task. I unfortunately needed to compromise my rule of "programs must output the solution, not an intermediary value needed to compute it", but because the intermediary value was extremely easy to parse into a solution (I output a number of characters equal to the solution), but it would have been incredibly difficult to actually print a number, I decided to stick with the intermediary version. My next problem will be done using a much more sane language...maybe something like Haskell, which I have never used, though it is a language that is actually meant to be used.

edit: I did not compromise my rules, the number is printed in unary.

Tuesday, August 6, 2013

[Michael] Radiosity

I want a short project that won't feature creep on me as much as my games always do, given our reduced time and my lack of prep time.

I'm going to use OptiX and G3D to write one or more radiosity solvers; hopefully getting results in real time.

Victory condition: Having a standalone G3D program that can basically render
 in a minute.

Bonus condition 0: Reduce render time to 1-2 seconds
Bonus condition 1: Reduce render time to 67 ms
Bonus condition 2: Support dynamic objects.

[Dan] Rasterizer

My plan for this hackathon is to write a software rasterizer that will hopefully by the end of the forty eight hours be able to render some cool scenes in real time.

Monday, August 5, 2013

[Sam] Project Euler Language Challenge

I don't have any good ideas for games/etc. floating around in my head right now (though the Dominion AI idea proposed over lunch today sounds interesting...that may or may not happen at some later date). So, I am deciding to pick up a proposal that came up over an earlier lunch during the year that sounded like it would be fun - try to solve as many Project Euler problems as possible (in 48 hours), but each solution must be written in a different language. My goal for now is to do at least 20, though I can hope for more.

Goals:

  • Have fun revisiting Project Euler problems / potentially solving new ones for me
  • Learn the basics of some "real" programming languages that I have never gotten a chance to use (like Haskell, Perl, Ruby...)
  • Muck around with silly / ridiculous programming languages while having an actual goal in mind for their use instead of playing with them just to play with them.


In order to make specific what I will be doing, I have established a set of rules to formalize my task:

Rules:


  • Each "solution" must both follow the Project Euler rule of taking about a minute or less to run to completion, and in addition must actually be capable of outputting the solution in some manner - a program that gives information that can then be used to deduce the solution through additional work or guess and check over a small range is not sufficient.
  • Two languages, in order to be considered "different," must not be related by age or have a subset relation in code. For example, Java 1.5, Java 1.6, and Java 1.7 will all be considered "Java," even though each is a slightly different language. Also, C/C++ will be considered the same language as any Project Euler C++ code will probably use very few, if any features that are not in the C subset. In addition, for the purpose of this challenge, "assembly" and "machine code" will be considered one language - I am not going to just go around and write assembly for a bunch of different architectures.
  • A "language" is defined loosely as basically anything you can write in in order to instruct a computer to perform a sequence of instructions - languages need not be Turing complete or live up to any other such qualifications. Meta-languages such as the C Preprocessor and the C++ template meta-language will be considered unique languages, though preference will generally be given to "real" languages before working with them.
  • I will say that non-programming solutions are invalid - among these would be pencil and paper, calculator usage, graph plotting, excel spreadsheets, etc - due to the increased difficulty in establishing an adequate metric for difference among such methods, and due to not being in the spirit of this challenge. However, this rule may change at a later date, as trying to solve problems in this way could be pretty fun.
  • Programs must be either hand-written or programatically written by programs I wrote - a solution is not in "Java Bytecode" because I used the Java compiler, but a solution could be in Whitespace if I wrote a Python script that allowed me to convert semi-human-readable text into Whitespace.
  • A new Project Euler account will be made for this project in order to record my progress
  • Outside Project-Euler specific help is not allowed, including but not limited to looking at the forums for a problem and looking at my own older solutions (most of which are written in Scheme/Racket, Python, or Java)
  • I will post my solutions to the Project Euler forums for each problem as I complete them

Sunday, August 4, 2013

[MMc] Starlight

For the hackathon I'm revisiting a game that I wrote in a month two years ago but never released because the original version became too large to maintain.

Title: Starlight
Platform: Windows
Players: 1 (maybe)
Concept: An RTS where your "empire" is a spaceship that you can fly. Add new rooms, upgrade the hull, trade and battle with other ships.

Related Games:  Galaxy Trucker, Minecraft, FTL, The Ur Quan Masters, Age of Empires, tower defense and RTS games

Technology Plan: 

  • Use G3D, 3DS Max, Photoshop, SVN, Audacity, CFXR
  • Spaceships are made from hex tiles, with math from my codeheart.js example
  • Minimize state and assets, e.g., 
    • Procedural generation of the galaxy and visual elements
    • Dervive all ship data directly from an single image of the ship
    • Rely heavily on emergence

Art Plan: 

Design Plan:
  • Straight RTS mechanics, except components are found and bought instead of built directly to avoid players having to learn a tech tree and recipies
  • No "units"
  • Emphasis should be on building and configuring the ship, with flying, combat, trading, etc. forming increasingly tighter reward cycles.
  • AI is (as always) a risk.  Multiplayer?
Early Asset Tests:
Procedural Starfield
Spaceship Rendered in 3DS Max

Spaceship Hexified on Load
Screenshots of Old Prototypes:

Fully 3D Prototype Emphasizing Flying
Another 3D Prototype

2.5D Minecraft-like Prototype with Intricate Wiring Mechanics

2.5D Prototype with UI

Combat in the 2.5D Prototype


Thursday, August 1, 2013

Machinis Ludo 4: Algorithm Jam

The Williams graphics group will run a two-day graphics hackathon to celebrate the end of summer research internships. Others are welcome to join us, but based on the short notice we're not going to do a full game jam and explicitly invite people.

Proposal Deadline: Monday 2013-08-05.  Projects can be solo or group, and need not be a game. This is a great chance to design a new G3D feature, implement a graphics algorithm that you've always been curious about, or just play with a demo effect (e.g., maybe in shadertoy).  If you want to make a game, that's of course welcome--I'm currently planning to make a game myself.

Start: 2013-08-08 9:00am ET (early starts and exploration are fine)
End:  2013-08-09 3:00pm ET...for real this time, so that we can have a cool-down party.


Desert Morning shadertoy sample
Sleeping and showering at some point in during the hackathon period is highly encouraged.  We'll have a mix of takeout and meals out in the lab--sometimes taking a walk for coffee, or half hour at the pizza place is better for workflow than plowing through and eating at your desk.

As usual, post your proposal to the blog before the deadline and then post regularly during the hackathon to document our progress.

Wednesday, July 3, 2013

[MMc] Victory

I'm declaring victory in the game jam, but fully intend to spend every free moment between now and Thursday midnight working on Castles & Catacombs. There's an entire game that captures the Monaco and Minecraft feel, plays with joysticks in a browser, and has a consistent retro pixel style of all original art.

It also has only about 1% of the features that we want to add, though. Tomorrow's a holiday and I'll finally have (half) of a day off to work on it properly!  Coding from 11pm to midnight every day wasn't really cutting it for making progress.






Congratulations to everyone! Our next jam will be in late August or September. I hope that Mike and I can both take off two days then to really host everyone properly in the lab. I was shocked to find the lab empty at 6am this morning! :)

[Nigel] Finished! Stairaway.

I'm quite happy with this game. Not because it is particularly interesting, but because I managed to create exactly what I wanted.  

 Play Stairaway here!

 

I came into this wanting to make a game about stairs. I also wanted to make the game in pure JS, and with online functionality. I somehow hit all of these goals.

There are two modes: (Controlled by the arrow keys)
   - Survival : Press the correct arrow keys to climb the tower. Avoid the lava for as long as possible.
   - Online VS: A head on head race. First person to die to lava loses.

Additionally, the game has networking enabled, allowing for the following:
   - Server stored high scores.
   - Working online matchmaking for the Versus mode.

Messing with node.js/socket.io to get networking working was quite the experience, and I feel I learned quite a bit through making this game.

Anyway, fun times. Can't wait to try everyone else's games.

[Michael] The end of the beginning.

I've fixed up the text bugs and finished up my level editor(!), which allows for straightforward creation of levels from pre-made parts, each consisting of a full physics description (using Box2D) and an arbitrary number of images. I've added in duplication and deletion in the last few minutes (I'm at the point where every few minutes makes the level editor or game significantly better. It's where I really like to be in a project). Note that since I was at home alone for the home stretch, I've put off the multiplayer aspects until after the jam.

I whipped up a non-trivial level and added an invisible goal that causes victory if you reach it.

Despite the things that cropped up getting in the way (I spent a large part of this afternoon helping out the repairman in getting my washer and dryer fixed, for example); I've technically "won" the jam. Far more importantly, I'm at the stage where everything I'm coding is fun; and the game improves constantly.

I intentionally bit off way more than I could chew for this jam: working in a completely new language, with a completely different debug cycle than I'm used to (gotta love those hours chasing down a trivial bug a typechecker would have found), integrating a full physics engine and creating a robust level editor. I used this jam as a concentrated period of time to get a large project I can be happy to work on off the ground.

I'm excited to work more on this game and I'll package up what I have so far and post it here later this week.

[CO'D] Down the Rabbit Hole...

So... Morgan... I'm really sorry. I hacked the CRAP out of Codeheart.js. It's so bad the file is called codeheart_lite. I couldn't even think of it as a shadow of what it was. But, it works with Ejecta. However, it will probably never be the same again. On the up side I could totally get rejected from the App Store again now:


Like a dog with a bone, I couldn't give up the idea that I ought to be able to combine the two. I think there must be some sort of perverse pleasure that one takes in taking well structured and thoughtful code and doing unspeakable things with it.

[Sam] "Victory" on-time

So, I entered with the goal of making a tower defense where all the state, both enemies and towers is nothing but dice...and I succeeded! Right now I think the game makes the jump from trivially easy to nearly impossibly hard a bit too quickly...but that can be ironed out later if I want to, and ironing it out would require some playtesting. However, the game now works with (I believe) no bugs or issues, is mildly fun, and has a beatable 'easy mode' (the only difference between easy mode and hard mode is that easy mode lets you know that you won when you reach level 25, whereas hard mode will just go until you lose...which, unless I am just really bad at my game or my recent changes fixed things substantially, will be soon after level 25. But anyway, the game is in a finished state, though I may add additional features, and the most recent version can be played here: https://dl.dropboxusercontent.com/u/34972177/dice/play.html.

And, the proof that the game is beatable:

Overall, this was a very successful jam - using codeheart certainly helped, as did having a solid enough idea for the game that most of my time was spent coding and not contemplating what should be coded.

final stretch

So i now have a working game. below is a video of me playing it. It may be confusing because there are two green squares. The top one is the player and the bottom one is an obstacle that i have been using to test my physics engine. The weird camera motion was also not part of the game. I did that to try and show the drops falling and hitting the block.

As you can see it still looks pretty bad and the playing interface is pretty boring and there are no instructions but it has a winning condition so that is good. 

I have been working on trying to add obstacles and getting my physics engine to work well with them. so far it is not the best but it has been getting better.



The real issue with this is that i wanted the whole thing to be solved by doing physics calculations. so if my collision is erratic and completely unpredictable then that sort of goes down the drain. I think i might be able to get it to the point where it might be predictable enough to include. even if it doesn't follow real physics. 

Pretty soon i will have to transfer from working on the physics stuff to actual focusing on the game play. So i will have to design levels, make the interface better, and make the whole thing more appealing to look at.

Tuesday, July 2, 2013

[Michael] Hectic Day

Several things popped up that kept me from jamming as much as I'd like (I'm reclaiming some of those hours tomorrow...); but I've made some major (if almost entirely invisible) progress. And not just relearning the hard and long way how to debug in a language with no static type enforcement and no compile-time errors...

I have a complete working level format: each level consists of 4 things: a name, a starting position, a goal position, and an array of level objects. Each level object consists of a physics body, consisting of as many Box2D collision shapes as needed, and an array of sprites, which are the visual components of the object. Each sprite can be static, or dynamic. If dynamic, it has a working animation system using sprite sheets.

I have a method for serializing and deserializing levels to and from JSON. Far from trivial, since Box2D makes heavy use of prototypes, which aren't preserved by a round trip through JSON.stringify and JSON.parse.

I've hooked in Morgan's file saving and loading code, so my program loads levels from disk and the level editor can save out.

I spent quite a lot of time hacking up the physics so that platforming feels smooth; still much to do to get it to feel alright.

I'm punting on art for the jam; I'm much more interested in finishing up my sophisticated level editor and tweaking the engine so that the controls feel right.

And finally, so this post isn't just text: my ugly as sin main menu (text rendering seems to be bugged, so I've put 0 effort it making it presentable), when you try to quit!


[MMc] Adventure Graph


Castles & Catacombs contains a world of individual adventures, each of which contains one or more scenes. The picture above is the world map, in which adventures are circles on the road. The reward cycles for Castles & Catacombs are:

  1. Character movement
  2. Reaching items in a scene
  3. Completing an adventure goal:
    1. Clear gold coins
    2. Clear silver coins
    3. Recruit new character
    4. Beat the par time
  4. Unlocking a new adventure
  5. Completing all goals for all adventures

I've been working on the data structure that tracks progress through the game and the code for the world map that shows what adventures are available.  The world stores a table mapping adventure tags to descriptions. An adventure description contains:

  • Position on the world map
  • Criteria to unlock this adventure (e.g., clear all gold on four other adventures, unlock the druid)
  • Tag of the opening scene of the adventure
The map rendering code compares the description of an adventure to the progression state for the local save game and then shows appropriate symbols for progression through the adventure, whether it is locked, and whether it is new (flashing green circle).

I only had 45 minutes today to work on the game, so I'm falling far behind.  I foresee my team spending much of the 4th of July completing our game after the deadline.  I mean "completing" in the "making fully playable" sense, not "reaching a state where we'll never work on it again."

Next steps:
  • Follow pointers between scenes after loading all scenes to give proper coin counts when inside the adventure
  • Reset the state of adventures on exiting them (the entire world is currently persistent, which can make some adventures unbeatable if left in a bad state)
  • Redraw the gold coins
  • Draw silver coins
There's 16 hours left in the jam. I hope that everyone else is at least taking a short break for sleep.  Good luck tomorrow, everyone!

[CO'D] End of Day 2...

I mentioned it in a comment on my earlier post, but I'm done with Ejecta for the time being. :( Just a bit too complicated to connect with Codeheart for the moment. However, I modified my Pong-like game to play more nicely on mobile devices. Here is a touchier version called Pong-like-touch:


I started on my Berzerk-like clone today. The first thing I discovered is that I'm fairly certain I can't just color my sprites with an overall canvas fill color, which I was hoping for. This is sad, because I was really hoping for some interesting variety in the colors with that approach...


Player controls are in. Enemies are in. Now I just need to decide how to handle level data and collision. Then I'll transition to getting enemies to fire back at the player and move toward the player. Finally will be keeping score. After that I'll go back and finish up the sprite-sheets and animation of characters... Not likely for tomorrow, but I can hope.

[Sam] 21-hour update

Things are progressing well, I suppose I technically have a 'game' done: there are towers, there are enemies, the towers shoot at enemies, the enemies can die and get stronger after rounds, you lose lives if the enemies get through, all sorts of stuff like that. Now I just need to implement some sort of system of resources and some interesting game play elements so that the game is actually fun / challenging in any way (at the moment, you can still just place towers infinitely)

Note: The pink background is unlikely to be a final design decision, I have just been too lazy to get rid of it.


So far, codeheart has been nice and useful for making my life just a little bit easier - also, having the last game jam behind me, there are two major differences with this game that are allowing me to get things done:
a) I actually have a vision for the game, which makes it easier to figure out what to do, and
b) I am actually trying to make good design decisions from the start, instead of hacking everything together using magical constants and guessing and stuff

On that note, by one measure of progress, lines of code, I am already about where I was at the end of the last game jam - so things are looking up, I think the game might actually be mildly fun by the end of the jam tomorrow afternoon, and good luck to everyone else, whose games look like they are similarly coming along well.

update

so at the beginning of day two i am pretty happy with my progress. I have worked out most of the structure of the game and am now adding in the game play itself. I have a basic bare bones physics engine and have the whole system down where droppers create drops at the right time and then if the drops hit the player cube they imbue some velocity to them. below is a basic video of that stuff working.


The whole thing looks awful and currently there is  no way to win and no way to set up the droppers besides going into the scene file. So that is what i am working on right now.

[CO'D] End of Day 1... Kinda

Alright. Clearly, it is Tuesday and not Monday. So this is more of an end of day one and start of day two kind of post. First of all, I've enjoyed using codeheart.js thus far. First of all, clone number one Pong-Like is complete:


Clearly, I've stolen a bit of code from the paddle sample, but also tried to update a few things (like using the vector class where it makes sense). Things I immediately discovered that were harder than I had anticipated:
  • Rotating text
  • Loading cool fonts
  • No matter what you do, loading a game from Safari on a mobile device is kinda, "ugh".
  • Wow, my generation one iPad is SLOW.
For those of you using CFXR or something similar to generate sounds, here is a nice little command line tool to convert those WAV files to MP3:

afconvert -f mp4f -d aac -b 128000 Score.wav Score.mp3

There are two issues that I didn't finish before the end of day one. The first is that the ball can get stuck in paddles. Easy fix, but not done yet. The second is that the two tap points for controls is not good on a small device. I want to have each paddle controlled by a single touch. Will probably make a second version of the game with those controls.

But, it was the "running in mobile Safari is 'meh'" issue that sent me to start playing with Ejecta, which I was really excited about. Basically I fell down the rabbit whole with the rest of my day and didn't get it working. :(

2013-07-02 09:39:57.555 Ejecta[799:c07] Creating ScreenCanvas (2D): size: 320x480, style: 320x480, retina: yes = 320x480, msaa: no

So, that is where I'm at now. Trying to decide if I continue with codeheart.js or if I convert my clone to "pure" Javascript and try it out with Ejecta.

[Nigel] End of Day 1

Alright. Today I finished the following:

   1. Concept art completed.
   2. All needed assets created.

Concept Art

3. Base engine completed. (Try it here! It's very rough and buggy, but it gets the concept across.)




Now for an explanation. As I stated before, I wanted to create a game involving stairs. So, I went with this:

   -Player is attempting to climb a tower of stairs
   -Lava is rising below the players feet
   -Player must climb by hitting the appropriate arrow key marked above their head
   -The game continues until they die, and the difficulty scales as time progresses

Additionally, I will attempt to add an online multiplayer element in which players attempt to race each-other.




Plans:
   -Finish adding assets
   -Enable multiplayer
   -Polish/Speed up game/Inject Fun

Monday, July 1, 2013

[Philippe] Setbacks and Learning Experiences

Well this past weekend was a roller coaster.

I've never had so many computer issues in a row before! Suffice to say that I basically had no computer for most of the weekend, so I have not made much progress in my game. On top of that, this week is abstract submission week at SMALL, which means late nights for the next day or two. I'll do my best to get everything compiled together, but this may not be a Game Jam I can win! :(

So far I have implemented the new puzzle environment where constellations are given to the player and then the player creates subgraphs by highlighting edges and vertices. This took a lot longer thanit should have, as at first I was trying to keep track of more information that I could handle, and run-times errors were haunting me. After taking a break and watching some Game of Thrones, I came up with a new idea that I implemented using only 1/4 of the code as my previous attempt. Although this wasn't a very productive venture, I did learn a lot about good programming.

I have also implemented the various algorithms needed for checking solutions for each of my puzzles. In the next stage, I plan to introduce the following topics through 5 new puzzles and 3 new challenges:
  • Spanning Trees
  • Hamiltonian Cycles
  • Perfect/Maximum Matchings
  • Network Flow 
 I think from here it won't be too hard to pull everything together, and I hope to at least get to the point where each puzzle is playable by the end of the jam. It won't be as complete as I had hoped, but who knows, the summer is still young..

Philippe Demontigny

[Michael] Joysticks + Platformer + Physics

I've been experimenting to get the right platformer-y feel inside the Box2D engine. Tomorrow morning will be for finishing the rough draft of controls (including wall-cling/jumping), and starting work on a level format/editor. Nothing impressive just yet.

[MMc] Coins

Gamepads now work for selecting characters and navigating the world map.  In game, there are coins that players can collect:


The coins play a satisfying Mario-like effect due to cfxr.  The command:

   grep ";" *.js | wc -l

reports 1566 source lines of code for Castles & Catacombs. The program clocks in at 8 MB of data and 47 MB of .PSD files that are not used at runtime.

We're debating whether the regeneration attribute should just heal the character who has it, or let that character heal others nearby.  Healing others makes the player feel more valuable to the team, but also could make the player feel like a walking med-kit (I'm sick of playing clerics and medics because of this).

Next:

  1. Refactor the scene-loading code to note pointers between scenes.
  2. Count coins on load and show the total for the scene (traversing the entire reachable graph)
  3. Show the total number of coins on the level
  4. Reset scenes (and all child scenes) on leaving them

[Michael] Pre-game Update

Due to some work that got in the way; I am now participating on the hardcore track on US Mountain Time.

I've acquired Photoshop, an OS X XBOX 360 controller driver, and some codeheart.js samples. Start time is in 3 minutes. Hope everyone who are on EST got a good head start.

[Donny] 1st Update

Glad to see all the people who are participating -- good luck everyone! (Thanks for the shoutout, Philippe) Here's my 1st update:

I've locked down many of the details for the Programming Game Engine I'm trying to make.

(1) For gamers who know how to program, the gamer will command his/her army by sending Strings along the lines of: (Unit4 use_second_ability_on (12, 3)), or (Unit2 move_to (4, 6)). The gamer will obtain information about the game world by accessing a GameWorld object that contains all the relevant information to that gamer, which is updated each turn.

AI challenge (http://aichallenge.org), and both versions of Darwin (http://www1.icsi.berkeley.edu/~barath/cs136/hw/hw9.pdfhttp://cs.williams.edu/~morgan/darwin/) use similar setups. I think this setup is easy for a programmer to use, and difficult to hack.

(2) Unfortunately, for gamers who don't have as much programming experience, something crazier is needed: I'm currently trying to create a very simple custom graphical programming language, and trying to write an interpreter for it.

What I would ultimately like gamers without much programming experience to be able to program in, would be something in between Lego Mindstorms' (http://mindstorms.lego.com/en-us/Software/Default.aspx) and Final Fantasy XII's programming interface. I will try to give more details about the specifics of the language as a move further along the implementation process.

Screenshot of the Lego Mindstorms programming interface (http://mindstorms.lego.com/en-us/Software/Default.aspx):


Screenshot of the Final Fantasy XII programming interface:


(3) I decided earlier on that I would use the Unity game engine to make this game (http://unity3d.com/). (Unity is easy to use, and in the long, long, long run, using Unity would hopefully make it easier for me to export this game to the internet, Xbox Live, the Playstation Network, etc.) But at the moment, I'm still trying to learn how to use Unity.

At the moment, I have figured out how to let a gamer make windows, move them around, combine them, and link them to build trees -- which naturally form abstract syntax trees, which will be important when I try to write the interpreter.

My current results: (This is still very basic, and I'm currently paying zero attention to looks):














Next step:
(1) Given that I already have abstract syntax trees, figure out how to write an interpreter. (I now wish I spent more time on CS434: Compilers)

Also, I want to note that I'm sadly making a last minute switch to the pro track. With my summer internship using up 10+ hours of my day, I won't be able to spend 20+, 30+ hours per day working on this game jam like a proper hardcore person would do. I'll still be working as much as possible, though.


Sunday, June 30, 2013

[MMc] World Map

The title screen, world map, and character selection screen all work now.  The world map is just a giant image that the characters can freely roam over--the underlying graph is not yet connected.



I then added mounts to the main game mode.  When all players are mounted, they return to the world map.  Well, they will.  I haven't implemented the final test for all players being mounted yet.


Next steps: 
  1. Actually implement returning to the world map
  2. Draw a mount for the faerie (I'm now thinking dog instead of bird--birds look dumb without animation)
  3. Implement the world map graph properly
  4. Allow controllers to be used on the selection and title screens


While working, I've been listening to this IDM/EDM Pandora station that Acy made for me: