> Tuff including all graphics, characters, ideas, sounds and maps are Copyright (c) 2014 Ivo Wetzel. All rights reserved.
(emphasis mine) IANAL, but my understanding is that at least in the US, it is the expression of the idea (the software and code, the graphics, and the other things mentioned on that line) that are subject to copyright, not the idea. See https://en.wikipedia.org/wiki/Idea-expression_divide.
IANAL, and yes, you can not copyright game mechanics or ideas. This is why so many clones of every game exists. Because no one owns the rights to "a tower defense".
There is only one successful Tetris clone lawsuit.[1] Most Tetris clones are removed just because they are fairly aggressive with their claims (not necessarily because their claims are valid).
The successful suit was due to the playing field having the exact same dimensions as well as very similar visual expressions as regular Tetris outside of the just the game mechanic.
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
If folks want to try it on a real Gameboy without all the wires, the Drag'n'Derp works pretty well. It's a Gameboy cart with a USB port for easy writing: http://derpcart.com/
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 :)
Pretty sure you could make your own with a 3d printer and one of those kitchen PCB-etching setups you see people using. There's no magic in there AFAIK.
Would seem painful enough as soon as speed or size became limited. C then was not as optimized as today. Old games used to be written in assembler, now the eeproms are bigger, the compilers are faster and portable.
It's a Z80-like core with some modifications; not all the Z80 instructions and registers are present and some instructions are completely different. Most instructions are the same as the 8080, but all 3 CPUs are not completely binary-compatible. It's neither truly an 8080 with added instructions, nor a Z80 with omitted ones.
Actually a lot of games are written in c# these days since that's what most unity developers use (and the other options are even less "lean").
I'd say c or c++ is only really standard in the AAA world, most casual/mobile/indie devs use higher level languages & engines (c#/unity, haxe, as3/flash, lua/corona, etc.)
I agree, that is why I smile every time I see the discussing of language X being too slow for game development, because of GC, bounds checking or whatever one comes up with.
As I am old enough to have lived through a few programming language generations accused of the same performance issues for game development, C included.
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.
Because softwares are not the only one to use cycles.
For example, in the GB, some memory space is only adressable during a few cycles, and so you have to optimize your code when you wish to update the video ram. If you miss the window, too bad.
ASM isn't all that hard, just a little tedious once you understand the CPU architecture a little and the mnemonics. You can think of it like a low-level basic. ;)
Cool, came here to report the exact same bug. Twitching, and doing the down smash eventually caused me to warp through the floor and initiate an endless fall into white nothingness. [Edit] After exploring some more, the extents of completeness are more obvious. I like the design style, and the art is very evocative. In terms of gameplay, there's a lot of blind jumps that basically end in death (spike and lava rooms to lower right). While I like the quick save mechanic with the light pillars, telegraphing those rapidly changing hazards might be less frustrating. Also, is it currently possible to get to the stuff up to the left?
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.
If anyone wants to go back more, AtariAge has good tutorials on 2600 game programming. Nothing like counting clock cycles to make sure the CRT beam is far enough over before changing the background buffer :)
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 :)
Some options include: He is familiar with it, the Z80 is so simple it doesn't really matter, and someone else already wrote one in JavaScript. Lastly does it matter?
All those are valid, I was just wondering if the dynamic nature of JavaScript, adding properties to objects at will etc. made writing an assembler easier.
You'll probably need to do a little work to make it work. The Gameboy used a Sharp LR35902, which is kinda 8080-ish and kinda z80-ish and has some of it's own stuff as well.
Either way, it's a really cool project! A working processor emulator, even a slow one, kind of makes you realize how deceptively simple lots of old CPUs are.
More like the original CPU/microprocessor. The man behind the Z80 was also the main contributor to Intel's 8080 as well as the 4004, which is arguably the foundation of a general purpose computer (calculator + memory) on an integrated circuit (microprocessor). I wouldn't say so much simple as it is ingenious.
Very cool. Not sure this was meant to happen, but at one point I did a double jump over a wall and then just started to continuously fall and it never stopped.
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 :)
Could you go into a little more detail on how the process is for adding sounds and sprites to the game?
I am very interested in this type of work and have been hacking at trying to build a game for the SNES. All I've been able to do so far is to collect all relevant documentation for developing it: https://github.com/bttf/snes_dev
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.
Quick question about the music for the game ; I see you have already answered a few questions along those lines.
When the bunny dies , there is a sound for its micro-explosion. I remember "Dangerous Dave" died with the same sound :) Are a lot of these interchangeably used ? Are these just system sounds ? How do these work ?
Awesome project!
So, are there any hard-way books or something, to begin developing for GB platforms? ASM and C have already learned by me, but I'm really frightened about code environment like IDE, testing and run on real hw? Are this question already answered or I'm really can't google?
The feel of this game reminds me a lot of Montezuma's Revenge, a classic in my book. Very cool, and nicely done!
I really like your project page as well, very concise, extremely informative, and covers exactly the things that someone wanting to make their own would need. Bookmarked!
I would love to write GB/GBC/GBA games using something like Ruby (or JavaScript!). Is this possible? Have any higher-level languages been used to write games for these platforms?
You would have to first port the ruby interpreter to the Zilog Z80 which could be a challenge because it is only an 8bit CPU!
The GBA actually has a 32 bit ARM CPU, although a very slow one (16 Mhz) so perhaps it would be possible to build a very minimal Ruby VM for that. I wonder if it would be possible to optimize by building a JIT compiler and JITing on an emulator before installing on the cartridge?
libruby, if that is the core of the interpreter, weighs 2MB. That's not gonna fly, even with heavy size optimization it would be unbearably slow, even on just a subset.
mruby can be compiled to embedded bytecode in a C file [1]. It might be possible to do something with that on the GBA, but the original GB is out of the question -- even the options for C are limited.
I'd "settle" for GBA ;) GB would be fun because it's so limiting but I am not interested in writing assembly (actually, could be a fun way to learn it...)
Nice. You can find RGBASM at OtakuNoZoku.com and the Gameboy Cribsheet too. Along with a bunch of other tools and code. I can send you complete game source if you want to study it.
You can also grab the RGASM project from the OtakuNoZoku website. I think Carsten (Surfsmurf) may have revived it on his github. I think I also pushed my source trees to github too. There is a GBC emulator that is both a COM component, and works inside of Visual Studio (at least, VS from around year 2000). Bunch of docs too kicking around. I have copies of most of them still.
I wrote programmer docs, assembler (before switching to extending RGBASM), linker, patcher, emulators, games, visual studio plugins, debugger, cartridge downloader, serial port driver, bunch of libraries, etc. Ah... the good old days.
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
I had the same problem though I was playing music with Radiant Player. However, I switched my sound output from HDMI (a Vizio TV) to my MBP speakers and it went away.
I'll also submit the above as a comment on the bug report.
The sound I get when I open this page is pretty sharp, noisy and unpleasant. I prefer it when websites have that turned off by default (unless it's obvious that the web-page involves a video that I'm supposed to be watching or something like that).
(emphasis mine) IANAL, but my understanding is that at least in the US, it is the expression of the idea (the software and code, the graphics, and the other things mentioned on that line) that are subject to copyright, not the idea. See https://en.wikipedia.org/wiki/Idea-expression_divide.