Beginner Mistakes

The idea of creating a Sonic ROM hack can be exciting. With the current tools and resources, the sky's (and the hardware's) the limit. However, a number of newcomers come in with some common misconceptions and tend to make the same mistakes when they get started in hacking. This page aims to make sure you are aware of these misconceptions before you get started. A lot of these points can really be applied to game development in general or really any kind of creation process.

The Learning Process

There are newcomers with all kinds of learning backgrounds. Some with experience in programming, most with little or none, and quite a number of them (especially those who are inexperienced) get the impression that they'll come in and be able to tackle learning programming, working within the limitations of the Mega Drive and game engine, and developing a complex and polished project real easily.

The truth is, however, learning to hack Sonic and work with the Mega Drive hardware is no easy feat. Depending on your experience, it's gonna take a bit before you truly get the hang of it. It's important to not get overly confident and ambitious and try to rush your way through it (see the Dunning–Kruger effect). Assuming you're starting from square 1, it's gonna take quite a long time to learn, but don't get discouraged. Even the most skilled hackers out there did not get to where they are in a short period of time. They just stuck to their guns for years and are even still improving their skills to this day. The same will pretty much apply to you.

When it comes to learning to program in the game engine of a Sonic game, a lot of newcomers try to purely rely on using the how-to guides to work with the game code, without looking into what the code is doing. They also tend to ask for code just so they can copy and paste it into their disassembly. As a result, while they're learning to navigate through the disassemblies, they aren't really learning to program in the game engine. If they want to add a feature that doesn't have a guide, they just can't, because they don't know how to.

Learning to program in the game engine requires more than memorizing the Motorola 68000 instruction set, it also requires a "programmer mindset" (see this). Every programming language in general, as different as they can be from each other, pretty much share the same fundamentals of program flow and logic. There are plenty of guides and references out in the wild for learning to program with other languages (and probably with Motorola 68000, too), but the same general logic behind those can still be applied here.

It's also important to learn to work with how the hardware works, too. When working with graphics, you'd wanna look at how sprites and tilemaps are formed and how palettes work, and when working with audio, you'd wanna look at how the sound chips work. This is so that you know what limitations you are working under, so you can apply that to your work.

Overall, just take your time when learning, there is no need to rush it. It's just a hobby after all. Learn to delve into the details and how things work, and you should start getting the hang of it in due time. Don't be afraid to ask for help with the learning process.

The Development Process

Deadlines

Going off on how some newcomers get overly confident, some will even set deadlines on when their hacks will be finished, and they are usually ridiculous deadlines, like being a month from their announcement. Game development in general takes time and effort to get right, and to set a deadline like that, especially if you're on your own and are inexperienced is just setting yourself up for disappointment and stress. Again, it's just a hobby. Nobody is rushing you, nobody is expecting you to release a product in time, and the Sonic Hacking Contest isn't going anywhere. Take all the time you need to make things right.

Ambitions

If you're just starting off, it's important to keep you goals small at first. Don't start trying to do something overly ambitious, the project's more than likely gonna be doomed from the start. As you build your skills, continually work on more complex projects and just work your way up from there. Start off working on a single level with maybe some basic gimmicks thrown in, and later on you may be able to do multiple levels with more complex gimmicks. Become acquainted with the code and tools first. Don't overburden yourself.

Game Design

A lot of newcomers come in with the idea that adding in a bunch of moves and features will help flesh our their hack, when that's typically far from the truth. If the rest of the game doesn't complement the extra stuff you add, then it just doesn't work. Give yourself a reason to add a feature or move and get the game to work with that and make the most of it. Let's have an example level that's basically a straight line. It's obviously not going to be a very fun level and is just boring. Adding something like a homing attack isn't going to fix it at all, because it's still basically a dull straight line zone at it's core. What makes a game fun isn't determined by how many moves the player has or what have you, but rather the world and design around it.

All in all, just adding in random features really has no point unless you make the game work with them.

Teamwork

A good chunk of the inexperienced newcomers will come in looking to recruit a team to make a hack with. However, the main issue with that is mainly due to the fact that the recruiter has no experience with hacking or working with teams (and basically is just looking to be an "ideas guy", looking to put in no further effort). Everyone in a team should be able to contribute a good chunk to the project's development besides coming up with ideas for it and minor tidbits here and there. It's usually just an excuse for the recruiter to get a hack made without doing much of anything, and that's just not fair for the rest of the team.

Not only that, but people are generally weary of joining someone's team if the recruiter has no existing reputation or portfolio. In the real world, if you apply for a job without a proper resume/portfolio, you're not going to get the job, and you probably wouldn't apply for a job you have little knowledge about or if the employer is known to be inexperienced and shady. It's the same logic here.

Beta Testing

Simply put, beta testing should not be used an an excuse to give out/play early access hacks. The purpose of a beta tester is to try to find bugs and other issues in a hack and report them in detail to the developer(s), and not just play it and give a vague opinion. Take a look at this topic on what a proper beta tester should be like.

Dealing With Criticism

It can be very frustrating that something you worked hard on learning to do and learning to create ends up being looked at as something very low effort, but do not get discouraged. The people who are giving you (constructive) criticism point out the flaws for you to keep in mind so that you can develop a better hack in the future and develop your skills even further. They aren't trying to flame you or make you feel bad about yourself. Sure, it's possible that someone may seem harsh with their critiques, but that doesn't mean that whatever points they have are invalid. Constructive criticism is one of the best tools you have for improving in making Sonic hack.