4 ms·

Source code: http://www.mojang.com/compo/metagun/metagun-source.zip http://www.mojang.com/compo/metagun/metagun-source.zip (linked from http://www.ludumdare.com

by 10ren 16y ago

Source code: http://www.mojang.com/compo/metagun/metagun-source.zip http://www.mojang.com/compo/metagun/metagun-source.zip (linked from http://www.ludumdare.com/compo/ludum-dare-18/?action=preview&uid=398 http://www.ludumdare.com/compo/ludum-dare-18/?action=preview...) I compiled (yucky) with (after unzip + mkdir build): javac -cp build src/com/mojang/metagun/{entity,level,screen,}/*.java -d build/ cp {src,build}/com/mojang/metagun/screen/exposition.txt jar -cf app.jar -C build . -C res . You need some html to run an applet; App.html just needs this: <applet code="com.mojang.metagun.Metagun" archive="app.jar" height="480" width="640"></applet> Run with: appletviewer App.html New to me (but probably standard to game writers) is: using a png to represent all the maps combined (like 10x10 maps), with each pixel's color representing a game tile type (eg. yellow for oil drum, purple for portal cube, red for spikes, green for signs etc). This representation is really cool, because it looks like what it represents (an isomorphism): you can "see" the level in a png editor, even though what you're seeing is not the actual level. Another aspect of how the data representation drives the game, is that there are no explicit arcs between game screens - instead, the screen design allows your character to walk off-screen, then that point enables you to transition to the next screen. I guess it's the most obvious way to do it: it's as if you are zoomed into a particular section of the 10x10 maps, and then you can move to adjacent maps. Maybe it's just that I've spent too much time with nodes and arcs recently :-), expecting logical concepts to be explicitly specified, instead of implied by the design. Anyway, there is no sequential index to get to a particular screen; you have to follow the path. Or you can look at that png. eg, the final boss screen is at xLevel=3, yLevel=10 (you can initialize those values in GameScreen.java; and you need to change the player start location too, because now it's not derived from the previous screen: change the last two args in the following new Level line, from 0,0 to 10,10).

Ogre 16y ago
I've seen the bitmap to level trick used before, but most "normal" (not developed under severe time constraints) games would eventually have a level editor implemented alongside the game. Personally, I'd be more likely in this situation to implement it as a text file and edit it with emacs picture-mode. I've also heard of some bitmap-as-data atrocities. A colleague who worked with an engine from a certain well known single player RPG described how bitmaps were used in that engine to control animation states. Like, if walking and getting hit, which animation takes priority. There are as many ways to implement that system as there are game developers. For some reason this developer elected to store those matrices as BMP files, and edit them using a paint program. The bitmap as level trick is a great shortcut for prototyping and rapid development, perfect for this contest. But I can't imagine the thought process that led to using one for animation data.
- 10ren 16y ago
  emacs picture-mode would be handy, otherwise it's difficult to maintain fixed-width. In practice, I have a lot of trouble with it. I think huge maps (those 10x10 ones) could be a problem, simply due to size; paint programs have zoom as standard, and of course the natural size for a pixel is pixel-size. Though I'm certain emacs has arbitrary zoom-mode. At least he was using a data-driven approach. There's a lot to be said for that (as opposed to coding it), provided you can find a good representation. As Brooks ~ said "show me your flowcharts and I will continue to be mystified; but show me your tables and all will be clear." He's talking about communicating it to another, but a (appropriate...) data-driven approach is also more flexible, simpler and easier to reason about, because it embodies an abstraction and isomorphism of the solution space. Of course, if it turns out insufficiently rich, you'll wish it was code (or at least that it can be supplemented with code.)
  - TeMPOraL 16y ago
    A year ago, when I was developing a retro Pacman for cellphones (J2ME) as a university project, I decided to use a text file to store maps. It was before I knew about emacs picture-mode, and I was working on Windows, so I actually used MS Excel for the job. You resize the cells to make them square, insert a formula that will rewrite all cells from a given row into a single string (so you could then just copy a column with those strings and paste directly into Notepad, or something), and then you can use convenient navigation with arrows, tab and ENTER to create the map (also filling entire row or column by one mouse drag was handy). Moreover, if you add "conditional formatting", you can make all different tiles appear with different colors and font styles (like walls with dark background or pickups colored in gold, green, etc.). It's a 2-minutes-to-do, poor's man map editor for tileset-based games :).

by 10ren 16y ago

Ogre 16y ago

I've seen the bitmap to level trick used before, but most "normal" (not developed under severe time constraints) games would eventually have a level editor implemented alongside the game. Personally, I'd be more likely in this situation to implement it as a text file and edit it with emacs picture-mode. I've also heard of some bitmap-as-data atrocities. A colleague who worked with an engine from a certain well known single player RPG described how bitmaps were used in that engine to control animation states. Like, if walking and getting hit, which animation takes priority. There are as many ways to implement that system as there are game developers. For some reason this developer elected to store those matrices as BMP files, and edit them using a paint program. The bitmap as level trick is a great shortcut for prototyping and rapid development, perfect for this contest. But I can't imagine the thought process that led to using one for animation data.

10ren 16y ago
emacs picture-mode would be handy, otherwise it's difficult to maintain fixed-width. In practice, I have a lot of trouble with it. I think huge maps (those 10x10 ones) could be a problem, simply due to size; paint programs have zoom as standard, and of course the natural size for a pixel is pixel-size. Though I'm certain emacs has arbitrary zoom-mode. At least he was using a data-driven approach. There's a lot to be said for that (as opposed to coding it), provided you can find a good representation. As Brooks ~ said "show me your flowcharts and I will continue to be mystified; but show me your tables and all will be clear." He's talking about communicating it to another, but a (appropriate...) data-driven approach is also more flexible, simpler and easier to reason about, because it embodies an abstraction and isomorphism of the solution space. Of course, if it turns out insufficiently rich, you'll wish it was code (or at least that it can be supplemented with code.)
- TeMPOraL 16y ago
  A year ago, when I was developing a retro Pacman for cellphones (J2ME) as a university project, I decided to use a text file to store maps. It was before I knew about emacs picture-mode, and I was working on Windows, so I actually used MS Excel for the job. You resize the cells to make them square, insert a formula that will rewrite all cells from a given row into a single string (so you could then just copy a column with those strings and paste directly into Notepad, or something), and then you can use convenient navigation with arrows, tab and ENTER to create the map (also filling entire row or column by one mouse drag was handy). Moreover, if you add "conditional formatting", you can make all different tiles appear with different colors and font styles (like walls with dark background or pickups colored in gold, green, etc.). It's a 2-minutes-to-do, poor's man map editor for tileset-based games :).