It is currently Sat Nov 17, 2018 6:55 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 41 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Wed Aug 29, 2018 8:50 am 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 38
Location: Montreal, Canada
Hi.

I've been working on-and-off since the spring on a little zelda-like adventure game. I thought id share what i have so far, maybe that will start a discussion, maybe not at all.

I've mostly been working on the foundations of the engine and tools. I have zero gameplay element, that will come next. Everything you see if obviously a placeholder (my character is a litteral crash test dummy to make this extra clear). I am not an artist in the slightest. I eventually hope to reach a point where I have enough of a game to partner up with a real artist to make this look real nice.

So here is what i've got so far. I'll cover some of the details of each in this post:
  • 4-way scrolling (100% artefact free)
  • basic assets (metasprites/tiles, animations, levels, etc.)
  • basic editor
  • small scripting language

Before i start rambling on, thanks to everyone who answered my questions. Thanks to Sour for Mesen, aka the greatest development tool, after visual studio.

4 way scrolling

Using vertical mirroring and assuming an overscan of 8px on the top and bottom of the screen, that leaves us with 16px to hide all of the attributes defects. This mean that if we are pixel-perfect, we can get really nice 4-way scrolling without using any special mapper (I use an MMC3)

Here is it running in a small C# version of the game I use for debugging. I use black bars to hide the overscan. When I switch to the debugging mode, there is 2 sets of red lines, one with the overscan and one without. Notice how all the artefacts are kept outside of the visible area. Note that the red/yellow squares are kept on screen for a few milliseconds, i'm not updating that many tiles.

Image

Same thing, in Mesen.

Image

It is a small level but it has been tested on huge maps and supports up to 8 screens on each axis (assuming you have the ROM/RAM to hold the data).

If you are planning to reproduce this, I *highly* advise that you create yourself a reference version in a language that is more "flexible" than ASM. The final ASM version is about 2000 lines of codes (including the code to prime the screen initially, and render some background animations). There are some nasty edge cases to handle, especially when it comes to stitching the attributes of the top and bottom rows, and on edges of name/att tables. Doing this directly in assembly would have been very time-consumming.

Basic assets

Here is a quick overview of all my asset types.

Image

Here is what each of them are:
  • Animation: A series of keyframe, each of them being a Metasprite.
  • AnimationSet: A bunch of animation together. This both represents a 1KB switchable bank of CHR ROM and the PRG ROM data for the keyframes.
  • BackgroundAnimation: Allows animating the background.
  • Bank: Represents an switchable 8KB bank of PRG ROM. You can dump assets in there as long as you dont go over 8KB. Right now only 8 are displayed because I have so little content. Ultimately all 64 might be there.
  • Level: More of a "room" than a level really. Comes with things litle triggers and scripts. More on that later.
  • Metasprite: Bunch of sprites stuck together.
  • MetaTile: a 4x4 grid of sprites. So my metatiles are 16x16.
  • MetaTileSet: a bunch of MetaTiles togheter. This both represents a 2KB switchable bank of CHR ROM and the PRG ROM data.
  • Palette: Duh
  • Sprite: Duh

More gameplay-related assets will be added in the future, this like text, dialog, music, etc.

Basic editor

If you every worked in the game industry, you know how tools are much more important than whatever fancy tech you may have. That's why engines like Unreal are so popular. Their tech is by no mean outstanding, but their toolsets are super flexible and allows artists to have total control over their content. So I decided to spend some times on tools.

The tools handles all the packing in CHR ROM, updates everything automatically. You can safely delete stuff without worrying about your level being completely messed up. It works pretty well.

While you *can* paint sprites and stuff in my tools, there is no way I am going to be able to compete with Photoshop. So I added support for copy and pasting images from external applications. It automatically creates sprites, assigns palettes, detects flips, etc. Here it is in action. Notice how it detects that the hat is a flipped version of the same sprite and how it matches the rest of the body to existing sprints.

Image

You can also compile and launch the game from the level editor:

Image

When you export the data from the editor, you simply need to include a couple of ".inc" file in your code and you are ready to go.

Scripting

My game will not be 100% systemic. By this I mean I want to be able to create unique moments like in Zelda games. Things like:

  • You enter a room, the music changes, a big bad guy appear, you kill him, them a chest appear in the corner, etc.
  • In a room you have 3 switches on the wall, if you dont press them in the right order, a monster appear, if you solve the puzzle, a door opens.

So i added a little scripting language (it is BASIC-inspired, the first language I learned as a kid). It compiles to some bytecode i made up. It supports a bunch of stuff (loops, arrays, complex math expressions and conditions, etc.) and can also make calls to "engine functions" which are implemented in ASM.

This also allows me to prototypes functionality that I am still not sure how it is going to work. Here is an example of me using it to prototype a door opening and a room transition. As the character hit the trigger next to the keypad, it plays a background animation of a door opening (thus changing the collision) and the room transition is done by another trigger.

Image

Please understand: NOBODY IN THEIR RIGHT MIND would use scripting to open a door and do a room transition like this if you are going to have 3 doors in every room. Of course you would want to make that code part of the engine. But is it good enough for a quick prototype? Absolutely.

The level has 3 types of objects that the script knows about: locators, routes and areas which are respectively 0D, 1D and 2D objects.

  • Locators are simple points, simply to represent a coordinate
  • Routes are paths, which will be used to assign path to AIs, for example.
  • Areas are rectangles, which can be used as trigger (and other stuff later).

A script is assigned to a level. It can have global variables that are kept alive as long as you are in that level. The script can only react to specific events. I dont want any kind of scripting to run on every single frame. Right now the only 2 events I have are:

  • on_level_init: Called after a level is loaded, but before it is rendered. This is where I will be spawning AIs, setting up the inital state of things like doors.
  • on_trigger_touched: Called when the hero enters a trigger. The id of the trigger is passed as an argument.

More will be added as I go along.

Anyway, that's it for now. Hopefully I will keep working on it a have more to report.

-Mat


Last edited by bleubleu on Wed Aug 29, 2018 9:50 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 9:05 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
NES Maker look out! I'm impressed, good work!

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 9:41 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2333
Location: DIGDUG
Are you sure you didn't mean "milestone"? BTW, you can edit the title by editing the first post in a thread.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 9:50 am 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 38
Location: Montreal, Canada
dougeff wrote:
Are you sure you didn't mean "milestone"? BTW, you can edit the title by editing the first post in a thread.


Oops. Fixed thanks!


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 10:52 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
That tool looks really elegant. Nicely done! Looking forward to see your progress with your game. :)

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 10:52 am 
Offline

Joined: Fri Sep 30, 2016 8:57 pm
Posts: 94
very impressive work, good job!

as soon as i finish up my current game i'm going to start work on a similar set of tools for the next several games i make.


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 1:05 pm 
Offline

Joined: Tue Aug 28, 2018 8:54 am
Posts: 68
Location: Edmonton, Canada
Impressive work.

P.S. You may not be an artist, but your dummy looks good :)


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 2:44 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
I suppose I'll ask, have you plans to share these tools? I totally get it if you're not, just curious. No pressure.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 4:23 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10973
Location: Rio de Janeiro - Brazil
bleubleu wrote:
Using vertical mirroring and assuming an overscan of 8px on the top and bottom of the screen, that leaves us with 16px to hide all of the attributes defects.

The problem with the assumption that TVs will cleanly hide 8 scanlines at the top and at the bottom is that... they won't, you'll find all sorts of picture alignments out there. Also, PAL TVs will always show all 240 scanlines, or so I've been told. If you want true artifactless 4-way scrolling, you'll need tricks or 4-screen name table layout.


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 4:28 pm 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 38
Location: Montreal, Canada
tokumaru wrote:
bleubleu wrote:
Using vertical mirroring and assuming an overscan of 8px on the top and bottom of the screen, that leaves us with 16px to hide all of the attributes defects.

The problem with the assumption that TVs will cleanly hide 8 scanlines at the top and at the bottom is that... they won't, you'll find all sorts of picture alignments out there. Also, PAL TVs will always show all 240 scanlines, or so I've been told. If you want true artifactless 4-way scrolling, you'll need tricks or 4-screen name table layout.


I understand. But compared to most games I play that attempt to do this kind of thing (SMB3 being a good example), I say this algorithm is far superior.

-Mat


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 4:29 pm 
Offline

Joined: Wed Apr 04, 2018 7:29 pm
Posts: 38
Location: Montreal, Canada
Kasumi wrote:
I suppose I'll ask, have you plans to share these tools? I totally get it if you're not, just curious. No pressure.


When I release something (or get tired or coding it) ill totally dump the code somewhere.
In the meantime it is still too much of a WIP to release anything. It looks OK in animated GIFs, but it is not in a form that I feel comfortable releasing yet.

-Mat


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 4:47 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6955
Location: Canada
bleubleu wrote:
I understand. But compared to most games I play that attempt to do this kind of thing (SMB3 being a good example), I say this algorithm is far superior.

Superior to SMB3 is an unfair comparison; it also has a status bar.

For free scrolling without a status bar he horizontal arrangement like this is just the standard method, and lots of games do it. (I was surprised that even the Mega Man series tends to stay horizontal for vertical scroll, even though its mapper could switch.)


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 5:15 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10973
Location: Rio de Janeiro - Brazil
bleubleu wrote:
But compared to most games I play that attempt to do this kind of thing (SMB3 being a good example), I say this algorithm is far superior.

I don't know... a glitch is a glitch, regardless of the edge of the screen where it manifests itself. If I had to pick an axis for scrolling glitches, I too would go with vertical mirroring and try to hide the glitches at the top and bottom of the screen. However, if my own CRT TVs are any indication, I definitely wouldn't succeed in hiding them. But still, in a game that primarily scrolls horizontally, that seems like the most sensible choice.

With the MMC3 at my disposal, I wouldn't think twice about using IRQs to mask the top and bottom 8 scanlines by disabling background rendering and using blank patterns for sprites, or vice versa.

EDIT: Just wanted to make it clear hat I'm not trying to be a dick or anything, I'm just pointing out that hiding stuff in the overscan unfortunately doesn't work as consistently/reliably (or at all, in PAL) as we'd like. You're doing something really cool, keep it up.


Last edited by tokumaru on Thu Aug 30, 2018 12:53 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 6:33 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2047
Location: Fukuoka, Japan
A lot of interesting things for the tools. Good work!

Wanted to do something similar (maybe not that advanced) a long time ago but time dried out. Will be interesting to see the final result.


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 4:53 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2333
Location: DIGDUG
Quote:
I too would go with vertical mirroring and try to hide the glitches at the top and bottom of the screen. However, if my own CRT TVs are any indication, I definitely wouldn't succeed in hiding them. But still, in a game that primarily scrolls horizontally, that seems like the most sensible choice.


I concur.

4 way scrolling on standard 2 screen PPU, I would use vertical mirroring and have tile changes at the top / bottom visible. The opposite of SMB3.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 41 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group