NESmaker showcase, January 2019

Hey all - here is a showcase of some of the games created prior to the most recent version. We are super proud of what our community is doing, and we're happy to report it is really turning on a lot of people to stating to learn ASM to create their own engines as well.

Check it out:
https://www.youtube.com/watch?v=1cwSvMbazlY

I checked the video and some of them looks nice. It will be interesting to see how far they go in their game and what they will decide to do after (more nesmaker type game, learn asm, etc).

Right? It's really great to see some folks who have never touched programming actually digging into the code since they can sort of organize it and work on it in small chunks at first. A few folks have already started creating their own engines from scratch, a few others have built plug ins and custom ASM to work with the tool, and others are simply modifying scripts and sharing what they've learned on the forums. It's really cool to see.

**Oh - and understand too, there is no "NESmaker type game" either. I REALLY want some seasoned ASM programmer NES devs to try it out to attest to this. You could literally start with ZERO existing code base and completely build from the ground up every last bit of the engine, using NESmaker as a code organizer, pixel editor, screen builder, etc. There are only a few things that the GUI sort of locks you into as far as visually, but hell - you could point MAIN.asm to a single script called "ignoreAllNESmakerStuff.asm" and write an entire game there from scratch. I'm just providing a simple codebase for those with zero knowledge as a way to get started doing some cool things.

Almost all of these titles -- easily 90% of them -- look incredible. Several look like they could've been released on cartridge back in the late 80s and achieved success or bare minimum a good cult following. Thank you for this compilation!

I guess my wording was not appropriate and didn't meant to be condescending, sorry about that ^^;;;

I just meant if the user will continue to make game with the tool or decide to just built their own. Since I have never used the tool myself, I can only infer from my current understanding, which is nesmaker seems to be a tool/editor that allows you to make game with little to no asm programming on the nes. It doesn't imply that nesmaker is bad in anyway.

No offense taken! Just trying to let ASM savvy folks here also understand that it’s not JUST for wysiwyg development. Most users are using it as a first step into ASM, and it’s conceivable that someone who knows ASM could use 0% of our code base, develop from scratch, and still use NESmaker as a script organizer and for asset creation.

No problem then

I could always try it someday but my current environment mostly consist of ca65 with vscode to write asm/c and uses it on multiple OS so I do not know is nesmaker whould cover in that case. I may check it someday but for now I cannot invest time in it since I'm a little bit busy ^^;;

No free eval activation?

I'm not in agreement with the eye rolling (I don't feel I'm entitled to a free evaluation), but as a NES developer, it's true that I'm not very likely to pay $35 just to play with it and try it out.

Well, I did pay for it and I still haven't tried it out

Hey, to each their own - it's not for everyone. The single best way to make a NES game will be to start from scratch and start to build, for sure! But...that takes a long time. A long long time. Especially for new comers. And it comes down to a question of how much time is worth. If it takes you even one day to get some sort of tools that can help you manage your work flow...let's say 10 hours...is your time worth $3.60 per hour? Just something to consider when it comes to tools like this.

A lot of folks here already have their flow, for sure. They already have built tools that they're comfortable with. They probably spent years on them, and they're specifically tailored to their uses. If you want to see how this works, we've created hours and hours and hours of tutorial videos, including a handful of "20 minute projects" if you don't have a lot of time to see if you dig it.

In the end, if it's not your thing, no problem at all. But we are very excited about the promise of what we've already seen users do with it already, and I thought their efforts were worth sharing

The price isn't at all unreasonable as a product, and is really quite fair. But my point is that if you're asking for experienced asm developers to try it out, you're asking for time AND money from them.

Completely reasonable perspective.

I'm also not adverse to offering a handful of seasoned ASM developers with some games under their belt some eval copies to see how they'd use it (and break it). If I found a handful that were up for the experiment and understood the spirit of it, I think that would be fun.

So there is no trial version, I guess? I was almost sure there was one since you could download the file from the site before the activation code.

I would have been more than happy to test but for now my time is already limited to even work on the current project I'm doing so it would be hard to invest enough time to give a proper feedback ^^;;; I'm not sure if you can mix asm/c and other things with it for a ca65 project?

Is there a video that gives an overview of the tool? I didn't check on the site yet (but will do later) but the one that was shared on twitter yesterday was mostly talking about palette management I think (did a quick scan in the middle of the night out of curiosity but didn't have time to listen to the audio).

Does this include developers of, say, assembly language audio driver who wish to develop an integration?

Tepples - do you even have to ask?! I’d be honored if you wanted to toy around with it. You’d have your sound engine integrated in a matter of hours, I bet. But we’d have to work with you on an import method for songs since right now it automatically turns fami-txt into gg asm.

Shoot me an email and let’s chat, friend! Joe@TheNew8bitHeroes.com

You've got mail, explaining (among other things) why I felt I had to ask.

pre-script:
while typing, this went from being an answer to your question to being a more general review, to being a plea for the thing i think needs improvement the most. If not interested, skip reading halfway. the tl;dr is you can't out of the box, but might be possible if you're willing to put some work into it and accept the framework of both the tool and the codebase.

EDIT: Apparently, you can write plugins in C# and add them to a plugin folder for nesmaker. Here's a resource that helps with that. http://joshuafallon.com/nesmaker-plugins-part-1/
That may change the outlook for some.

----

You can look at the neatly organized and fairly well-commented codebase, and the functions and macros are easy to browse because of appropriate naming. But i'd say the tool UI itself is not designed to be a general project organizing solution for any other code base than the one included and things you add or modify yourself that will work well with the mother engine. It enforces some fundamental design decisions and if you override them by writing code and structuring data differently enough, the i'd argue the point of the tool GUI sort of gets lost (quick level, object and assets editing, file organization and graphically assisted conditional assembly).

You can problably translate the code base to ca65 syntax if you wish and work from there, but there may be some caveats since the linker works quite differently with ca65 (automated) than with asm6 (manual).

You can very well code your own "modules" (basically a modular set of rules for the game) to jigsaw into the baseline engine.

It's really great for trying out ideas and producing results quickly. That way they won't stay in your "for later drawer" as much. Besides being able to go from an idea into something of a game quickly, You can kind of view it as one big interactive nes programming tutorial, which is awesome. You can look at one function at a time in a functioning game and modify it or its trigging conditions to see what happens.

I can vouch that it is pretty easy and fun to set up a project with NESmaker. I haven't been able to spend as much time with it as i'd like, but you can quickly have it do things that doesn't seem obvious at first glance even without code modification, like for example sprite animations with different frame durations and the like. I've even used it to try out animations in non-nesmaker projects just because it has sometimes been quicker than mocking them up in photoshop or writing the code to have some animation cycle on-screen by hand.

As far as modifying and adding your own code goes, that's pretty easy too. Modular code snippets + an interface that organizes it all is great for managing code assets.

Managing code is easy and transparent. You can quickly find the thing you're looking for in- and outside the interface and edit away. There are some things though that if you wish to replace, the GUI tool won't work for you any more.

Managing data and assets is.. a bit limited and not as transparent. A lot of it is baked into the project file, as opposed to creating a visible subfolder system of individual files. You can import and export certain things (such as palettes to clipboard and graphics from .chr binaries and to .bmp files) through the interface, but dealing with stuff such as data tables outside the interface is hard and time-consuming because it obfuscates where everything actually is. Some of the stuff needs to be string-searched for in the packed project file. Visual representation of modified assets is unfortunately not as robust as i would like; you will run into unhandled exceptions this way. And i find myself wanting to have a look at the data as text a lot to 1) get a better look at how it actually organizes things, 2)attempt editing it free from the restrictions that the editor imposes.

If there's a weak point that effects the creative output unnecessarily and that really concerns me, i'd say it is missing a properly game style-agnostic metatile system and how the lack of it is forced on the user through the GUI. The big advantage of not having one is the very direct approach to constructing the building blocks of a level. When creating tile assets*, you pick an even tile offset on a portion of the chr table (the UI will quantize your click into an even ID), and it picks the following tiles for you, relative to that offset: $00, $01, $10, $11. That makes for a super-easy interface that everyone can get at the very first glance.

But the interface also gets in your way if you decide to do something more versatile (ie. 4 freely definable tile indexes per metatile). Currently, cons are:
-You can't reuse a hardware tile in several meta-tiles.
-You can't pick an odd-numbered offset (except if editing by hand in a hex editor, but then you sort of lose the point of a GUI. I just found out that the GUI can't handle this properly, so the option left is patching your ROM after each build, or searching and replacing and then reassembling the text file).
-Most noticably, the number of unique metatiles is capped at 24 uniques per game screen (again you can enter any index using a text editor). Metatiles have variable size from 2x2 hardware tiles to 32x32 hardware tiles, in steps of 2x2 increments. So you can technically have more metatiles, but they will contain the same 24 basic 2x2 patterns.

Silver lining: Beside the "fixed relative index metatiles", up to 4 rows of tile data are dedicated to path-drawing which dynamically can create 4 different fill-tile fields with automatically drawn borders. With this you can make clouds, canopies, mud, ponds, etc. The fill uses one tile for the fill closest to the border, and another tile for "deep" fills. This helps alleviate the problem with the metatiles greatly. But it also decides a very specific style of level construction for the level designer/artist. You'll quickly run into limitations such as not being able to make paths within paths without creating borders, or adding a unique metatile detail to the fill or border without creating a new path-generated border around it. I found this a tad frustrating, but it can be somewhat worked around outside the GUI.

You can see these limits in the showcase. Some of them are doing really impressive things within those limits, but it is still apparent that the number of metatiles with unique content/arrangement is quite low. You get 24 unique two-by-two:s and 4 dynamic fill fields with border tiles per screen and bank.

All this sounds a harsher than i would have liked to put it, but i'd rather do away with the current metatile system altogether, except the paths. Paths are pretty cool for some game styles, and you can disable them comfortably if you don't like them; potentially freeing up that space for more unique metatiles.

2x2, fixed-size, 6-byte metatiles (1 byte per tile offset/ID + 2 properties byte, since NESmaker engine assigns properties per metatile) would be a slightly more indirect method as you need to pick each of the four ID:s for each metatile individually, but it is just as easy to get into, while both allowing for creative freedom pretty much exponentially, and more varied end results, and producing a better tile usage economy. The drawback is the expanded asset size. There may need to be a cap to how big a metatile table is per bank, depending on available space. To get to the same number of unique tiles as the existing system (24), you'd need to reserve just 144 bytes. And you could still use the tilespace in chr-ram more efficiently. Any single addition at 6 bytes each would be a well-needed improvement. Plus you could assign any currently loaded tile from RAM, not just the 96 designated "background bank" ones. If you for example don't need all those text symbols, you could use that space for commonly used background graphics across banks, and so on. The liberty with one such system is not just that you get more unique metatiles, but also a bigger artistic freedom on what to put in them and less hassle with pre-organizing your tileset to match the current metatile system in 2-by-2 sets.

It'd require extra work on the GUI tool beside putting the metatile system into place since it wasn't designed for this, but if there's one single area where i think the tool and codebase needs to improve, this would be the one. The rest is great.

*asset is NESmaker terminology for, among other things, a metatile + attributes for the same.
**the second (paths) is easy enough to disable if one really wants to.

@FrankenGraphics

Thanks for the lengthy explanation. From what I understand from it, to port an in progress project is not a good idea but it could be useful for fast prototyping as long as you are aware of the limitations imposed.

Yeah, that's pretty much the gist of it. You can make complete, good games in it too, no doubt! Just be prepared that at (at least if you’re already at some point, for advanced enough users, the tool will stop supporting the changes you make, and at that point it'd been better to keep all resources transparent and as separate files, for quick text editing (as opposed to string searching with a hex editor and deciphering data formats) or in case the changes you want to make will break the GUI part of the tool.


EDIT:
Just to correct myself, there seems to be support for 36 unique metatiles per screen and bank, not 24 as stated before. You have one partition of 24 metatiles, and one of 8; both directly organized as such in chr-ram. Plus the 4 "path" strips, as mentioned before.

Wow - that was quite a breakdown...thanks! And feedback like this is always pretty great to hear from actual NESdevs too.

Yeah, we had to straddle a lot of lines...how to do xyz in a streamlined way, that could cover the broadest possibilities the most easily. There is, however, a future plan for a library-graphic system like what you're describing where values are still metatiles, but it alternately references library values rather than strict tethers to the tileset. It's fun how people showing us how they use the tool helps us inform the changes to make. I hope more with nesdev experience dig in a bit and get with us to offer suggestions, how it would help them do their thing, etc. Those are the sorts of suggestions we like.

And yeah, we're hoping the plug ins blow it wide open for folks who have ideas we might not have thought of. Already, someone built a GUI interface for a sprite based hud rather than our tile based hud system, which was a great test!

Also - it's awesome to hear that you've used the tool to wireframe graphics!!! We're hoping that even seasoned devs who have their own resources will eventually find some part of the tool useful in their toolbox, so thanks for confirming that, too!

You guys rock.

Another use is to quickly check if a sprite + sprite palette works against some certain backdrop + bg palette combination you've drawn. When you've got a full game engine going on, that's easy to do, but when you work on concept graphics before there is any game, this quite useful and only takes a minute.

I'm happy you feel that way! I cannot thank you enough for the effort you've put into this tool, and for keeping developing it. As a GUI designer for public space kiosks, i recognize that once your product gets out in the wild, there's always lots of use cases you could never have foreseen - which i've found can be both amazing and frustrating.

I think one difference you might see between people who've been already knee-deep in assembly programming and nes game design, and the new group that make the NESmaker user majority, is that the latter group will largely adapt and be closely inspired by your personal workflow through your video tutorials, while the former group will try applying and adapting their already established workflow to NESmaker. This means doing things in a different order, for one thing, which may cause some "feature gaps" (which is always a subjective thing for each user) to magically appear.

For example, in your videos, you create assets and objects, assign them properties, and then paint some screens. But if you for example create assets and objects, paint some screens, and then assign properties, you're put in a bit of a spot currently as maps won't auto-update accordingly. It's a bit of a tricky situation though... if implementing auto-updates to the meta screen tables, you'd need to identify intentional property deviations made by the user as to not overwrite them. I guess comparing previously held tile/path property with screen contents should mask out what cells to update with the new property.

Speaking of map construction, have you thought about implementing edit filters like the ones in NESST? I'd not copy the checkboxes which can get in the way and confuse users at first, but holding for example shift and click to only "paint" properties from an asset, or ctrl+click to only paint the metatile of an asset without overwriting previous properties would accelerate level building by some.


This is great news! Just to show you something NESmaker related i'm working on. I'm still reworking the tileset to better fit the current NESmaker scheme, so it still looks less detailed than it actually could, but here's the rationalization-in-progress:


which works fine from a gameplay perspective. I think i can get a lot more out of it, though, especially with the "ignore path" property you've introduced semisecretly, if it is going to do what i think it does.

Second picture is an earlier mockup draft.

I'd need to rationalize & remove some uneffective tiles from there to include rocks and other mechanically needed tiles, but this (or more, really) is about the level of detail you could get out of NESmaker with a metatile reference library, even when needing a text/symbol table occupying several rows of chr-ram.

I'm building an arcade cabinet experience for a local museum that are producing an exhibition about trash in general and sea pollution in particular. The cabinet itself, including special peripherals (and the whole exhibition for that matter) is built out of salvage, second hand electronics and new-old-stock parts. The game is about sanitizing the coast off trash in a dystopic near future. The game reflects points and items in the exhibition. Between the material costs and time spent constructing it and the budget i'm, using NESmaker felt like the obvious choice to get it all done on time. This project wouldn't be sane without NESmaker providing both GUI tools and a solid backbone to build on. Having it lets me focus all the more on conceptual and game rules design and not worry so much about this or that method for controller input, whether to use samples or not, and so on.

@FrankenGraphics

When I see what you can do with nesmaker, it doesn't even look like there is any kind of limit I guess an artist that knows how to work around them should be able to make impressive things, that's for sure.

Love those arts, would love to be able to make such nice things like that on my next project but I'm a dev after all ^^;;;

For sure, but i see this restriction in all nesmaker games (even though there's some really impressive work being done graphically within those restrictions). I want to stress that it's not a bad thing for each game in itself, it's just a really big restriction (i think it's the most significant one present) to impose through the tool if it can be avoided, because it limits the range of games and what also the expression they'll take.

A lot of the new people coming in to the scene are artists, not programmers. "Programmer art" is a known concept. But there's also a reverse phenomenon: Artists that have the skill to make a unique expression, but aren't necessarily experienced with just what the medium offers technically. In that case, it's not easy to know what is a hard restriction and what is a malleable one, and what is a reasonable model of screen/level compression. You need to be a bit both artist and programmer to be able to compare the merits of one level compression scheme to the other, at least on your own. Even if in a group, this is a difficult communication point.

The way i view the current system: you need to accept a certain minimalist, blocky style (more so than the attributes impose) and a somewhat "absolute" approach to what individual chr tiles (and 2 by 2 groups of them) are supposed to represent. It may be hard to tell the difference in those two screens because neither was fully developed at the point of screen capture. But note the very freely placed borders between different terrain types and that you can stack these within each other in the mockup, including off-attribute grid placements, diagonal lines, elaborate border details. The sacrifice is needing a common colour across at least 2 subpalettes, but that choice is free for the artist to make. Another thing that is very hard to do is shadows relative to the position of solids. I could go on. It's fine if you want to emulate the styles common to the years 85-87 (loosely speaking and not a bad thing either), but if you want to do something other than that, you want a metatile reference table. It's just that versatile.

You're right that you can do a lot even with 32 2x2 tiles. For example sacrifice one palette and use a fade-to-black(or other fill colour) aesthetic, and you can have one subpalette be one step darker than the others and reuse all 32 metas as far-off background, practically doubling your resource, depending on the contents. Since two colours in that subpalette now are black/fill, the contents will look very different. I started using this trick extensively in the new levels of project blue because i wanted more than 256 2x2:s per level, lol. Of course, the # of metatiles available at the same time doesn't mean anything unless you relate it to the # of screens you're using them across, how they're shared/segmented, and how many you're using on average per screen. Project Blue is stretching the same 256 metatiles across sections of 64 screens, which is a bit thin-spread and an artifact from the needs to fit the compo mapper (rom size) restrictions. But being able to freely combine tiles in your metatiles allows for shaded, tile-reusing backgrounds like this:

Thanks for your kind comments about the art.

Wait, museums in Sweden use retro arcade styled games to get their message accross? Screw me sideways, that's awesome. I like "classic" museums, but it's true that it's difficult to make them interesting to these who need the most to discover new stuff, kids and teenagers. If I had that as a kid, I'd have demanded museum trips every week-end!

It looks like games that are created with the PAL flag set don't have the NES 2.0 identifier in the header. Can anyone confirm they are created this way? My understanding is those flags should only be used if header indicates 2.0. Am I mistaken on this?

One of them are, as of this spring, at least. I've worked with museums before to avoid the generic touchscreen + web app fare (which works sometimes but tends to be either understimulating/not attractive to the youth, or underperforming technically) with more robust, thematically specialized solutions, but building an arcade cabinet is sort of a first for me. I took notes while doing a study on the soviet arcade museum in st:petersburg and the project is sort of a mashup of a NES and the sort of peripherals russian arcade cabinets were commonly using (discrete electronics and vacuum or gas tubes to show points).

Museums often find themselves in a position where they don't have the budget to compete with the general attractiveness of podcasts, video streaming, online databases, various internet phenomena and commercial games, but also need digital solutions to reach out, or just use them to maximize the potential of an exhibition. Retro-styled games can circumstantially be a goldilocks solution. Designing a game for an arcade hall and designing an exhibition-enhancing digital module can have a lot in common - you need to attract first-time and one-time users, and you probably want them to leave wishing to return/talking about it with their friends.

The plans are still vague but i'm planning to host a high-score competition and hand out some prize carts once everything is put in place.

This project wouldn't be feasible without NESmaker. It could hypothetically be with an all-original code base (and my own is incomplete), but enormous amounts of time is saved simply from having a level editor to go with that code.

(Semi-off-topic; may need separate thread) NES 2.0 is not needed for NTSC vs. PAL identification. Bit 0 of byte 9 in the classic NES header controls that. If an emulator chooses to ignore that, for whatever reason, then that's a bummer. Reference material: https://wiki.nesdev.com/w/index.php/INES

(As has already been hotly discussed, iNES-1 headers are not trustable to be authoritative, and so support for the iNES1 PAL/NTSC bit is rarified, and all emulators that are known to support it added it at the same time as NES2.0 support)

FrankenGraphics - for what it's worth, you COULD design a plug in to handle these sorts of graphics, and just write your own tile loading code rather than use the loading code that comes pre-packaged. The only draw back is that you wouldn't see it visually represented in the screen painter. At least, not right now. But I thought it would be worth mentioning that even this is possible currently.