The New 8-bit Heroes: New NES game and creation documentary
Created by Joe Granato
Latest Updates from Our Project:
Today is a monumental day...
about 8 years ago
– Wed, Jan 10, 2018 at 06:36:47 PM
Today is a monumental day.
What you're seeing in this image are physical evidence of the three major deliverables that you have helped bring into the world. This is a VERY brief word about each:
1) We set out to make a documentary. Our plan was for a small scale, 90 minute film that explored the homebrew community. Now in reality, here is our film...what you see pictured is a blu-ray with a 112 minute, award winning documentary about an international journey of self exploration that is getting tremendous reviews both inside and outside the gaming community, featuring some of the most notable figures in retro gaming, and with two hours of bonus material!
2) We set out to make an NES game. Our plan was to create something on par with Arkista's Ring...simple, middle of the road, and what we thought would be within our grasp to do. While what is pictured is only the prequel for our ultimate NES deliverable, now in reality, here is a NES game! Even as just a prequel quest, it far surpasses our original intent, and while Mystic Searches is still a work in progress, that means this project has allowed us to create not one but TWO installments into the NES catalog!
3) We set out to make resources for aspiring NES developers. Our plan was to create a series of tutorials. Instead, we have inadvertently created an entire development environment for the NES! Now in reality, here is the physical component of our tool!
All of these things now exist in the world, and it is thanks to you and your patient support! We will be continuing to improve Mystic Searches and refine our NESmaker tools, but...today is the day that we have concrete evidence that all of the things we set out to create...a film, a playable NES game, and resources for aspiring developers, now exist in the world thanks to your help!
So that I can focus 100% of my effort on Mystic Searches, we will be launching a crowdfunding effort for NESmaker, so that we can bring Josh (our tool developer) on in for more concerted effort in expanding what it is capable of. For those interested in making your own NES games, you'll want to at least check this out!
Some firm dates I can give:
The kickstarter for NESmaker begins Friday at PAX South. If you're attending, please come by the booth and check it out!
The BluRay release event is Saturday at PAX South, at our showing there.
As soon as we return, BluRays will begin to ship out to those of you who are getting a copy of the film. For those getting a digital copy, you'll also be getting your Vimeo codes at that point.
Love you all.
Joe
Happy New Year!
about 8 years ago
– Mon, Jan 01, 2018 at 06:17:14 AM
Happy New Year everyone! Not much time to write, but I wanted to let you know a few things.
1) GAME NEWS - The prequel game, Mystic Origins, is starting to arrive on doorsteps!
2) TOOL NEWS - The NESmakers group is growing extremely fast. You can join it right now at www.facebook.com/groups/NESmakers! We will be posting relevant info and updates and videos there and hope to start a cool community of aspiring NES developers!
3) FILM NEWS - The New 8-bit Heroes hit Amazon today! Now, most of you guys are getting some level of film as part of your reward, and that is coming very soon, however if you want to spend New Year's Day with us, here are the links!
Merry Christmas to all...
over 8 years ago
– Mon, Dec 25, 2017 at 01:26:35 PM
Merry Christmas to all, and to all...new NES games? :-)
Here's a relatively short update with what we've been up to the last few weeks.
1) The Game: Austin and I have been managing the monsters and NPCs, grouping them by their respective geography in the game world. It's tricker than you might think. It's not just a matter of creating the objects and then placing them where we'd like. Instead we have to conceive everywhere we might want monsters to appear together and then make sure they all fit on the same tileset. For instance, if we want one of our big hulking skeleton monsters (burnout) to be on the same screen with bats flying out of caves, guarding a magical muse creature, all three of those have to be on the same tileset. If we also want bats to exist in other parts of the game, we have to load redundant graphic data for the bats...but of course, we want to do that as sparingly as possible to make the game as interesting and diverse as possible. It's like playing with those picture puzzles where you have to keep moving pieces until it makes an image.
But one part of it that has been fun has been using the game's colosseum to test out monster AI and make sure that it's all working before populating the monsters in their respective areas. We have to test them somewhere. Ordinarily, we'd just use a dummy screen, but this was much cooler!
Zmeu's Colosseum
We will likely be throwing up a series of videos showing us testing various monsters in this colosseum, just for fun!
Also, the music for the game is done. After a lot of code massaging, simplifying of sound effects (I mean, does the item selection sound really need reverb?), simplifying a few of the songs (which was heartbreaking), and removing unnecessary data, I am proud to say that Mystic Searches will include 15 original tracks. I will be posting a series of videos soon on YouTube that show off these songs and the creative process behind them. For those that might want to see that, make sure you're subscribed to www.YouTube.com/TheNew8bitHeroes.
Also, as stated many times, a finished NES game is complete as per this project...the prequel Mystic Origins. Though it is only a small vertical slice of what Mystic Searches will be, it is completely its own story, it's own mini game world, and is a fully playable game. You can get a copy at our site at www.TheNew8bitHeroes.com - the first batch will be going out in the next two weeks.
2) The Film: Well, it's finally that time. The New 8-bit Heroes film is hitting AMAZON on NEW YEARS DAY! What does that mean for backers? Well, let me lay a few things and dates out there:
NEW YEARS DAY - the film hits Amazon. Rental is something like $2.99, purchase $9.99. Most of you are already getting a digital copy, and many a physical copy as well. But anyone who wants to help celebrate it's wide digital launch and can spare the $2.99, we'd love to have you join us on New Years Day to start the year off optimistically! I'm almost certainly getting on a giant group chat that evening for anyone who wants to discuss the film (and the project in general). I may even be demoing some process work with screen shares if I can figure it out. For more info on that, GO HERE AND JOIN THE EVENT! And invite any and every 8-bit loving miscreant you know, whether you plan to wait to get your copy, have already seen it, or will be experiencing it for the first time! :-)
PAX South, in the middle of January, will mark the Blu-Ray release event. A few days prior, the day they come back from manufacturing, we will begin fulfilling Blu-ray orders. How long it will take for us to get through them all, I'm not sure, but we will also be trying to confirm everyone's address one by one before sending things out, so please be on the lookout!
Around that same time, we will be issuing a special code to anyone due the digital reward of the film. You will have access. Unfortunately, Amazon does not have this feature, but we can utilize our Vimeo page to offer this to everyone who is due this reward. Again, please be on the lookout for this, as these codes will be VIP codes, and will likely be associated with your email.
3) The tools: NESmaker crowdfunding will also begin at PAX South. We just made some huge decisions regarding how it will handle expansion, dealing with multiple projects, etc. We are so excited that this is an outgrowth of this project, and can't wait to see what you guys come up with! All of the backers who pledged the Developers Package tier are already grandfathered in to getting NESmaker.
That's it for right now. I hope everyone is having a great holiday. I look forward to a great 2018!
A lot of things...short and long...
over 8 years ago
– Fri, Dec 08, 2017 at 12:31:15 PM
I'll give both a short, bullet point update, and then below, elaborate on each point.
THE SHORT UPDATE:
THE FILM: The film is slated to hit Amazon on NEW YEARS DAY! The blu rays are currently being manufactured, slated for release only a few weeks later.
THE GAME: Making boss and mini boss behaviors. Compressing the narrative to fit.
THE TOOLS: Making more modifications on title screen editor and hero editor for NESmaker. This will hit the universe at PAX South!
THE LONGER UPDATE:
THE FILM: We were so happy to be able to include so much bonus material onto the blu ray for this project. We managed to pull about 50 minutes of extended interviews from people like James Rolfe, Adam F. Goldberg, Mike Winterbauer, Tommy Tallarico....at least a dozen more, with some random, raw thoughts about the NES, post market development, retro gaming in general. What's funny is, even in doing that, we weren't able to scratch the surface of the 7tb we captured over the course of the two years of filming! But we crammed as much as the blu ray disc would hold!
We also included an entire sequence which was scrapped in the final film. Some of you may have seen it when we had it up on Vimeo for a short time - our dramatized trip to the desert to meet up with Rob McCallum. Eventually, this got scrapped because the dramatization was painfully obvious, and as fun of an adventure as it was, we felt that it took away from the film. Ironically, what *feels* dramatized is all based 100% on reality. We just attempted to force it into a micro-narrative to make it more watchable. We set things up and write some dialog to make the things experienced work better as a story arc. As an experiment, it is not congruent with the way the rest of the film was told. But...it's on the blu ray for you guys to enjoy as a short bonus.
The third bonus feature is a raw collection of interviews that were captured while gearing up to film It's Dangerous To Go Alone...The Movie. The movie stalled before it ever even got started, however as a running start, for about a year I traveled the country on my own dime to grab some interviews from notable creatives or artists who were inspired by The Legend of Zelda or creators making Zelda themed things. This wasn't meant to ever be a film about the Legend of Zelda, but rather about it's influence on contemporary culture. When the film's crowd funding effort failed, the project died on the proverbial vine, but ended up almost directly leading to The New 8-bit Heroes. So I recycled a documentary featurette I once created about traveling to Baltimore to film the Baltimore Symphony Orchestra perform the Symphony of the Goddesses. In the original featurette, I included a montage overview of interviews I'd done...in this version, I actually reworked that moment where there was once a quick overview montage to instead actually showcase over a half hour of those raw interviews. While this will never be the documentary I'd planned for It's Dangerous To Go Alone...The Movie, at least it gives a logical outlet to showcase some of this lost footage. And what's ironic is, the frame story of this 40 minute featurette becomes a perfect thematic prequel to The New 8-bit Heroes.
Lastly, there is a slideshow of concept art for Mystic Searches, some if it never before seen.
That's a lot to cram on to that documentary! The almost 2 hour feature cut of The New 8-bit Heroes, 50 minutes of bonus interviews, a 40 minute documentary featurette on influence of The Legend of Zelda, and dozens of pieces of concept art for Mystic Searches! For those that are receiving physical copies of the bluray as part of your reward, we will be in touch early Jan to make sure we have correct addresses for you!
For those that can't wait, we'll let you know when the film hits Amazon, and we hope to have your support spreading the word!
THE GAME: I spent the last week or so working on new behaviors for mini bosses and bosses. One of the major differences between a *boss* type monster and a normal monster in our engine is the need for added complexity. Sometimes, a boss is made up of multiple objects (two hands and a head, let's say). Sometimes, a boss actually morphs objects (changes from a man to a dragon and back). This is what makes these monsters feel like escalated opponents rather than run of the mill AI. We've had to create methods of parenting objects, where the parent passes certain data to the child (for instance, hit points). Alternatively, we've had to create a paradigm for an object acting like a *controller* object, which controls all the objects in a scene, even though it feels like you're simply interacting with each component piece. This is not easy to do with the memory limitations on the NES, or how our engine is currently structured. However, it's mostly going very well. One of the challenges has been in object lineage of different sizes. If a monster that is only 1 tile wide turns into a monster that is 3 tiles wide, sometimes that one tile wide monster can move all the way to a solid object, then change, and then the monster is stuck in the wall. We've been working on solutions for problems such as that.
As far as having created a NES game for this project, that feat has been accomplished. Mystic Origins, the prequel quest, exists in the world and is ready for consumption! For those who have missed it - Mystic Origins is a prequel quest. It was originally a beta...a 10% vertical slice of where we were with the engine. Some of you played its buggy on line version. We were able to refine it and tweak some of the bugs, and now it's its own unique prologue adventure. While it is short, even this shorter game is more complex than anything we thought we'd be able to create when we first started the project. We honestly COULD have called that game Mystic Searches and used it to fulfill the promise of a NES game. But, it is only a slice of what Mystic Searches will actually be. We don't want to cut corners with it, as it's a project we are very passionate about. So, for those that *just want a NES game*, and any new NES game will do, Mystic Origins is complete and ready to rock. For those that want to just get as much NES goodness as they can, or want to immerse themselves in this new fantasy universe, Mystic Origins is a great starting point. It's a great holdover until Mystic Searches can finally be completed.
You can pick it up at our website - www.TheNew8bitHeroes.com on the shop page.
THE TOOLS: The goal with the tools is to make a self-inclusive, drag and drop WYSIWYG development environment for creating NES games. This means taking the tools capabilities beyond what was needed for Mystic Searches. A perfect for instance - we created many of our graphics in Photoshop, then converted them into 4 color, 8-bit BMPs, then loaded them into things like NES Screen Tool to make CHRs files that NES can read. But in order to streamline the process, we built a graphics editor INSIDE of our tool, that handles working both with the 8-bit BMPs and produces the CHR files on export, so we never have to leave the tool at all. We're trying to apply that everywhere, so that this is a single resource that can be used. The latest development is creating *special screens*, which are made up of 8x8 tiles rather than 16x16 metatiles (read: more detail, but also 4x the number of space). Special screens are things like start screens, end screens, game menus, story screens, etc. Rather than have to build these screens externally, now someone can easily design them from inside the tool itself, without having to worry about creating CHR files or thinking about where to put the resulting nametables. Just create the screens using a simple interface and have all the data created and do what it needs to do upon export.
This is the latest on the tool. We'll be showing off these on our YouTube show, where we're showing off the NESmaker tools. If you haven't subscribed yet, that's at www.YouTube.com/TheNew8bitHeroes.
Lots of things happening at the end of 2017/start of 2018!
The "Tetris" puzzle that is NES memory management
over 8 years ago
– Thu, Nov 30, 2017 at 10:32:30 AM
This post has to do with memory management, the real reason the NES is so tricky to develop for. It will hopefully explain why every NES game is so dramatically different at the code level, how memory management considerations factor into the development time of a NES game, and how it is like a whole other art form compared to modern development.
So we talk a lot about how little memory games for a system like the NES have, but how that correlates to programming these games is a bit abstract. The average person has a loose understanding of how those limitations result in simpler graphics or chiptune music, but have never considered how it actually effects design.
How do modern games handle object data?
Let's talk about making a game in a modern tool first. Let's pretend you wanted to make a game in GameMaker. It's a pretty intuitive, fairly versatile little program that is great for beginners. Essentially, you create *objects* and give those objects various properties (what graphics they use, how they behave based on certain input or game states, etc). The interface is clean and intuitive once you learn it, and looks like this:
GameMaker Object Interface
So in this GameMaker object called Player, you can generally get a feel for what's happening. When it collides with certain objects, things happen. When you press left, right or space, things happen. It uses the graphic of a little space ship.
I could honestly keep adding details to this object and its behavior endlessly. There are virtually infinite combinations of choices and actions and functions that can define this object and how it behaves in a game.
Or we could take a look at a program like Unity. Unity also utilizes a friendly object oriented environment. Its objects are called Prefabs. The design of how the object interacts with the game is more code-centric so it's a little more abstract to show, but it's also pretty endless of how you could define an object and how it can interact with the game.
Unity PreFab Editor
How does NES handle "object data"?
The NES is NOT an object oriented development environment. It is a much dumber piece of technology than those used to play GameMaker or Unity games. It's the difference between someone communicating fluently in a language with an understanding of a dictionary's worth of words versus trying to communicate with a handful of grunts and gestures.
For a moment, let's talk about how our particular engine works (and most other NES engines have some sort of similar paradigm). The NES operates by reading values at certain addresses in the memory. In our game, we have a slot of 512 bytes in RAM devoted to objects. Each byte can hold a 256 value number, and the NES can read that number (or in some cases, its bits) to determine how to proceed.
So for instance, objects can be either on or off. If they are on, they should be drawn to the screen. If they are off, they are drawn off screen and don't interact with the game. Simple enough in concept.
The first set of bytes in RAM use the label ObjectStatus. There are 8 ObjectStatus bytes (why 8? We'll look at that in a second). The first BIT in these bytes determines whether or not an object is turned on.
So, if I want the first object to be turned on, I would need to write #%10000000 to the memory address occupied by the label ObjectStatus. Notice the 1 in that high bit. If I wanted the second object to be turned on, I would need to write #%10000000 to one memory address beyond ObjectStatus (so, ObjectStatus+1). Essentially, that high bit in ObjectStatus + 0 through ObjectStatus + 7 give me the on/off values for each Object. In the object update routines in the game, or in the the object draw functions, it'll take a look at these bits and say "Yes, draw that object" or "No, that object is off so skip drawing it".
The next set of 8 bytes tell the 8 objects where to be drawn horizontally on the screen (their X value), while the eight that follow that tell the 8 objects where to be draw vertically on the screen (their y value).
So if object 0 is turned on, it would look at ObjectX to know where horizontally to draw it. Now, remember how I said each byte can hold a value from 0-256 (an 8-bit value)? Well this explains why the resolution for NES games is 256 pixels wide. An x value can be anywhere between pixel 0 - the left side of the screen, and pixel 256 - the right side of the screen.
If Object 1 is turned on, it would look at the value in memory address labeled ObjectX+1, and that would tell it where to draw Object 1 horizontally.
So we have a series of *variables* that are essentially sets of bytes that define object properties. ObjectStatus, ObjectX, ObjectY, ObjectSpeed, ObjectSpawnType, ObjectDirection, ObjectHealth, and so on and so forth...each label being 8 bytes long to represent the 8 possible objects.
The difference from game to game:
Now, even though most NES games do something similar to this, there is no hard and fast rule on how to set this object scheme up. Some games have objects that only need a handful of *variable* bytes, and they might be set up for dozens of on screen objects at a time. Some games may get very particular in conserving all the bit data possible and figure out cool ways to optimize and compress all that variable data. Some games use far less than 512 bytes for objects, and some far more. The labels that we created to handle our data may be wholly different from those that another game would use to handle their data. The fact that we use these very particular 512 bytes for our objects, and the fact that they're set up the way that they are, is simply because it is what made sense for OUR game engine, not a testament to how the NES works in general.
For instance, our game is sort of a 2.5d engine. That means you can move up/down/left/right like in a top down game, but also jump in an imaginary z direction. This means that our movement and position must factor in an extra plane (z), that our collision detection must be in the form of a cube, not just a rectangle, that we have variables such as jump height and gravity that other games might not have.
Using the data:
Every frame of the game, a routine loops through the values and updates the objects accordingly. This can get super complex depending on what's going on, but, it essentially works like this:
Look at ObjectStatus+0. Is it on? Yes? Ok. Then draw it at ObjectX+0, ObjectY+0. Use animation frame that is in ObjectAnimFrame+0. Look at ObjectStatus+1. Is it on? Yes? Ok. Then draw it at ObjectX+1, ObjectY+1. Use animation frame that is in ObjectAnimFrame+1.
...and so on.
Obviously, a lot more is happening than just *where to draw things*, but hopefully that's an easy enough example for you to understand conceptually.
One of the challenges:
One of the challenges of developing like this is how to manage that memory. Our Objects currently require 54 bytes each to function. We allow for up to 8 objects at a time. 54 bytes x 8 objects = 432 bytes in a 512 byte space in the games memory. We could conceivably have 9 objects (486 bytes) in that space, but not 10 (540 bytes would be too many). But you can imagine how limiting it is to only have 8 objects on a screen. What if you had the player, two projectiles, his melee weapon, two power ups on the screen...you'd only have room left for one more object (a monster, maybe?). All of the sudden, the memory limitations begin to play a huge role in what can be done in the game. Unlike a program like GameMaker, to where you're not worrying about or thinking about memory and you could add an infinite number of monsters on the screen until the computer choked from trying to perform so many tasks at a time, the NES only has so much space to store object values.
One of the ways we optimized this was to have different classes of objects. There are *core objects* which utilize all 54 values, but there are also several objects that don't need that information. A power up doesn't need hit points. A poof effect doesn't need acceleration. A projectile doesn't need experience worth value. There are many objects that just need on, type, and coordinate values. We can express each of these items using a limited set of bytes (filling out the rest of the 512 bytes we have reserved for objects). Now, during the game update phase, we can update the main objects, then update the limited objects.
When this leads to trouble:
Let's say that this is all mapped out, good to go. Utilizing exactly 512 bytes to maximize each object. But then, I realize that i want each object to be able to...oh, I dunno..have it's own spawn type (some coming up from the ground, some coming from the edges, some falling from the sky, some randomly appearing). I can make another set of 8 bytes, one for each object, with the label ObjectSpawnType. I'd add 8 more bytes to my memory map.
But I don't have 8-more bytes. I'm using all 512 that I have made available for monsters.
I have choices. I can look for bytes that may not be using all the data (for instance, since our game only has four frames of animation, the values can ever be 0-3, which can be expressed in 2 bits...leaving six bits unused). I could combine labels that only make use of partial bytes. But if I do that, I have to get back in the engine and find every single place that a function references these bytes, and I have to rewrite how the data is gathered.
And example. Let's say I have these two bytes:
ObjectAnimationFrame (can be 0-1-2-3, so can be expressed in just two bits), and I have ObjectActionType (can be 0-1-2-3-4-5-6-7, can be expressed in just three bits).
Ordinarily, I would just read ObjectAnimationFrame+0 to let object zero know what type of animation to show, then I'd read ObjectActionType+0 to let object zero know what action that object should be doing.
So I'd have to rewrite the functions that READ this data to do some crazy math to just read the first two bits of that for the animation data, read only the middle three bits for the action type. These new functions take up bigger ROM space and actually takes the processor longer to process, marginally slowing down the game. Do this too much, and you'll run out of rom space for code or slow the game to a crawl (we all remember NES games that did that!).
But after reworking that, I could have a byte that would allow to to specifically give each of the 8 objects a unique spawn type as part of their properties this way.
With a modern engine, you'd just create a new variable and give it a value, then tell the object what to do when it sees various values. The whole concept of trying to play Tetris with the memory this way doesn't exist.
For those that are really into the behind the scenes of this process, I thought I would share all this, as we are now in one of those positions of considering playing tetris to get something working *right* rather than the way it's sort of held together with proverbial duct tape right now.
