If the design of your roguelike limits player vision so they only see their surroundings, then instead of generating the 512 x 512 map in one go, you can improve the performance/memory usage by generating only the blocks around the player.

This would save a lot of initial loading time and could support maps much larger than 512 x 512.

If your engine doesn't need to render objects outside the viewport, then you don't need to generate those objects until you actually need to render it.

Yeah I got that, but I was just wondering if thats where the performance hit is. Generating the map vs rendering outside visible area.

Every few seconds the screen freezes for a fraction of a second. This happened to me on both Chrome and Firefox.

I suspect the lag is caused by garbage collection taking too much time. I ran into a similar issue on Firefox when working on my canvas game. Not sure how this can be fixed. (fwiw, I am running on this on an i5 Macbook Air)

Yeah, I'm seeing the same regular stutter as well. I noticed that it was reporting 50fps, but I suspect it's running at 60 fps with vsync and then dropping 10 frames every second.

On Firefox, the profiler tool will show you garbage collection in red. For me, there are pauses too, but they are not caused by garbage collection.

Screamed at JavaScript for failing at big integer multiplications. Got it after rewriting in python. Here is my poorly written explanation.

--------- MAJOR SPOILERS ---------

Let's multiply unique prime numbers and count their factors.

  n         Number of factors
  2         2 (1, 2)
  2x3       4 (1, 2, 3, 6)
  2x3x5     8
  2x3x5x7   16

Notice that each time you add a new prime number, the factor count doubles

i.e. 2x3x5x...x500500th prime will have 2^500500 factors

The 500500th prime is 7376507 (thanks to wolframalpha), and it's not very big.

We can easily get the product of the above with 500500 multiplications while modding result of each step by 500500507 to get an answer.

Except that the product of first 500500 primes isn't the smallest number containing 2^500500 factors. This can be made smaller.

Observe that

  (2x3x5x...x500499th prime)x2

has

  2^500499 + 2^500498 factors.

This is because with the extra 2 we added, it produces additional factors with existing factors that are a multiples of 2.

Continuing with this, we see that

  (2x3x5x...x500499th prime) x (2 x 2)

has

  2^500499 + 2^500498 + 2^500498 = 2^500500 factors.

This is a better solution, since 2x2 is smaller than the 500500th prime.

If we want continue doubling factor count by multiplying 2s, we will need to multiply by 2x2x2x2 next, and 2^8 after, which becomes inefficient quickly. Instead, why not use 3? Multiplying (2x3x5x...x500499th prime) by (3 x 3) also doubles the factor count.

So at this point, we think about doubling factor count and the ways we can do it. Out options are

<1>. Multiply by a prime that we have never used so far

<2>. Multiply by an existing prime k + 1 times, where k is the number of times it has been used

We repeat this 500500 times, using rule <1> and <2> (which can be generalized to one rule) and the result is the final answer.

  factor count          n
  2                     2
  4                     2*3 <1>
  8                     2*3*2*2 <2>
  16                    2*3*2*2*5 <1>
  32                    2*3*2*2*5*7 <1>
  64                    2*3*2*2*5*7*3*3 <2>
  128                   2*3*2*2*5*7*3*3*11 <1>

For 16 factors the number works out to be 120 (just like the example!). For numbers shown in the questions, sieving the prime takes some time, I also found it helpful to use a binary heap for speeding up finding the next smallest factors.

This relies heavily on requiring that the number of factors be exactly 2^500500. Can we find the smallest number with at least 2^500500 divisors?

This game is quite different from Conway's Game of Life because it's not deterministic. During a turn, cells will rely on Math.random to find whether to move or divide; the direction that the cell move into is also randomized.

I agree, you can call it cellular automata if you want but it is false advertising to draw any comparison to Conway's Life. Still, it is fun an interesting but I would have found it more compelling if it didn't have a random component. That's part of the magic of Conway's life that complex results arise out of simple, deterministic rules.

FYI: There have been many competitive versions of Life written over the years. Here's one: (Life As War)[http://www.ctrl-alt-dev.nl/Projects/LifeAsWar/LifeAsWar.html]

"There have been many competitive versions of Life written over the years."

Mistaking "Conway's Game of Life" for "Cellular Automata in general" can produce sub-optimal results. The same thing that makes Life so interesting is that from its simple rules, extremely surprisingly things result. In some sense it is in the class of maximally interesting "suprisingness" as it is Turing-complete. But this same surprisingness and the wolly, humanly-unpredictable way it manifests make it almost entirely useless for game playing.

The general idea of cellular automata can be turned into game form, but you're better off defining your own rulesets, which can produce things like http://chir.ag/stuff/sand/. I also remember playing a game that actually resembles the linked page, but where each player moved a mouse cursor around, the cells tried to follow each corresponding player's mouse cursor, and the various blobs would eat each other. Probably one of the most clear examples of a game I god good at (relative to my opponents) and couldn't even begin to verbalize my strategy, even though I had one.

The Powder Toy, more or less the state of the art in falling sand games now, has a raft of Life rulesets. I found it quite interesting to pit them together; they have no particular rules for directly interacting with one another, but the way they take advantage of life and death and empty space nonetheless can produce some fascinating interactions anyway.

To illustrate this, I made an extremely simple demo that's roughly the same in execution: http://jsfiddle.net/mkq1bvp7/5/

Assuming the RNG is a deterministic random number generator, then that should make the entire game deterministic? Given independent runs, the decisions that each cell takes should occur in order, and therefore achieve the same result.

You don't know what the starting internal state of the RNG is, so no you can't predict it. The starting internal state being secret is what gives PRGs their security.

Crypto PRNGs are secure as long as their internal state is secret.

Normal RNGs are not however. A common RNG under Unix used to cycle between even / odd every other number.

> You don't know what the starting internal state of the RNG is, so no you can't predict it.

You don't need to know that. All you need to know is that it is identical to the previous run.

> You don't know what the starting internal state of the RNG is

Unless you give it a seed manually, of course. Say, 42?

Can you simplify the form and save user's time by figuring out the type credit card from the number? (IIRC, all Visa cards start with 4)

I recently found that AngularJS has supports for promises. I replaced some of the callback code to use promises and it's a lot more readable.

Callbacks:

    Backend.CallA(param, function() { 
      aDone = true;
      if (aDone && bDone) { doC(); }
    });
    Backend.CallB(param, function() { 
      bDone = true;
      if (aDone && bDone) { doC(); }
    });

Promises:

    var promiseA = Backend.CallA(param);
    var promiseB = Backend.CallB(param);
    $q.all([promiseA, promiseB]).then(doC);

IIRC Angular's promises are based on stripped down version of Kris Kowal's Q. You may want to check it out:

https://github.com/kriskowal/q

As of AngularJS version 1.2, the promises provider ($q) is fully Promises/A+ compliant.

http://blog.angularjs.org/2013/11/angularjs-120-timely-deliv...

I've started reading this after I found it on an old HN post. I went through everything except chapter 12, 13, and the latest one that just came out. I would highly recommend learning OpenGL from this tutorial if you have no prior experience with opengl or computer graphics. This tutorial dives right into shaders in the very first chapter, where as the other sources (the red book, opengl superbible) still tries to teach your fixed pipeline rendering for several chapters before introducing glsl.

As someone who's been watching professional Korean SC competition for almost 10 years, the strategy described by your brother can be found from many high class players. Unlike Warcraft3 or other RTS, units in SC have very low health. Even if you have 5% more units, you can easily lose a fight within seconds from bad unit control, bad fighting position or just bad luck. It's never a good idea to attack just because you have 5% more units. Good players will continue play cautiously to make sure the opponent never gets a chance to take those 5% back. In the end, they win by the accumulated bits of advantages from various battles or economy advantages. You don't always need an glorious "final battle" to win the game, as long as your advantage is big enough (say 50%), you opponent will know that he lost and leave the game.

This is probably why SC has become very popular and still remains very popular. There are constant conflicts throughout the game trying to increase or take back the small advantages.

For the Starcraft watcher/spectator's counterpart of the article, there is the University of Washington Starcraft spectators study: http://jeffhuang.com/Final_StarcraftSpectator_CHI11.pdf

They explain the many types of people that watch Starcraft, and that Starcraft games are fun to watch because of "Information Asymmetry"

Sold out online at future shop, was going to get one. I could try door crashing the store tomorrow and see if they still have the one for demo...

http://www.futureshop.ca/en-CA/product/hewlett-packard-hp-16...

As someone who also like random candies, I wonder if it is cheaper to just order candies straight from Japan (Amazon Japan or maybe Ebay?) I am stealing idea here, but that would be another way to get more candies.