Self publish or Not?

[theloon]

I have a chance to make an RPG for the 2600. If I restrict it to 32k then I can let someone else deal with publishing. If I self publish I can buy 256k ROM carts and really go big with level data, music, hi res screens etc.. However, I have no experience publishing. Doesn't seem like the fun part of releasing a game.

 

Do I pare down my game design until it fits into 32k or go big and deal with packaging, manuals, order processing, etc..

[Cyrano Jones]

I have a chance to make an RPG for the 2600. If I restrict it to 32k then I can let someone else deal with publishing. If I self publish I can buy 256k ROM carts and really go big with level data, music, hi res screens etc.. However, I have no experience publishing. Doesn't seem like the fun part of releasing a game.

 

Do I pare down my game design until it fits into 32k or go big and deal with packaging, manuals, order processing, etc..

 

 

My advice would be to make the game first. Make it how you want it. Don't compromise on anything until you have to, and have fun with the game making part. And once it's done - then you can make these decisions much more easily.

[theloon]

Thanks for the advice. I might divide the game into sections that work in 32k. I could always expand to the full 256k in a deluxe version. Perhaps fumbling around funding through a round with kickstarter for that one.

[Stephen Moss]

To self publish or not depends on several things...

a ) By self publishing you maintain control over cost and quality.

b ) Providing that the quality of the manuals & service a third party would provide is at least equal to that you could provide yourself would you consider what (if anything) they would charge for publishing for you to be value for money considering the time and effort it would save you

 

Perhaps you could arrange a hybrid system where you produce the 256K carts and the third party to does the rest?

 

[LinkoVitch]

I'd second what CJ said. In the process of working on your game you may find it ends up smaller than you planned for one thing, or you may discover some techniques to reduce the storage footprint. Make the best you can, you can then edit it as required.

 

I am sure once you are at the point of nearing completing and have a good understanding of what you actually have you will be able to find someone to help with the publishing of it.

[theloon]

Thanks for the advice! I'm in awe of all the programmers who also have working knowledge of publishing.

 

Specs definitely change. I'm starting to design the game around Rogue-like features. Which means a re-think about how the banks are laid out. I can also lean more heavily on procedural features instead of ROM.

 

[LinkoVitch]

If you are procedurally generating environments, then you could probably store pre-defined set of 'locations' in ROM easily by just storing the seed value for your RNG used for generating the environments...

[theloon]

Totally! Here is the layout for the password system. The player must enter an 8 character password with 64 possible symbols - A-Z a-z 0-9 and !? Basically, the net result is 6 8-bit variables worth of info.

 

Level (0-31)

Percentage to next Level in eighths (0-7)

Current Dungeon Floor (0-255)

Armor (0-15)

Weapon (0-15)

Potion (0-15)

Ring (0-15)

World Seed (0-255)

Checksum (0-63)

Game Event (0-3)

 

With each cartridge a password will be given out that has a unique seed value. Every owner of the game will have their own unique dungeon to delve! Er, until 256 of them are out there

[LinkoVitch]

Perhaps you could start a RNG at the start of the game, and let it run until the player starts the game, use whatever value it has as the seed for the procedural content? That way you are adding a small amount of entropy to the mix (based on how long they wait until they start the game) ? Or perhaps have that prefill the values and give them the option to randomize or enter their own level code?

 

Cunning way of implementing a save system and randomizer though squire