don't click here

How to Build a 2D Sonic Engine

Discussion in 'Fangaming Discussion' started by lotzi, Sep 29, 2017.

  1. lotzi

    lotzi

    Member
    6
    0
    0
    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. Amnimator

    Amnimator

    Member
    224
    0
    16
    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
     
  3. Covarr

    Covarr

    Sentient Cash Register Member
    4,233
    3
    18
    Trapped in my own thoughts.
    Two stageplays, a screenplay, and an album
    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. winterhell

    winterhell

    Member
    1,165
    7
    18
    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.
     
  5. lotzi

    lotzi

    Member
    6
    0
    0
    Thanks. I'll probably develop migraines lol.

    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.

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

    winterhell

    Member
    1,165
    7
    18
    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.
     
  7. lotzi

    lotzi

    Member
    6
    0
    0
    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. Billy

    Billy

    RIP Oderus Urungus Member
    2,118
    178
    43
    Colorado, USA
    Indie games
    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. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,505
    201
    43
    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. lotzi

    lotzi

    Member
    6
    0
    0
    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?
     
  11. winterhell

    winterhell

    Member
    1,165
    7
    18
    Already responded to that question in the other topic.
     
  12. lotzi

    lotzi

    Member
    6
    0
    0
    Fair enough. Looks like I'm making pong lol
     
  13. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,505
    201
    43
    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:

    [​IMG]

    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:

    [​IMG]

    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. Xiao Hayes

    Xiao Hayes

    Classic Eggman art Member
    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. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,505
    201
    43
    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:

    [​IMG] [​IMG] [​IMG]

    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://bigevilcorporation.co.uk/2012/02/28/sega-megadrive-1-getting-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.sonicretro.org/SCHG_How-to:Work_with_Motorola_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.com/watch?v=p83QUZ1-P10

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

    And it's probably also a good idea to understand the address map of the Genesis itself: https://en.wikibooks.org/wiki/Genesis_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.com/Primer-Graphics-Development-Wordware-Library/dp/1556229119

    Sonic Retro actually itself hosts a pretty terrific physics guide here: http://info.sonicretro.org/Sonic_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.sonicretro.org/index.php?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.
     
  16. Xiao Hayes

    Xiao Hayes

    Classic Eggman art Member
    Thank you very much, that's the kind of help I needed! Or so it seems, I'll have to put it in practice to really know. I'm not sure about how much I need to do my way and how much use could I make from some already made content, but I wanted to include palettes and block mappings in the same fashion as they are in 16-bit Sonic games, and some other "tiled" effects like the way some ledges crumble. Last time I forgot to tell you that I already had plans on trying rom hacking to understand better how do the original games work because of this all.

    As I told you, I know programming and I'm pretty decent at it, but I know nothing at all about coding game related things besides making all the tutorials and checking all the examples from GMStudio1, and I want to do more than what that toolkit allows me to, and I don't like buying a new version every 2 years (at least GMS1 had a usable free version), so I chose to do my own engine even if it's a long, hard and tedious task. Maths will be the hardest part, I have it almost forgotten, and I didn't know that much in the past, but I'm smart and confident about my coding capabilities; not that much about my time managing ones, though. :v:

    Thanks again, let me ask you just a little question that has come to my mind after checking the links: Is there something useful to find in GameDev, or something that makes creating an account there worth enough? That website was one of my only hints to try and find something like what you've told me.
     
  17. Zphase

    Zphase

    Member
    14
    1
    3
    This retro engine sounds kinda like you may be able to use it, or just check it out for ideas.

    http://www.tilengine.org/index.htm

    post #4 from forum
    http://www.tilengine.org/forum/showthread.php?tid=6
    It has a basic sonic background demo and it also has c# bindings

    here is a video
    https://www.youtube.com/watch?v=wjrCPRD1BKk
     
  18. Aerosol

    Aerosol

    Not here. Moderator
    11,163
    573
    93
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    Hey that TileEngine thing is neato.

    I just started faffing about with Godot Engine myself.
     
  19. Lapper

    Lapper

    Lappering Tech Member
    1,763
    951
    93
    England
    Sonic Studio, Sonic Physics Guide, Kyle & Lucy, Freedom Planet 2
    While the actual process of making the engine is up to you, what doesn't change is how the collision actually *should* happen. There are methods using tiles and methods using vectors but other than that, it's always the same if you want authentic results (unless you don't care about accuracy)

    [​IMG]

    2 floor sensors (red), 2 ceiling sensors (green) and 1 wall sensing line (blue). I've illustrated him as a box but honestly he is just a bunch of 'lines' when it comes to collision.

    His wall sensor is illustrated as 4px below the centre, however I think it's actually 8px below his centre and then ends up right at your centre when you are on any kind of incline. 4px is a good average though because I'm not certain, I bet someone could shed light on that. It pokes out 1px each side (it's effectively 2, one side pushes you out of solids left, and the other right).

    His floor sensors will always pick the highest point it finds (if it finds 2). The second illustration shows how far these sensors actually check into the ground (they only extend like this when he's already on the ground).
    So while he's on the ground, if those extended sensors find anything, he'll stick to the highest one found. The only time he stops is when that wall sensor touches anything, which would only happen against a wall. This means he'll never just come off a slope, he'll stick to it unless it's a 16px or higher cliff

    The ceiling sensors are exactly the same when seeking, but of course react different when they find something. A flat ceiling wont attach you, it'll just stop your Y Speed. Other angles will rotate you correctly and stick you as if they were floor sensors, using the ceiling sensors as floor values, as described above.

    As someone said above also, this whole setup will rotate 90 degrees for walking on walls, ceilings, etc. So on a flat angle (0 degrees) if you walk up a curve and pass 45 degrees, it'll all flip sideways.

    Of course, that's just collision. How his speeds change and how he reacts to things is all about using the right values and trig.
    http://info.sonicretro.org/SPG:Solid_Tiles
     
  20. Xiao Hayes

    Xiao Hayes

    Classic Eggman art Member
    My goal is a multi-platform C++ only engine, but I'll check anything helpful, just in case. ;)


    I' read most of the SPG past year, and also checked the GMate engine at the beginning of this one. I figured out a lot on how layout and object collision worked back in the pre-3D days, so I think this battle is already won, but I needed to know the low level coding to do what I want or, at least, start from where I want. Thanks for your time anyway, I appreciate a lot there's so many people willing to help with this.