BonsaiDen

Thing is though, making one minute of lets-play costs a lot less (time / money) than making one minute physics or crash course or you name it.

Also, I probably watch hundreds of hours of youtube every month so the amount that ends up at each channel will be extremely small 5.50 / monthlyHours * oursPerChannel isn't going to be very much in the end.

The biggest winners are going to be MCNs (Multi Channel Networks, which most Let's Plays are part of) which take another 20-30% of the revenue generated by each of their partnering channels.

If you want to support single channels, something like Patreon is still going to reign superior in terms of actual money received at the other end.

Thing is though, this and stuff like "hand over the keys to that encrypted data" are really easy ways of getting just about everyone into prison.

I could for example argue that you, by changing the profile picture on your blog, have used a warrant canary too. Do you have any way of proving that you didn't? You certainly can't argue that you don't need one (this would imply you haven't receive a NSL which would be a warrant canary statement in itself), you can still argue that you haven't used your profile picture as one, but then we're back to square one, with them saying "You have!"

If the government wants you in prison, they'll find a way.

I can wholeheartedly agree with this. I do Web Development for a living, so I write a lot off business application backend / frontend JS code. While it's certainly fun (especially when there's no pre-built solution for some problems and you have to wrap up your own code to fill the gap), most of my personal code revolves about making computer games.

These end up for the most part being some multiplayer HTML5 Tech Demos (where I can play with all the fancy new Web Tech I can't use at my day job) or really old-school stuff like doing Z80 Assembly for my very own old-school Nintendo GameBoy Jump & Run (along side with a custom assembler / compiler and toolchain) and digging in dissamblies of commercial games.

I can't imaging just doing "work" code, because that can be very exhausting at times. But I certainly have no problem staying up all night and getting that game up and running around 5AM in the morning just to scribble down some more ideas before I finally head off to bed.

What would make Apple Servers secure in this case? They most likely have the VeriSign Private Keys at their hands already.

Getting an Apple Private Key for signing the binary is also just a few blackmails and a gag order away. The average Apple engineer sure doesn't like to end up in jail for a prolonged time just because they happened to "find" some illegal material on one of his computers.

The sad truth is, the frameworks for something like this are already in place. There are "elements" in the government which have total control and surveillance at the very top of their agenda.

Controlling the media is easy (see Chinese, Russian State Televion etc.) but you also need to control the Internet these days. China is already really "good" at this and the US is also doing the groundwork, it's not as easy for them as it is for the Chinese, because they don't want to kill their tech sector and the billions of revenue for good overnight, so they have do introduce these things more slowly.

Focussing on the cause won't give you the side-effects (or benefits, depending on how you look at it) of installing a surveillance state / building up intelligence for economic advantages etc.

If in today’s world the act of merely "kidding" around on the internet or dropping a suitcase in front of some building, is enough to bring whole cities to a grinding halt, then the terrorist already one.

And because of this, you won't need anymore technology to stop terrorist, but the technology to remove all the fears from peoples minds. Fear and the removal of freedom are the terrorist ultimate goals, they may achieve this in part by killing people, but they also receive a tremendous amount of help by your government of choice which wants to know every little detail about you.

It's a game about visibility after all, many many more lives are lost every day due to illness and hunger than through means of terrorism. But there is no visibility, because spending money on medical research isn't as "effective" as spending it on your military / intelligence budget. Partly due to the lobbyists and partly due to the fact that helping - seemingly "random" - people won't convince your average voter, that you're actually doing something for them. Arguing about how you're protecting their children is much more convincing in the short term.

Sadly, at the moment I don't see any way out of this dilemma, except for some horrible events to take place which will wake everyone up e.g. someone newly elected using the existing surveillance mechanism in their country to install a totalitarian regime along with the mandatory secret police. Which I really hope won't happen.

ES6 classes are nothing more than syntactic sugar for the existing prototypical inheritance model.

There are a whole lot of things every programmer should know because they'll have a profound impact on their code no matter how far up they sit in the abstraction chain.

Even things like memory alignment and cache lines can bite you really badly if you don't know about them and order your loop the wrong way around :)

Date and Time Handling, Unicode and Data Structures are also a common area for many misconceptions and sources of error. Of course nobody needs to know everything, but have a lively thirst for knowledge always helps, especially one you got over the initial confusion of learning the basics. There's just so much interesting stuff out there and a lot of it will help you improve even if you don't end up using it right away / at all.

Even if you're just swimming on the surface, it's always a good thing to know at least the 1-3 meters beneath you, just in case something happens or you get stuck in some seaweed and struggle to get out on your own.

I've actually made quite some good experiences with teaching people a few things about ASTs right once they started writing code, even though I only gave the some very basic lessons about how the "text" is eventually transformed, it really helped them a lot in understanding why certain text does certain things.

In the end, it's always very hard to play the game successfully if you don't know the rules by which you have to play. And a little can go a long way.

Vanilla JS is perfectly fine and there are a ton of people out there who are using it every day on a highly professional level.

There is a huge amount of tooling these days and specially the Node.js community and ecosystem are flourishing. Code coverage, static analysis, test frameworks for every use case imaginable, you name it.

Coffeescript and its brethren are a "solution" for people who are not interested in JavaScript and don't care about performance / maintainability in the long term. The additional compile step and the resulting problems with not being able to know exactly what it ends up generating become a huge burden in the long run. If you're really good in JS, you know what we'll be JIT'ted and what not, just like a really good C++ developer knows what the compiler will eventually optimize away and what not.

Seriously, building your cool, new library in <Insert Fancy New Compile to JS Language here> is like writing the latest addition to Boost in C89. Nobody wants to depend on it in the long run.

From what I have seen, the people who are mainly using things like Coffeescript are coming from Ruby or Python and want their cool-aid back.

If you don't want to learn a language, don't use it and if that means you won't be able to do stuff on the web, well I'm totally fine with that. I've seen enough code that looked like a J2EE developer just started coding C the other day.

It's probably not possible at this time. The whole map is just a giant demo level which evolved (and still is) along with the gameplay and other features (like spikes and lava).

I've got some rough sketches for the final world as well as the powerup placement, since there are no text boxes in the game, everything will be explained through level design or other hints like enemies or neutral creatures performing certain maneuvers for the player to imitate.

There are quite a few resources you can find after searching for a bit e.g http://problemkaputt.de/pandocs.htm or http://students.washington.edu/fidelp/galp/megaguides/GameBo... (the latter one being the original manual for licensed developers)

That's a "recent" development though :) The original title back in the day were all written in assembly, you really have to squeeze out every single byte and cycle for something like Pokemon or Kirby.

It's a bit hard to find, but it's all there :)

- http://gameboy.mongenel.com/dmg/gbspec.txt (html version http://problemkaputt.de/pandocs.htm#soundcontroller ) - http://www.otakunozoku.com/nintendo-gameboy-cribsheet/ - http://realboyemulator.files.wordpress.com/2013/01/gbcpuman.... - http://students.washington.edu/fidelp/galp/megaguides/GameBo... (The original Manual)

There are more, but I can't seem to find the links right now :O

You got me! I enjoyed Knytt so much, and it was the game that first inspired me to make the first version of Tuff way back in 2010 :) https://github.com/BonsaiDen/Tuff/commits/master

It's known issue, I've to the exact same issue here on Linux, seems to be related with their Web Audio implementation.

I was looking at these option initially too, but ended up going for the challenge since, both I read some not-so-good reviews and shipping the thing to germany would probably ended up being at least as expensive as buying the soldering equipment :) Building one of those custom GamePaks takes about ~4 hours once you have all the materials prepared (you really need very, very thin wires!) and putting it together for the first time is one of those finger crossing moments which you'll remember for a really long time :)

I'm a full stack Web Developer at daytime and I'd argue that I probably do speak JavaScript more fluently than I do English. So for me it really was a no brainer. The custom conversion tools needed for the graphics / map / sounds are also written in JS, so it's a bonus to have good interop with those too.

In addition to that, getting the compiler up to speed (takes < 90ms on my old core i5) was a nice exercise in getting more familiar with v8's performance analysis tools :)

Sure!

I'll start with the graphics part, since that's the easier part of the two.

Since the original GameBoy has only 4 shades of gray, all "bitmaps" are 2 bits per pixel so you can squeeze a total of 4 pixels into 1 byte, the graphics are converted from PNG files via some JavaScript routines which can be found in the convert.js file in the repository.

The GameBoy uses 8x8 pixel hardware tiles on a scrollable "background" and supports up to 40 sprites which can be either 8x8 or 8x16 pixels in size.

There are 2 tile buffers in VRAM which partly overlap and only the lower one can be used for sprites, which gives you 128, 8x8 tiles for use with sprites and 256 for use with backgrounds.

Sprites can be mirrored, so this somewhat reduces the amount of graphics needed for the player character.

In order to reduce the map data, each room uses 80 16x16 blocks which are served from a meta table in memory, where each index maps to 4 8x8 tile definitions of the block. When drawing the screen the code resolves the individual 8x8 tiles and sets their value into the current VRAM buffer for the screen (there are two, which are swapped, to minimize draw artefacts).

Since the meta table is limited to 256 16x16 blocks too (due to the fact that the map format only uses 1 byte per block tile) there is some additional pre-computation magic going on when creating the map data. Basically, the block tiles are split into 4 x 8 rows, each screen then maps onto 4 of these "rows". By then packing often uses block tiles together, you can have more details for certain rooms since they don't need to use all of the different rows available and can basically swap some of them out.

Also, all graphics and map data are additionally compressed with a custom LT Type compression routing and are decompressed on the fly. Except for player graphics, which are stored into a RAM buffer at start in order to avoid graphic glichtes when switching out the sprite tile reference indexes and the graphics at the same time.

Overall, the timing is really important since you don't have too much time during the VBlank period (yes, it emulates a vblank!)

Now as for the sound, right now I'm really just setting the sound channel register values pretty much "Per hand", meaning, that I pick some decent values (tested in some GBA sound test ROM for gameboy sound channels I found somehwere - yes the GBA still has the original GameBoys 4 channels, since it's backwards compatible).

The sound data is stored in some kind of JSON format for easier editing, all the bit field stuff is than generated at compile time and baked into the ROM.

I've also gotten a prototype of a music engine running (not yet in the repository) where you'd play pre-defined sound "patterns" on virtual channels and "mix" them down. The sound / music stuff really is a whole story of its own, especially since there are nearly no references to find, except for some old, undocumented ASM sources of some Rare Ware GameBoy ports of Banjo / Jet Force Gemini which apparently got uploaded by one of the Sound Engineers at Rare.

Nah' I would only be showing off if I were to put it onto a real cartrdige and GameBoy, wouldn't I? ;)

- https://dl.dropboxusercontent.com/u/2332843/tuff.cartridge.j... - https://www.youtube.com/watch?v=yXNEeld8Lq8

Yes, it's all written in z80 assembly, although the GameBoy CPU really uses a mix of i8080 and z80 instructions, the mnemonics are all z80. I've also written my own assembler just recently, to have more control over the output and more easily generate debugging information: https://github.com/BonsaiDen/gbasm

It's a 16x16 screen world which wraps around, if you move to the left or right you should eventually land on a non-empty screen. The "world" is anything but finished, to be honest, it's more of a debug / feature test world than anything else at the moment :)

Here's a picture of the whole world for reference: https://dl.dropboxusercontent.com/u/2332843/tuff.map.png

You can do a wall jump or a double jump, at the moment all powerups are enable from the start since I'm missing out on the animation for collecting them an all other sorts of things. I tend to deviate from the gameplay aspects of programming and spend a lot of time doing optimizations and tooling, just recently I wrote my own assembler to cook the whole thing into the final ROM image https://github.com/BonsaiDen/gbasm

In general there are two types of JS code bases you'll encounter, the ones for the Browser which end up putting everything into a single file and the ones for Node.js, which (in most cases) organize their code in the usual directory / file structures you may be used too from other programming languages.

There are also multiple camps which battle about whether too use semicolons at all and where to place commas that separate the individual parts of `var` statements. I'm not going to take any sides here, since I think that style is something everyone has to decide on their own :)

Now as for the code to read, there's obviously jQuery, but Angular.js is definitely a good read too these days.

https://github.com/angular/angular.js

If you're into parsing (or want to learn about it), there's also Esprima which is a JavaScript Parser written in JavaScript:

https://github.com/ariya/esprima

Taking a look at NPM might give you an idea of another syntax style, since commas are infront of the lines here and there are no semicolons:

https://github.com/npm/npm/tree/master/lib

And last but no least a shameless plug or two!

gbaasm this is a assembler for z80 GameBoy code (which takes assembly files and build a ROM) written by myself, it has a big focus on performance and is another example of lexing / parsing source code.

https://github.com/BonsaiDen/gbasm

For something short and sweet I got a minimal 2D physics engine here. Beware though, if you're new to physics simulation is can be quite hard to figure out what excactly is going on:

https://github.com/BonsaiDen/box

I wouldn't necessarily say that you immediately know whether you're in danger or not. There's no clear statement on how exactly they will "restructure" the company within the next year, this makes it incredible hard to judge whether your department will still be important the next quarter.

I was a Zynga until last June, when the shut down their whole Shared Tech Group (basically the core Tech Support for all Teams / Server Management, Engine Development etc.) overnight, the whole group always had the feeling they would not be in danger because after all, pretty much everyone was dependent upon them. Until management thought otherwise, they announced "some cuts" at the Company Meeting, which was on Friday the next Monday we held the severance agreements in our hands and were instructed to leave the office.

You never really know what management is planning unless you know someone up their or are part of it.

At least for me - a native German speaker with English as a self taught second language - I find that the `y` in bay actually makes it easier to figure out the correct pronunciation.

Since `a` is pronounced as `ah` in German, just having `ba` would make the `a` sound like the one in `bra`, which would make it hard to distinguish between `ba(y)` and `ba(h)` when first learning the language.

Removing the y's would also leave one with seemingly strange words like `awa`, `ga`, `sla` and `sta`. Which quite honestly to me, look much more like mnemonics rather than actual English words.

Here's another Version: http://selmiak.bplaced.net/games/ps2/index.php?lang=eng&game...

Prepending a ! results in the parser picking up the line as a expression instead of a statement.

    function foo(){}; // statement
    var a = function() {}; // the right side of the = is a expression, a function keyword inside a expression does also not require a name

Also function statements are put into the scope before execution of the program begins, expressions on the other hand need to be evaluated.

So this will work:

    foo();
    function foo(){}

While this will throw the usual `Undefined is not a function` (it does not throw foo is not defined, because the var statement gets hoisted, meaning before the code is run the compiler will move all var statements to the top of the nearest scope (i.e. function)

    foo();
    var foo = function(){};

Now, as for why he closed the tab, first of all it is pretty clear that this is a very dumbed down explanation of the whole thing, and while there is a SO link it's not immediately clear that all operator tokens can trigger this behavior.

Have you considered getting a orthopedic insert? I'm also flat footed and had enormous problems with both my legs / knees and my back before getting them.

I could see Mindstorms working out really great :) Or just any sort of "simple" 3D game engine. I think it's important that he sees immediate results, he can learn the gritty details over time, having the actual feeling of creating something is a big motivator. At least it was for me, back when I was like 12 and started out on my own, surprisingly I remember being way more productive back then I think I once wrote a really decent cannon hill clone in a week or so, but today I can hardly get any project started at all, meh.

As a VIM User, I feel right at home :)

Works well here on 10.04 with a Nvidia GT530 (propr. drivers)