This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

New Game Development / Programmers Wanted

New Game Development / Programmers Wanted
by on (#15309)
My name is kurt and i play in a band called the depreciation guild. I have no experience with programming but i create NES music which is used for our group. We're currently looking to make a sidescroller game that features the 2 members of the band, for possible cartridge release on the NES or as a ROM for emulator use. We know that this is an ambitious project but we're pretty serious about it and want to make it happen. I'm wondering how possible it will be to do this, given the constraints of modern hardware. Also, I have a few questions:

1.) We could handle the sound aspect of the game and we have plenty of friends who are artists, but would we need an artist who knows how to program in 6502 assembler code (if that's what it's called), to make the game art?

2.) Would creating a game involve writing 100% original code or are there development tools available for writing, let's say, a sidescroller game?

3.) Is it possible to even create a game with a team of only a few people?

4.) Obviously, there would be $$$ involved for helping us undertake this project. What would be a reasonable pay for the writing of the game code?

5.) What is a reasonable time frame for a game to be created in?

Email me at gibson781@gmail.com if you're interested. Thanks!!

-Kurt

by on (#15322)
1 - No, artists don't have to know a lot about programming. Just know about how the PPU works, and know the hardware limitation with tiles and color. If you're in a team, artists and programmers should work together to got a great results but the artists doesn't have to know programming, they should just be supported by a programmer that can tell them if what they want to do is possible or not on the hardware.
2 - Yes, you have to write all the game engine in 6502 assembly. Once you have made a whole game, it would be easier to do others as you could reuse your own routines. There isn't anything yet worth using in the NESdev scene.
3 - Of course it is, as long as you made it seriously
4 - We're all homebrew devlopment crews. No money is involved, exept maybe to purchase hardware things to test your code or whatever.
5 - This all depend how much people are involved, how much they are experimented/skilled and how much time they spend on it regulary.

by on (#15368)
I am very interested in this type of thing as well - how can i get started?

by on (#15379)
I'll offer my input also.

1. What Bregalad said. The artist understanding the PPU as well as the programmer does would be ideal.

2. If the game is anything beyond simple, writing development tools would be smart. Something like a level editor would be almost necessary.

3. Certainly. Highly determined people.

4. It's likely to be a lot of work, at any price I'm sure it would come out to be waay below 'minimum wage' anyways. Definitely in hobbyist territory here. :) I would think some kind of profit (and copyright)-sharing would be a reasonable to see it. 50% (or more, easily) would be a start. Depends on what really carries the project, I suppose.

5. I'd estimate between 6 months to 1.5 years. Or forever, if the scope of the game changes enough during development.

I could probably help out with some hardware (loan a devcart or something), since developing with emulators only is a total crapshoot. That offer is for anyone, too.

by on (#15380)
Quote:
I could probably help out with some hardware (loan a devcart or something), since developing with emulators only is a total crapshoot. That offer is for anyone, too.

Well, I've been devlopping my game since more than one year only trough emulators so far. I think this is decent, as long you're aware of most incompatibilities between emulators and hardware, but sure in the hope to see this running on a real card later. Since the game isn't completed, and erase/rewrite EPROMs is a real pain, I prefer wait for the game to be finished to put it on a card.
The most annoying part in game devloppement is design some complicated bounds in game engine. Some stuff in game engine coding is very nice, and some is a real pain, and will not make you want to work harder for your project. I've found no tutorial about game engine writing by the way, all tutorial I can found about creating games are with using a pre-made game engine, wich is a very bad and lazy thing.

About map editors, I've done all my maps on paper first and then with all .db. Mabe not the most optimal way, but it works pretty fine for me since I know in wich format they are stored. I'd have not a single idea how to write an editor with Visual C++ or something...

by on (#15386)
If anyone's interested, I've been working on an NROM sidescroller, and I'm planning to re-use the engine for the sequels to it. This is what I have left to do:

1. Create a sound engine

2. Finish the AI part of it

3. Create physics- Includes collision, jumping, and whatnot.

4. Successfully make code that will go to the next level of the game

5. Make password access


Some bad things about my engine:

1. Can't go back in the level

2. Only 4 enemies may be on the screen at once.

3. Enemies cannot go beyond the right side border of the screen once they have crossed it.

4. Pretty much only $540-$5FF and $700-$7FF are available, because the rest is used for the engine.

5. The game uses objects, and these objects use more space than metatiles they contain.

A couple good things:

1. Levels are 256 bytes long (not including the sprite part), so it allows for many levels.

2. Each enemy has $40 bytes reserved for it's AI commands (Does that make sense?)

3. Space isn't really an issue here.

How does this sound? It's my first NROM sidescroller attempt, so I think it's pretty decent. I haven't finished it yet, but this is what it will be like.

by on (#15388)
Quote:

1. Create a sound engine

2. Finish the AI part of it

3. Create physics- Includes collision, jumping, and whatnot.

4. Successfully make code that will go to the next level of the game

5. Make password access

What did you do then.... err.... ?

By "sidescroller", you mean a game that scrolls independantly of the player, right (like Gradius) or you're just saying it scrolls from a side-view (Megaman) ? Because both can be very different; Graduis is very linear and has no loading times, but Megaman is totally unlinear.
I'm totally highhacking here, but I'm pretty happy to have been sucessfully working on AI of ennemies today !! Additionnally, my engine seems to work with 7 ennemies on-screen at full-speed !!
Now the fun part of my game devloppement can eventually begin !

by on (#15389)
Bregalad wrote:
What did you do then.... err.... ?


I've made a successful scrolling routine that updates attributes, and a routine that updates sprites. My code puts the AI adresses in RAM, and goes to them every Vblank. You know, now that you mention it, it doesn't seem like I've done that much. But I have gotten the most important parts of the game engine out of the way. You may disagree, but I beleive that a good level and sprite engine is the most important part to make the game function. If I made a new engine, there would definitely be things I'd fix, but I think that what I've done is pretty impressive for being my first sidescroller. I'm getting there, I'm over halfway done making my engine. I can't really think about what I've completed, but I do know that I've made alot of progress.

by on (#15391)
Bregalad wrote:
About map editors, I've done all my maps on paper first and then with all .db. Mabe not the most optimal way, but it works pretty fine for me since I know in wich format they are stored. I'd have not a single idea how to write an editor with Visual C++ or something...


i did that for map data up untill i started bit packing to conserve space, and then it became a hassle to change it. thats when i decided to write a quick custom editor. i still use .db's for other kinds of data, as long as its not huge chunks.

by on (#15392)
I make NES ROM level editors that save their data in SRAM, then I copy and paste data from the SAV file into a new binary file, and just incbin that. It's actually quite handy, because I can just use the knowledge I already have to make things easier.

by on (#15400)
Celius : Actually yeah, I've just totally forgot about maps and stuff because I've been a lot of trouble with AI and physics lataly, and those are much more annoying than anything else, as opposed to create maps and mazing routines wich is a quite fun thing. I think phisics really are annoying, but I'm feeling good after most of it is being done.

Actually do a NES ROM map editor can proof to be quite fun, to run an editor to run on the same platform as the game. Also, you just need to know 6502 coding. However, making a windows editor would make more sense, because you can modify it easier to get maps from a different format for another game or something...
And with RAW compression, doing all maps with .db isn't really that much a pain. I just have the low 5 bits tell the metatiles number, and the high 3 bits tell the number of times it repeats, so it is fairly easy to code and it has a great compression ratio.