EmuDevz

Honestly, the premise is great and it can really ignite an interest in programming for the right person, but like others have said, there are a few issues that make it not the *best* option. For one, it's teaching (ostensibly) you to create an emulator from scratch using... Javascript? Sure, JS is everywhere and everyone is using it, but it's not the only language out there and it's not even a good language to use for something like this. If you were a brand new programmer and didn't know anything about the field, you would be given the wrong idea about when to use which language. Not that JS can't run an emulator (one of the most popular ones right now is written in JS), but it just isn't the right choice. Of course, that's assuming you are new to programming, which you can't really be since the game requires a certain level of JS experience coming into it. You need to not only know programming concepts, but how to implement those within JS (which again, is not that good for some things). Then you get into the actual writing. First off, the game is split into a console and text editor, but you cannot resize them or close the console. So if you are using third party resources in your browser (which you WILL be doing), you either need to have your screen split three ways because you have no way to relocate or close the game's console UI, or you will be alt-tabbing between the browser and editor constantly. Good luck seeing your own code if you don't have an ultrawide monitor. The game also forces you into writing the code in a very specific way. Your internal names cannot be something that makes sense to you, they have to always match the the dev's naming and formatting. The actual code writing is more along the lines of "rewrite my code exactly as I originally wrote it" and less along the lines of "learn how to make this product". It's not bad, necessarily. It just isn't as polished as it appears to be on the surface. This is an area I've been interested in for a long time and I'm genuinely sad that such a promising idea just isn't executed all that well, like most games of its type.

assembly > java

A pretty neat game with a good vibes, that does a lot of nice things, but also has some problems. If you're even [i]interested[/i] in programming, the game can get you up to speed enough and provides enough helpers that you should be able to work through it, perhaps as hard/frustrating as a Zachtronics game at times. [h3]The Good[/h3] 1. There is a "broken" emulator that has a mix-and-match quality, so rather than having to make the entire emulator to see and hear and experience what you worked on in a section, you can see it slowly build up over time! 2. The massive list of test cases means you can [i]generally[/i] be confident that it'll at least mostly work if you pass them, although there are edge cases, and at the very end you're generally expected to just load up roms to test the (optional, post-game) code you've written. 3. It provides a ton of homebrew, as well as a few NES test carts, so it's a lot of fun just playing around with things and getting to explore them! 4. There is an emulator specific debugger, containing more detailed information about exactly what code is being run, the states of memory, even internal states of things like the sprite data, although it is generally inaccessible in-game, only usable when a rom is loaded, and not for the tests, which makes debugging some issues harder (I could see this being fixed over time, though) 5. The game is open-source on github, and the dev seems to respond to issues pretty quickly (the game also updates fairly fast). 6. You are provided with a lot of "Template" files that are usually at least half-implemented, helping mitigate bad point #2, and also just letting you get right to the 'good stuff' for a lot of levels! This does taper off later on, but it's still very well appreciated (and arguably it might feel a bit too handhold-y if [i]every[/i] file was given as a template) [h3]The Bad[/h3] 1. The code you're writing is Javascript (ES6 transpiled to ES5). This makes a lot of sense to easily tie into an electron app, gives you the chromium debugger, and makes the mix-and-match "brokenNEEES" system more sensible. However, it means you are constantly running into type-based issues (You see a lot of `!!(variable)` things, which abuses javascript to convert a variable into a boolean). Means that iterating over things can break in weird ways (the difference between for...of compared to for...in compared to a few other methods means that if you [i]do[/i] know a bit of javascript, you might have a *harder* time), and also means that performance can suffer (I kept having issues where after loading a rom, all subsequent roms would run at 2/3 speed. The best option is "Refresh the page" by pressing Ctrl+R on the 'command line' window). 2. The test cases sometimes require anti-patterns by checking for specific behavior that, under normal circumstances, is fully identical to alternatives, but rather than checking things entirely from the emulator's perspective, it sometimes takes shortcuts and calls functions directly, 'revealing' bugs that would not appear in a rom! 3. The UI can be a bit weird, I reported a bug about how you're locked out of the console for a 'boss fight', thus preventing you from opening files, only to be informed that there's a small magnifying-glass icon in the corner that you can use to open (but not create) any file! It also means that you have to exit the chat in order to create a new file (a common task in many levels, as not every file has a template) All in all, while it does have some flaws (some of which are essentially fundamental), I think this was well worth the time I put into it, and while I'd probably then just make my own NES emulator in a different language that doesn't make use of the NEEES simplifications (which the dev is upfront about, and it's for the best in this case!), I'd probably recommend this to anyone that might be interested in programming an emulator, or even just wanting a reason to do some 'manual programming'!

Its a free game which guides one through writing an emulator for a CPU and its peripherals which is nice! The idea and the platform are also nice and it is a learning experience although I wouldn't recommend it: The developer forces some good paradigms, mostly notable test driven development, But the tests force you to write the code in a specific way. That way is extremely bad from a architecture/design perspective. Most notably failing to use any SOLID and SLA. The created classes do not have well defined interfaces or access patters but rather everything could potentially change values - and you will do that. One example is the # of cycles. Another example is that you later have to read addresses from memory after you implemented a memory interace already before. To be honest I skipped a lot of text and may have missed the information, but when gathering addresses the test will test for addresses beeing at the border of the memory so you have to read the first byte at the end of the memory and the second byte at the beginning and combine both. The memory interace we implemented before had a "read16" - does this function need to support the wrap around too? Are addresses a special case? who knows, but we now have different behaviour for reading memory. (I tested implementing it in the read16 but the test for it failed, but this may have been my fault) The information on the requirements are not consistently shared in a documentation. Some of it requires you to go through the chat, suffer from this aweful dialog and do basically 1:1 what was given to you. It is basically like having a real customer in front of you, that of course you have to talk with, so that you know what to do, but then the customer wants to force the exact implemenation too. FWIW: My brain was in python land in between and I accidentely wrote print(..), which will open the print dialog of your system :) Can the sandboxing be a bit stricter there?

Great stuff, if you know some programming, but are intimidated by the concept of emulation, give this a try. If you dont know anything about programming, this is not where to start.

I remember when I first opened the beta version I spent 4 or 5 hour sessions palying through the weekend. It was already addictive and it was not half of what it is now. It's a great, solid game. You can tell it's made with lots of love and attention to detail, you know. It just shows. I had never played a game like this before and I've found it to be quite easy-going for the level of complexity it envolves. The audio and video sections are so good! I will not talk about the background music, I'll let you judge youselves. You will want more games like this.

Лучше чем секс

actual gem 💡💾

I wish I had something like this during my undergrad a long time ago, it would have made Assembly way more enjoyable. I like that you see the memory changing with your code. Then see and test your changes in the emulator with hot-swap. The Javascript part was a bit weak. It felt less like puzzles, and more like work with poor management. You might make something that performs well and delivers what the emulator needs, but it is not necessarily what the unity testing is doing in the background. When you realized what you are being tested, you can just make something to pass it all, but not necessarily the best performance / the cleanest code. If Javascript elements were introduced the same way as the Assembly instructions, even if you did not know how to program, the puzzles would still be enjoyable.