Sonic and Sega Retro Message Board: How to Build a 2D Sonic Engine - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

How to Build a 2D Sonic Engine Starting my own side project

#1 User is offline lotzi 

Posted 29 September 2017 - 09:08 AM

  • Posts: 5
  • Joined: 24-September 17
  • Gender:Male
Hi All,

I'm looking to start a project where I build my own 2D Sonic engine from scratch. It's been a while since I worked on a video game, but I want to have something I can work on in my spare time. Before anyone comments on difficult a project like this is, I have 4+ years coding in C# and have worked on video game projects both in school (classes where I've made a game) and my spare time. With that out of the way, I would like to ask a few questions on how to get started:

1.) What game developing software (Unity, Unreal, etc.) would everyone recommend to write the engine in C#?

2.) If I were to write the engine in C++, what software should I use then?

3.) What would everyone recommend the first thing I should work on? I was thinking of getting Sonic to stand on land first.

All advice is greatly appreciated. Thank you for your time.

#2 User is offline Amnimator 

Posted 29 September 2017 - 10:30 AM

  • Posts: 222
  • Joined: 15-April 13
  • Gender:Male
1. What you're asking can pretty much be done on any remotely modern game engine, and if not it's usually possible to do your own custom implementations of what's missing.

2. Unity is more or less C# only now, UE4 is predominantly C++.

3. Usually collision and slope detection should be the first part of the main ground work.

Sorry if this borders on a non-answer, but that's more or less how things go. Learn more about the tools you want to use, or even make your own when needed. Wish you luck, and as minimal headaches as possible :V
This post has been edited by Amnimator: 29 September 2017 - 10:34 AM

#3 User is online Covarr 

Posted 29 September 2017 - 10:32 AM

  • Sentient Cash Register
  • Posts: 4135
  • Joined: 05-February 07
  • Gender:Male
  • Location:The desert of nowhere, USA
  • Wiki edits:1
Unity is probably the easiest to get started with, and has built-in C# support, but I've heard a lot of people get frustrated with it as their projects get bigger. In particular, people seem to run into performance problems.

Unreal can use C# with some work. It doesn't have any included support, but it can be added using MonoUE, which requires building the engine from source, which requires linking your Unreal and Github accounts... the whole thing is kind of a mess and I don't think it's worth the effort. You'd be better off using Unreal with C++, or with its Blueprints visual scripting system.

#4 User is offline winterhell 

Posted 29 September 2017 - 12:17 PM

  • Posts: 1138
  • Joined: 16-October 10
  • Gender:Male
For C# there are XNA/MonoGame and OpenTK. Very good, you can do absolutely anything with any of those 3. Runs on every platform: Windows, Linux, OS X, Android, iOS, Xbox One, PS4, Switch.
The software, there is no question, Visual Studio Community Edition. Its free of charge, everybody uses it, everybody loves it. You can even use it for commercial products, they wont ask you for a penny.

I personally stray away from engines like Unity, Unreal etc. Too slow, too limited, one week it works, you update to the new patch, your code is now broken. Your experience might be different.
This post has been edited by winterhell: 29 September 2017 - 12:18 PM

#5 User is offline lotzi 

Posted 29 September 2017 - 05:31 PM

  • Posts: 5
  • Joined: 24-September 17
  • Gender:Male

View PostAmnimator, on 29 September 2017 - 10:30 AM, said:

Wish you luck, and as minimal headaches as possible :V


Thanks. I'll probably develop migraines lol.

View PostCovarr, on 29 September 2017 - 10:32 AM, said:

Unity is probably the easiest to get started with, and has built-in C# support, but I've heard a lot of people get frustrated with it as their projects get bigger. In particular, people seem to run into performance problems.

Unreal can use C# with some work. It doesn't have any included support, but it can be added using MonoUE, which requires building the engine from source, which requires linking your Unreal and Github accounts... the whole thing is kind of a mess and I don't think it's worth the effort. You'd be better off using Unreal with C++, or with its Blueprints visual scripting system.


The majority of my classes had us made our games with Unity and it was terrible. I want to try making the engine in C# first since I know it better than C++, but I'll keep it and UE4 in mind if I want to try another approach. Thank you.

View Postwinterhell, on 29 September 2017 - 12:17 PM, said:

For C# there are XNA/MonoGame and OpenTK. Very good, you can do absolutely anything with any of those 3. Runs on every platform: Windows, Linux, OS X, Android, iOS, Xbox One, PS4, Switch.
The software, there is no question, Visual Studio Community Edition. Its free of charge, everybody uses it, everybody loves it. You can even use it for commercial products, they wont ask you for a penny.

I personally stray away from engines like Unity, Unreal etc. Too slow, too limited, one week it works, you update to the new patch, your code is now broken. Your experience might be different.


I thought XNA wasn't used that much anymore. I'll have to look at all three then. Thanks for the tip!!!

#6 User is offline winterhell 

Posted 29 September 2017 - 05:40 PM

  • Posts: 1138
  • Joined: 16-October 10
  • Gender:Male
Just like how DirectX 9.0c is from 2004, games keep coming out using it, even AAA ones. Nothing wrong with that. XNA is very similar in terms of capabilities, even has some DirectX 10 features.
This post has been edited by winterhell: 29 September 2017 - 05:41 PM

#7 User is offline lotzi 

Posted 30 September 2017 - 11:03 AM

  • Posts: 5
  • Joined: 24-September 17
  • Gender:Male
Thanks to everyone for their advice.

After looking through everyone's suggestions, I've decided that I want to build my Sonic engine using the Unreal Engine 4. I picked UE4 for a couple of reasons.

1.) I went into this project mainly wanting to get myself to learn C++, so this was an easy decision since UE4 is mainly in C++.

2.) I've worked with XNA before, and even though I don't hate it like I do with Unity I'm not that impressed by it.

#8 User is offline Billy 

Posted 30 September 2017 - 11:58 AM

  • RIP Oderus Urungus
  • Posts: 1798
  • Joined: 24-June 05
  • Gender:Male
  • Location:Colorado, USA
  • Project:retrooftheweek.net - Give it a visit and tell me what you think!
  • Wiki edits:15
While we're talking about creating Sonic engines, has anyone ever tried their hand at replicating Sonic physics in a modern 2D physics engine, like Box2D? Is such a thing even possible?

#9 User is offline Cooljerk 

Posted 30 September 2017 - 12:11 PM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View PostBilly, on 30 September 2017 - 11:58 AM, said:

While we're talking about creating Sonic engines, has anyone ever tried their hand at replicating Sonic physics in a modern 2D physics engine, like Box2D? Is such a thing even possible?


See, there is really a trick to the whole Sonic physics stuff - determining your resultant velocity is normal physics type stuff involving sin, cosine, and tangent, and that's really easy to do with any sort of physics engine (really, it's just math, you don't need an actual physics engine to accomplish that). However, the stuff about running along walls and things of that sort? It's a lot simpler than it appears and is sort of a visual trick - the game uses invisible collision tiles which sonic hugs as he runs forward. Each invisible collision tile is stored twice - once normally, and once rotated 90 degrees. When the game detects that you're running fast enough, you'll stick to ground tiles, and if your resultant angle goes great enough, the physics model switches, so that gravity is turned 90 degrees. When you're running along walls, you're really just hugging the outline of the collision tile rotated 90 degrees.

So, sure, you could use Box2D or any other physics engine, but it wouldn't feel right unless you made specific tweaks to allow sonic to stick to walls, which would sort of defeat the point of using an accurate physics model in the first place. Because Sonic's physics aren't realistic. That's why you can do crazy stuff like run along ceilings then hit a curve and continue running upward - no correct, accurate-to-real-life physics model works that way.

#10 User is offline lotzi 

Posted 30 September 2017 - 04:08 PM

  • Posts: 5
  • Joined: 24-September 17
  • Gender:Male
That's really helpful to know. Thanks for the info!!!

I got another question.

If I were to build my own engine from scratch (Not using UE4 or Unity), what would I need to learn how to do?
This post has been edited by lotzi: 30 September 2017 - 04:10 PM

#11 User is offline winterhell 

Posted 30 September 2017 - 05:29 PM

  • Posts: 1138
  • Joined: 16-October 10
  • Gender:Male
Already responded to that question in the other topic.

#12 User is offline lotzi 

Posted 30 September 2017 - 05:48 PM

  • Posts: 5
  • Joined: 24-September 17
  • Gender:Male
Fair enough. Looks like I'm making pong lol

#13 User is offline Cooljerk 

Posted 01 October 2017 - 01:56 PM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View Postlotzi, on 30 September 2017 - 04:08 PM, said:

If I were to build my own engine from scratch (Not using UE4 or Unity), what would I need to learn how to do?


That's an enormous question, and not one that any single person can answer, because there are a multitude of ways to do things. To try and tackle this question, first let's ask, what is an engine? Many people conflate an engine with a renderer, but in my opinion an engine should:

A) Provide a method of memory management/object creation

B) Provide a rendering context

C) Offer some type of external, run-time scripting

D) Interface between unique data sets/byte codes

There is no singular right or wrong way to accomplish any of the above, and the approaches you will take will influence what you need to know. Sonic games are not easy to tackle, they are actually among the more complex 2D games out there, and game development is already one of the more complex types of computer programming tasks. For example, the average non-game developer might never have to think about memory management or object pooling beyond a superficial understanding that objects exist, where as I'd say designing a memory manager is one of the biggest tasks in game development.

I like to post this image, because it was created organically as I was creating my own engine when someone asked me to explain to them in person what I was doing at that particular moment. This is a "simple" renderer:

Posted Image

Not an engine, not even the memory manager, not even the rendering context itself, just the actual renderer. The above, at the time, drew this:

Posted Image

This isn't to discourage you, just to make sure you understand that "creating a sonic engine" is a lot of work. You should honestly go for it, but be prepared to stumble quite a bit.

Some general things you should probably learn, to get you started:

-Boolean Algebra
-Trigonometry
-Binary
-m68k microprocessor assembly
-singleton design patterns
-SDL, openGL, or DirectX
-LUA

Best of luck!

#14 User is offline HedgeHayes 

Posted 01 October 2017 - 03:18 PM

  • Chaos Emeralds, Alola form
  • Posts: 324
  • Joined: 01-June 17
  • Gender:Male
  • Location:Bilbao, Spain
  • Project:Too many of them
I was thinking about creating a topic like "fan game development 101" or something like that, but seems it's already happening. I want to learn and do that, but truth is no one taught me how to make anything game or even graphics related when I studied programming, so I have no idea of where to start. The extra problem is I wanted to do a "retro technology" engine, that is, try to do things like in the 90s for the base engine without touching any more modern technology at all, but it's hard to find documentation for that these days or the appropiate tools to do so. How does anyone learn about it? Specialised careers for video game development have only recently started appearing around here, and they are quite expensive, plus there wasn't such things twenty-five years ago, yet they made videogames.

Well, I can add a lot of things to explain the above further, but I don't want to write a text wall, so I'll just say I know I'm capable of programming a Sonic engine as long as I get the right directions to learn on how to do that, so your listing is helpful but, if I could abuse of your knowledge a bit more, I'd want to know if there's some available text out there to get (correctly) initiated in the process of learning how to make old fashioned games. Once I can get my own pixels on screen and a way to handle frames, I think I can do the rest by myself (well, I need the sound too, but I can add it later).

#15 User is offline Cooljerk 

Posted 01 October 2017 - 04:08 PM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View PostHedgeHayes, on 01 October 2017 - 03:18 PM, said:

I was thinking about creating a topic like "fan game development 101" or something like that, but seems it's already happening. I want to learn and do that, but truth is no one taught me how to make anything game or even graphics related when I studied programming, so I have no idea of where to start. The extra problem is I wanted to do a "retro technology" engine, that is, try to do things like in the 90s for the base engine without touching any more modern technology at all, but it's hard to find documentation for that these days or the appropiate tools to do so. How does anyone learn about it? Specialised careers for video game development have only recently started appearing around here, and they are quite expensive, plus there wasn't such things twenty-five years ago, yet they made videogames.

Well, I can add a lot of things to explain the above further, but I don't want to write a text wall, so I'll just say I know I'm capable of programming a Sonic engine as long as I get the right directions to learn on how to do that, so your listing is helpful but, if I could abuse of your knowledge a bit more, I'd want to know if there's some available text out there to get (correctly) initiated in the process of learning how to make old fashioned games. Once I can get my own pixels on screen and a way to handle frames, I think I can do the rest by myself (well, I need the sound too, but I can add it later).


Well, firstly, computer graphic hardware today does not work like computer graphics hardware did in the 80's and 90's. Much of the hardware tricks and programming techniques were products of their time, ways to get around the limited amount of power these types of machines have. Even ignoring the whole shift from 2D to 3D hardware, today's video cards are entirely different beasts from the fixed function days of even 10 years ago. This is a blessing and a curse - today's GPU is more akin to a tiny, parallelized computer running within your computer than just a method of getting pixels and colors onto the screen. Anachronistically, this makes communicating with your GPU similar in some regards to the way you'd talk to, say, a PPU on the SNES or Copper on the Amiga. Even cooler, the pipeline is fully programmable these days, so there is nothing stopping you from programming your GPU to behave like an old piece of hardware... it's just not very easy to do, particularly when you're just starting.

If you want to make a game that behaves like old hardware, you're going to either need to write a software renderer, or gain an understanding of modern GPUs well enough to program them to behave like old hardware. Both of these approaches are very difficult and time consuming. They are not tasks absolute beginners should really tackle, but if you're really confident and wish to try, I can suggest a few resources, and maybe lay out the path I myself underwent.

I should note, I had an actual mentor from NASA in 1999 which I used to hang out with, who would sit me down on weekends and teach me things. We began by creating Asteroids, then Breakout, and then moved onto recreating Ultima I-V using SDL:

Posted Image Posted Image Posted Image

I'd say the first step for anybody looking to get into game development would be to play around with a library like SDL to get a handle on graphics. SDL is an amazing library that works well in conjunction with OpenGL (think of OpenGL like Direct3D, while SDL is DirectX -- it handles everything else). Today, there are some really good sources out there for learning SDL, the absolute best I've found being Lazy Foo: http://lazyfoo.net/tutorials/SDL/

Around the same time I was learning SDL with my mentor, I also began learning m68k microprocessor assembly. I learned mainly from others in this scene, from following rom hacks and save state hacking and all that jazz. Today, there is so much more information on the web that makes this easier. I honestly don't know how anybody could get far learning how to make a "sonic" game without picking up m68k assembly, especially if they want to do everything the "oldschool" way. In the process of learning m68k ASM, you'll also gain a great understanding of how memory works, which is pretty essential to low level computer programming.

Big Evil Corp, who posts on this site and has a genesis game in development, has a really good series of tutorials on Genesis m68k development here: https://bigevilcorpo...etting-started/

Markey Jester, who is a tech member on this site, has been sort of a gold standard for beginning genesis development for years now: http://mrjester.hapisan.com/04_MC68/

Red Hot Sonic had a very old ASM guide that I seem to recall using back in the day: http://info.sonicret..._68000_assembly

Finally, an extremely good source is this series of videos from Photon of Scoopex. Scoopex is a historical amiga demoscene group, and photon is their long time lead programmer. Amiga programming is different than megadrive programming, but this series of tutorials still will give a great understanding of m68k asm: https://www.youtube....h?v=p83QUZ1-P10

An invaluable reference would also be the motorola 68000 reference manual: https://www.nxp.com/...l/M68000PRM.pdf

And it's probably also a good idea to understand the address map of the Genesis itself: https://en.wikibooks...sis_Programming

As for development patterns, like learning the singleton development pattern or how to build a memory pool, these are subjects you'd likely tackle eventually in college in a datatypes course. However, to get a good head start on that, this is a terrific book from an EA developer on the subject: http://gameprogrammingpatterns.com/

You'll also want a good foundation for games math. Most game development math will fall under trig, algebra, and basic calculus. I found picking up calculus extremely difficult over the course of my life, and I'm still constantly learning, but this book was a tremendous help for me: https://www.amazon.c...y/dp/1556229119

Sonic Retro actually itself hosts a pretty terrific physics guide here: http://info.sonicret...c_Physics_Guide

And lastly, to toot my own horn, I have a tutorial (that I've admittedly neglected... need to edit and upload the most recent chapters I've written) that intends to walk people through basic game development for retro consoles here: http://forums.sonicr...showtopic=35955

You can also pop into the Sonic Retro or SSRG IRC channels. They are on irc.badnik.org at #retro and #ssrg respectively. There are always people online who are willing to help (provided you have done the ground work first and aren't just popping in to ask a general question like "how do I program").

Long story short, man, most of this knowledge comes from reading, experimentation, and internalizing it all. There's really no shortcut or single guide to it all. As I said before, game development, and especially Sonic game development, isn't a beginners subject. But hopefully this is all a good starting point for people.

EDIT: Oh yeah, I forgot to post the bible: Michael Abrash's Graphics Programming Black book, with foreward by John Carmack

Much of this book is outdated if applied literally, but it's THE place to start if you want to understand graphics programming. It's a very heady read, though.
This post has been edited by Cooljerk: 01 October 2017 - 04:15 PM

  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users