It is currently Tue Nov 13, 2018 6:04 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Oct 16, 2018 1:36 pm 
Offline

Joined: Tue Aug 28, 2018 8:54 am
Posts: 58
Location: Edmonton, Canada
I have an idea of the mechanic, and trying to find an approach to prototype it without spending month of developing tooling and engine just to realize it does not work. I am aware of the idea of Miminum Viable Product, but not sure how to approach it for NES.

My issue is that NES being limited hardware, and having limited software support. I can't really write bad and fast code, because don't have enough CPU, neither I can use sorting and big amount of variables for sates and collisions because I don't have enough RAM.

I want to have top-view game with 4-way scroll that I can theoretically put on cart. With structure of something like that
Code:
    _
 __| |_
|      |
 --|___|


And I already have an issue of how should I store the data, and automatically load background and metadata. Cheap and fast way is just to have NxM arrays of background tiles, collision tiles, enemies etc, but it will obviously won't fit.

So now I start thinking about the of:
1. Storing maps (uncompressed nametables with ID, global x and global Y, because I didn't came up with a way to uncomress lines/columns without unpacking whole kilobyte of data into the ram)
2. Creating maps, as generic NES tools (like NESST) only cover 1 screen (probably just by hand, because trying to adapt "Tiled" editor to convert to what I need, will be even harder)
3. Storing collisions (probably parallel arrays of sorted x,y,type objects)

And all of this looks like a lot of work for a prototype (not saying as it shouldn't, as I am trying to develop for NES, and NES is not modern engine created to be easy).

My question is not about specific approach (although any hints/links would be appreciated), but more about how can one start developing the game and not burn out before seeing anything viable? What could or should be stripped off technically or nor in order to be able to progress?


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 3:39 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2329
Location: DIGDUG
Quote:
how can one start developing the game and not burn out before seeing anything viable?


Technical issues, like "how to compress all way scrolling" will slow you down.

Maybe you need to simplify or rethink the project.

Many of the people who have been doing this for a long time limit their games to single screen at a time (zelda and mad wizard and every NESmaker game), or 2 screens at a time (most mojon twins games).

By adding this limit, you can focus on gameplay and game design.

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


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 4:27 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10960
Location: Rio de Janeiro - Brazil
If you want quick prototyping, better use the PC rather than the NES, and convert the engine to the NES once it's working the way you want.


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 5:33 pm 
Offline

Joined: Tue Aug 28, 2018 8:54 am
Posts: 58
Location: Edmonton, Canada
dougeff wrote:
Technical issues, like "how to compress all way scrolling" will slow you down.

Maybe you need to simplify or rethink the project.

Many of the people who have been doing this for a long time limit their games to single screen at a time (zelda and mad wizard and every NESmaker game), or 2 screens at a time (most mojon twins games).

By adding this limit, you can focus on gameplay and game design.


I discarded compression+scrolling completely due to complexity. I just wanted to show my string of thoughts. You are probably right, my fantasy things big, my brain asks me to stop. I just finished the simple pong and more or less familiar with the system, and now I want to create the game of my dreams :) (probably not a good idea)

tokumaru wrote:
If you want quick prototyping, better use the PC rather than the NES, and convert the engine to the NES once it's working the way you want.


I thought about that. But thinking about it again (thank you for triggering this), if I create simple graphics library that imposes some major limitations of the NES, like nametables, sprites, flickering; or at least limit myself to the NES limitations I should be able to develop the prototype that can be convertable to the NES.


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 7:01 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2763
yaros wrote:
I have an idea of the mechanic, and trying to find an approach to prototype it without spending month of developing tooling and engine just to realize it does not work. I am aware of the idea of Miminum Viable Product, but not sure how to approach it for NES.

My issue is that NES being limited hardware, and having limited software support. I can't really write bad and fast code, because don't have enough CPU, neither I can use sorting and big amount of variables for sates and collisions because I don't have enough RAM.

I want to have top-view game with 4-way scroll that I can theoretically put on cart. With structure of something like that
Code:
    _
 __| |_
|      |
 --|___|


And I already have an issue of how should I store the data, and automatically load background and metadata. Cheap and fast way is just to have NxM arrays of background tiles, collision tiles, enemies etc, but it will obviously won't fit.

So now I start thinking about the of:
1. Storing maps (uncompressed nametables with ID, global x and global Y, because I didn't came up with a way to uncomress lines/columns without unpacking whole kilobyte of data into the ram)
2. Creating maps, as generic NES tools (like NESST) only cover 1 screen (probably just by hand, because trying to adapt "Tiled" editor to convert to what I need, will be even harder)
3. Storing collisions (probably parallel arrays of sorted x,y,type objects)

And all of this looks like a lot of work for a prototype (not saying as it shouldn't, as I am trying to develop for NES, and NES is not modern engine created to be easy).

My question is not about specific approach (although any hints/links would be appreciated), but more about how can one start developing the game and not burn out before seeing anything viable? What could or should be stripped off technically or nor in order to be able to progress?


Have you heard about meta-tiles? Most NES design levels with 16x16 blocks, and convert them to 8x8 tiles during scrolling.


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 7:12 pm 
Offline

Joined: Tue Aug 28, 2018 8:54 am
Posts: 58
Location: Edmonton, Canada
psycopathicteen wrote:
Have you heard about meta-tiles? Most NES design levels with 16x16 blocks, and convert them to 8x8 tiles during scrolling.


Of course! But it does not cut out amount of work that is required to be put into, to have something working. If I wanted to use engine, I would probably just take Godot.

I want to develop something complex, but I need to start from ground up, and I am afraid to burn out in between. Hearing from someone to forget about scrolling or limit scroll to two screens is probably good advise, as it was something I was worrying about.


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 7:46 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 416
Scrolling is tricky but it doesn't take very long to implement.

The longer slog is implementing all of the items, levels, enemies, and abilities. That's the type of thing you'll burn out on.


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 7:56 pm 
Offline
User avatar

Joined: Wed Sep 07, 2005 9:55 am
Posts: 334
Location: Phoenix, AZ
pubby wrote:
The longer slog is implementing all of the items, levels, enemies, and abilities. That's the type of thing you'll burn out on.


This. I finished the core of my Zelda-like game years ago, but always get burnt out creating content. I also like building engines, so I've started a few other projects and bounce around a lot.

_________________
. That's just like, your opinion, man .


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 8:02 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2035
Location: Fukuoka, Japan
It is possible to work on a huge project from the get go but chances are the motivation will dry once the grunt work comes and complication arises.

Better to start with smaller projects, which will allow to build your experience. Compared to bigger one, it will be easier to manage and code can be re-used too in your next one.


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 8:37 pm 
Offline

Joined: Fri Sep 30, 2016 8:57 pm
Posts: 92
no matter what you do, it's going to take a while to get up and running.

what i did, was actually developed a level editor for my game before doing anything on the NES. that taught me the technical limitations of the graphics, which is going to factor into how you choose to compress your level data. design your level editor to spit out a bunch of hex data, and then your NES code is simply de-compressing the data and pushing it where it belongs, byte by byte.

it also makes level building much much more fun, which as others have mentioned, it can be a drag without the right tools.

my first project is a pretty full-scale game, but it's taken a year and half so far, with another 6 months to go.


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 8:57 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 490
Location: Central Illinois, USA
I think it's important to spend a good amount of time near the beginning thinking about what you really want to do, and what's required to get there. Is 4-directional scrolling important to your dream project? How big of a game does this thing have to be? Do some back-of-the-envelope math to see what sort of compression might or might not be necessary. Do the simplest thing necessary to build the thing you want. Don't devise the world's best banking scheme, or level compression, or vram updater. Only make it as complex as you need to.

If you sacrifice too much, you'll be disappointed, and will lose interest. If you go too big, you'll get stuck and get discouraged. Find that minimum thing that still lets you make the game you're dreaming of.

pubby wrote:
The longer slog is implementing all of the items, levels, enemies, and abilities. That's the type of thing you'll burn out on.


I like to mix it up. Leave a few interesting features unimplemented if you can afford to. Work on content when you're not in the mood to work on new features. Work on features when you're sick of adding content.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 10:18 pm 
Offline

Joined: Tue Aug 28, 2018 8:54 am
Posts: 58
Location: Edmonton, Canada
never-obsolete wrote:
This. I finished the core of my Zelda-like game years ago, but always get burnt out creating content. I also like building engines, so I've started a few other projects and bounce around a lot.


I can relate. It easier for me to program, that fill the content. But my ultimate goal is to have a viable demo at least. I know my limits.

Banshaku wrote:
It is possible to work on a huge project from the get go but chances are the motivation will dry once the grunt work comes and complication arises.

Better to start with smaller projects, which will allow to build your experience. Compared to bigger one, it will be easier to manage and code can be re-used too in your next one.


It is fair. But as of now I have one idea I can work on. Otherwise making something I don't relate will shrink my motivation even more. I have a big respect for you, for working on your project for 10-ish years, if I remember correctly.

gauauu wrote:
I think it's important to spend a good amount of time near the beginning thinking about what you really want to do, and what's required to get there. Is 4-directional scrolling important to your dream project? How big of a game does this thing have to be? Do some back-of-the-envelope math to see what sort of compression might or might not be necessary. Do the simplest thing necessary to build the thing you want. Don't devise the world's best banking scheme, or level compression, or vram updater. Only make it as complex as you need to.

If you sacrifice too much, you'll be disappointed, and will lose interest. If you go too big, you'll get stuck and get discouraged. Find that minimum thing that still lets you make the game you're dreaming of.


Thank you, this is a really good advice. I appreciate it.


Top
 Profile  
 
PostPosted: Tue Oct 16, 2018 10:44 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2035
Location: Fukuoka, Japan
There is a good part that I had to stop so "working" is quite a loose term in that case even though I had the project all the time in the back of my head but now I can put a little bit of time on it, which is refreshing. At that pace, I will match the same schedule as duke nukem forever :lol:

As for little projects, it can be interpreted in many ways. For example, if you scope is quite big, trying to build everything in one shot is quite hard. In assembler, one bug sometime can make thing fails many places (especially when you refactor the names and now everything goes south by accident ^^;;) and hunting it on a huge scale is hard. For your situation, the little projects would be "units" that can be used in your goal projects, code that can be reused with ease. Those units could be the 4 way scrolling, handling meta-sprites format, compression of data, handling of music and sfx, AI, intro/cut scene management, fx with raster etc.

By separating in smaller units/projects with test assets, it will be easier to manage and you will have re-usable code for later. And isolating the feature will make it easier to debug, which is a plus.


Top
 Profile  
 
PostPosted: Wed Oct 17, 2018 1:20 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 621
Two ways

1. Use something more powerful, a SNES for example, you will be able to keep 6502 code, the tile format is the same, just its extra RAM, banks, CPU speed mean you can write the most crap code it will give you about NES performance. Then you can optimise and compress the data down as needed to get it to a NES. Or say screw it and release it as a SNES title.

2.) Hack the emulator, seems the NES and its PPU don't really have a very tight relationship, so get an emulator and make it execute 2,3 instructions per the normal 1. Just throw more RAM into the address space, and give yourself a 512K cart.


Top
 Profile  
 
PostPosted: Wed Oct 17, 2018 6:10 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10960
Location: Rio de Janeiro - Brazil
Maybe use one of the emulators with Lua scripting (FCEUX, Mesen) and write most of the game in Lua? I don't know if you can manipulate the memory-mapped registers directly from Lua or how that works in regards to timing, but even if you have a ROM with just a vblank handler to dump buffers to the PPU, the rest of the logic could all be Lua.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Dwedit and 2 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