To make an engine, you need a level, not Lorem ipsum

You can talk about almost anything that you want to on this board.

Moderator: Moderators

Post Reply
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

To make an engine, you need a level, not Lorem ipsum

Post by tepples »

Some people claim that the thing holding back homebrew on Super NES is lack of pre-made generic game engines. It's more complicated than that.

Many web designers prototype their designs with "Lorem ipsum", a passage from On the Ends of Goods and Evils by M. T. Cicero, adding actual articles later. I'm guilty of this as well; I used a translation of this passage when I was building my NES VWF engine and when refining another pixel font.

But in "Lorem Ipsum is Killing Your Designs", Kyle Fiedler explains why this isn't the best approach. It ends up with a design that's optimized for a Cicero excerpt rather than for the information you wish to present. Instead, he recommends starting with a rough draft of an actual article as you begin design. Joshua Johnson agrees in "The Importance of Copywriting in Web Design", as does Jason Fried in "'Getting Real' design tip: Just say no to Lorem Ipsum".

In the case of a game engine, this means having the map of an original level and original sprite cels in place before programming begins, even if only for the purposes of designing a binary representation of level maps. To avoid the chicken-and-egg problem of making a level map without knowing the constraints on the map format, have a pixel artist produce a rough draft without technical constraints at first (other than the 8x8-pixel tile grid) by making the playfield layer and parallax layers as PNG images. Then derive appropriate technical constraints on the engine from that. This worked well for Haunted: Halloween '85, whose first deliverable was a viewer for the draft of the school level. When the draft level had more than 256 distinct tiles, I came up with a way to shuffle tiles around in CHR RAM at runtime.

Not only does this produce an engine more tailored to the intended use, but it also avoids placeholders slipping into production. This is why you need to test with original artwork from day one, so that Nintendo has no grounds to sue you into financial ruin should some artwork from Super Mario World accidentally end up in the published game.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: To make an engine, you need a level, not Lorem ipsum

Post by FrankenGraphics »

The placeholders slipping into production link had me laughing hard. :lol:

Someone should start a museum. One exhibition for placeholders, and another for google translate cheats gone bad.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: To make an engine, you need a level, not Lorem ipsum

Post by FrankenGraphics »

Back on topic... the first thing i do in a cooperation is draw a mockup screen. They tend to get over-crowded, but serve as a good basis for discussion on what the engine should/could do. Now that NESST supports nametables of arbitrary sizes, it'd be easier to quickly whip up a full-fledged level mockup without the need for a game-specific level editor, and take it from there -should we use metatiles, metatiles of metatiles, free-form structures, draw-order layers, world drawing algorithms? etc etc.

The project that has moved the 'fastest' was when i was presented a functional engine to do graphics for, but that's because i got involved at a late point which hides any/a lot of work done priorly from my sight.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: To make an engine, you need a level, not Lorem ipsum

Post by Oziphantom »

Its a Captain Ahab problem. You can't make a generic engine, you can argue something like Unity is one, but lets be honest, its not, it just gets twisted and abused into one because machines have more power than is needed for the actual game concept to run, well mostly.. a SNES while coming from a NES will be drowning in resources its not really. So if you go down some OCD fuelled quest to make the most perfect engine for all things.. you will never find the whale, and when you think you have there will be something else.. No one engine will support Yoshi's Island, SFII and Chrono Trigger, and if it did the OCD will kick in again on how it runs in 5 frames and wastes cycles left right and centre.

A better approach is to make a bunch of frameworks that do A thing. So again sorry for my C64 based views on terms but it what I know best.
So having a GoatTracker for the SPC 700 is a nice thing, plays music and SFX self contained and has a nice tool that you can give to a musician and it "just workstm"
while these are things we have on a C64 you don't need on a SNES but they set the idea.
Krill loader - this is a custom build loader that you set a configuration for and it spits out a loader code to supports what you need, and works on a variety of devices with some nice fall-backs and its as fast as it gets. So you need to load, you just use Krill.
File packer Exomiser, PuCrunch or ByteBoozer depending upon what you need, again just pick it up off the self.
Sprite Multiplexors, there is a 24 sprite, a 16 sprite and a bolt sprite plexor around that you can copy in and modify.
Need streaming, Spindle will get the job done.

For the SNES
Having a arbitrary tile arranging animation system, i.e a "spine" for the SNES, that lets an animator make and animate sprites, and it packs the frames into the smallest amount of sprites and calculates the positions. However it will need to be build with limits in mind, i.e you make one that can handle up to 12 tiles per object or something like that.
Having a bunch of Layer scrolling engines, so you just make code that will scroll a 16 colour Layer 2 plane, and then some that will scroll a 4 colour Layer 3, etc With vertical, Horizontal, 4 way and 8 way versions.

The other issue is you need to make it vanilla, its needs to be the newbie get up and running type easy, it would be nice to make and have a micro-threaded entity system framework(if you have the luxury of a 65816 might as well use it ;) but again dammit Nintendo why no VIA/CIA!!! ), but they are lovely and easy to use, however if you break it or end up needing to debug across it ? Waaaaay post the intermediate level, let alone the beginner.

While you can make an engine, and you can get it such that Metal Warriors and Zombies Ate My Neighbours can both use the same "engine", I'm sure you can't really run either game on the other, and that it just started as the same code but was upgraded and extended as a base.

Don't make an engine, make things that have strict limits and allow people to use and modify as needed. So instead of trying to design a system that has X,Y,Z for some arbitrary product that doesn't exist and there is no data for. Choose some hard limits, make a simple thing that does it, and then use it. Make a tool that does the basic editing and lets them get it on screen. It doesn't have to get people to the finish line it just has to get them off the starting line.
Oh and use something that works native on Windows and build all the guis such they work on Windows, sure you might use Linux but 93% don't ;)

unless you want to make a SNES SEUCK, then sure, pick some hard limits, make a editing tool and voila, hell put in Mouse support and make it directly on the SNES... why didn't they do that back in the day? That would have rocked...
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: To make an engine, you need a level, not Lorem ipsum

Post by tepples »

Oziphantom wrote:A better approach is to make a bunch of frameworks that do A thing.
But you still need practical data with which to test each framework.
Oziphantom wrote:So having a GoatTracker for the SPC 700 is a nice thing, plays music and SFX self contained and has a nice tool that you can give to a musician and it "just workstm"
Such a tool still needs sample songs and sound effects. When I was developing Pently, I had to follow Kyle Fiedler's guidance: "Write your own copy. Seriously, do it." So I composed music to test each effect, and in some cases, I struggled not to make them sound contrived. But one reason why I haven't implemented some effects in Pently is that I haven't had a need for those effects in my own original compositions. I've begun to test S-Pently by porting parts of the soundtrack of Thwaite, and once I get more stuff in, I can adapt the Pently examples as well because S-Pently reuses the pattern and song formats.
Oziphantom wrote:Sprite Multiplexors, there is a 24 sprite, a 16 sprite and a bolt sprite plexor around that you can copy in and modify.
You still need some sprites to multiplex, so that you know your plexor does what games actually need.
Oziphantom wrote:For the SNES
Having a arbitrary tile arranging animation system, i.e a "spine" for the SNES, that lets an animator make and animate sprites, and it packs the frames into the smallest amount of sprites and calculates the positions. However it will need to be build with limits in mind, i.e you make one that can handle up to 12 tiles per object or something like that.
Then you need a bunch of sprite cels with which to test this animation system.
Oziphantom wrote:unless you want to make a SNES SEUCK, then sure, pick some hard limits, make a editing tool and voila, hell put in Mouse support and make it directly on the SNES... why didn't they do that back in the day? That would have rocked...
They did. It was called Dezaemon. There were versions for Famicom and Super Famicom.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: To make an engine, you need a level, not Lorem ipsum

Post by Oziphantom »

Sure you need data, but you only need data for the one thing, and doesn't need to have any meaning. Multiplexors are testing with solid 255 filled sprites or some other pattern if they are multicolour, its the sorting and raster split locations that are important with them. Each one has its own sorting limits, which you document and the let the person choose the one that fits or best fits so they can modify.
Music is the more extreme case in what you need to test, but the idea is you don't aim to just make the framework you make a game and pull out what you used, so at some point you will need music and then you make a music framework that plays the music you need.
However most of the pieces basically have a job and you can test that with anything as it doesn't matter that it puts a hand coloured tile that looks pretty in the right place, it just matters that tile A should be in mem location Y.
The scroller just needs to make sure whatever the random test data is that makes up the test "slivers" gets put into the right part of VRAM.
The map generation system just needs to make sure the random test data it has for "blocks" gets split up into the right slivers when asked.
The world/camera activate system only cares that when the camera is a 100,100 and its at 200,200 with a active area of 50,50 it determines it should activate, and when the camera moves back to 50,50 it should deactivate. Where the camera is 2 words in RAM somewhere.
None of these need to be tested with actual art and the pixel data is neither here nor there, the test will only look at the values in RAM not if it makes a pretty picture.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: To make an engine, you need a level, not Lorem ipsum

Post by FrankenGraphics »

Meaning can absolutely have a positive impact on technical development.

-Oh, so this is a game where you don't control the player character directly, but gives it incentive to act according to AI by manipulating the world around it?
-Oh, so the objects you manipulate will often be off screen relative to the center-on-player position, and you need a good way to toggle between your scope of action and the player character?
-Oh, but switching back and forth is disorienting, where am i?
-Oh, we need a quick-scrolling transition to make the player have a sense of direction, but the breakneck speed required between to extreme ends makes the transition look choppy
-Oh, so we should work on a way to interpolate frames of quick camera movement, got it.

You could add it as the need arises, but with limited resources, planning ahead will give a better balance of distribution. To plan ahead, you might need assets that convey meaning to accurately do so. Not saying it's a definite must, but it could help.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: To make an engine, you need a level, not Lorem ipsum

Post by psycopathicteen »

Can we use the tiles I've already made for my own game?

Here's some clouds I've been working on.
cloud.png
cloud.png (2.1 KiB) Viewed 3632 times
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: To make an engine, you need a level, not Lorem ipsum

Post by psycopathicteen »

Oziphantom wrote: For the SNES
Having a arbitrary tile arranging animation system, i.e a "spine" for the SNES, that lets an animator make and animate sprites, and it packs the frames into the smallest amount of sprites and calculates the positions. However it will need to be build with limits in mind, i.e you make one that can handle up to 12 tiles per object or something like that.
My animation engine will come in handy there because you can have the sprite optimizing tool output to my animation format. I just wish I can hide the messy code from beginners and just tell them "it's magic".
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: To make an engine, you need a level, not Lorem ipsum

Post by Oziphantom »

Do any SNES emulators have a monitor? and if so can you TELNET into it?
Post Reply