Hello everyone,

For learning purposes, I want to try to make a small graphical snake game in assembly. I've thought about where to start and which tools to use and personally I thought about using SDL and C to handle the keyboard input and the graphical output, but I would really like to know from other if there are better/easier ways to do this.

Thanks

You want to make it in C or in Assembly?

Both are programming languages and, thought it is totally possible to write a game in assembly, is it recommendable? No. Not just because it takes a lot of work do get done, but maintainability is also difficult.

As for in C, you can do it. Lazy Foo has some very practical tutorials with SDL2.

32 minutes ago, Romee said:

but I would really like to know from other if there are better/easier ways to do this.

But, your problem here doesn't seems to be (only) language, but lack of understanding of game architecture. For that, I think this is a good read: http://gameprogrammingpatterns.com/contents.html. The topics State, Game Loop, Update Method and Object Pool are, in my opinion, the most useful to understand how to design a (good) game architecture (at least as a start point).

Quote

You want to make it in C or in Assembly?

Both are programming languages and, thought it is totally possible to write a game in assembly, is it recommendable? No. Not just because it takes a lot of work do get done, but maintainability is also difficult.

As for in C, you can do it. Lazy Foo has some very practical tutorials with SDL2.

  1 hour ago, Romee said:

but I would really like to know from other if there are better/easier ways to do this.

But, your problem here doesn't seems to be (only) language, but lack of understanding of game architecture. For that, I think this is a good read: http://gameprogrammingpatterns.com/contents.html. The topics State, Game Loop, Update Method and Object Pool are, in my opinion, the most useful to understand how to design a (good) game architecture (at least as a start point).

First, thanks for the quick reaction. But excuse me for my bad explaination, to me it sounded pretty logical, but I think I was mistaken. Namely, this is my case:

I will be making the game using both Assembly and C. Assembly will be used as the main language of the game, i.e. all the gameplay logic (for example, incrementing position, incrementing scores, etc.) will be done in this language. But, as input handling and graphics drawing is slightly out of the scope of my goal for this small project, I will do that by writing the functions that do that in C, using a media library, like SDL. To call the functions I make in assembly, I use the call instruction. 

This way, I can divide the input handling, graphics drawing, etc. to C and the graphics library and the gameplay logic to assembly. But, my question still remains, is SDL a good option for this, or are there any better solutions.

Thanks by the way for the Game  Architecture link, a long time ago, I made a small game with C++ and SFML, but my knowledge was a bit rusty, so I will read that page without a doubt!  

Why do you want to do a whole game in assembly?  You'll kill yourself over something that doesn't have much practical use.  Also if you don't plan on becoming an assembly expert the compiler will likely beat you.  If you want to get a feel for assembly from top to bottom try something non-graphical.

My suggestion is if you want to play with assembly try inline assembly in a C/C++ program.  You can also mess with intrinsics if you're interested in SIMD programming.  Inline assembly would be your best bet at getting a taste of assembly.  If you want to go further, your C++ compiler likely outputs assembly as well, so you can make small programs and examine the assembly output to see how the compiler handles it.

1 hour ago, Romee said:

First, thanks for the quick reaction. But excuse me for my bad explaination, to me it sounded pretty logical, but I think I was mistaken. Namely, this is my case:

I will be making the game using both Assembly and C. Assembly will be used as the main language of the game, i.e. all the gameplay logic (for example, incrementing position, incrementing scores, etc.) will be done in this language. But, as input handling and graphics drawing is slightly out of the scope of my goal for this small project, I will do that by writing the functions that do that in C, using a media library, like SDL. To call the functions I make in assembly, I use the call instruction. 

This way, I can divide the input handling, graphics drawing, etc. to C and the graphics library and the gameplay logic to assembly. But, my question still remains, is SDL a good option for this, or are there any better solutions.

Thanks by the way for the Game  Architecture link, a long time ago, I made a small game with C++ and SFML, but my knowledge was a bit rusty, so I will read that page without a doubt!  

It's totally up to you, but I wouldn't advise making a game using Assembly if you're looking at being as productive as possible, and looking to reduce the amount of time spent debugging, as well as making future changes. Even using C would be a better option, but I would still not recommend using either for a new game developer.

I would suggest sticking to any language that supports more mainstream OOP concepts like C#, C++, or JAVA.

Are you looking to do this just as a hobby project to toy around with Assembly and C? You're going to be putting yourself through a lot of headaches using Assembly. If you're looking at making the program fun as fast as possible, it's not going to make enough of a difference to avoid other languages like C#, C++, or JAVA with today's machines.

I personally use C++ with SFML, and OpenGL when needed. I was never a fan of C with SDL, but that was way back when it was still version 1, not 2. I've heard good things about SDL 2, so it's worth a look if you're looking at sticking with C along side Assembly.

I wish you the best on this interesting journey.

I would say there is merit in making such a simple game in Assembly for classic computers such as the C64, Amiga or ZX Spectrum.  The cpus and memory maps are much easier to learn - especially the 8-bit machines.

The communities for those machines also appreciate new projects.

What you want to do is perfectly feasible.

If I understand your intention correctly you want to use the SDL to develop a C framework for your snake game to run in? Something like:

int main()
{
  init();
  
  while (!quit)
  {
    poll_input();	// Update input state
    update_game();	// Call your assembly entry point; assembly code updates the game state and renders to a bitmap
    present();		// Use SDL to display the bitmap
  }
  
  shutdown();
  
  return 0;
}

If that's your approach then it's a sensible way to limit just your game state and logic to being developed in assembly.

I'd recommend first just writing a single routine in assembler and working out how to assemble that and link it with an object file compiled from C, then work out the ABI so you know how to handle parameters and return values, and finally how to share data between the assembly and C parts. Once you have that plumbing in place you can iterate away on your game in assembly.

31 minutes ago, Anri said:

I would say there is merit in making such a simple game in Assembly for classic computers such as the C64, Amiga or ZX Spectrum.  The cpus and memory maps are much easier to learn - especially the 8-bit machines.

The communities for those machines also appreciate new projects.

I agree, I've done a couple of hobby games for the 8-bit Atari, it was the first computer I had and learned to program on and it's a lot of fun and very rewarding to develop for it using an adult's brain and modern dev tools.

It is a great learning exercise, and I agree there is much value to it if this is something you want to learn.

11 hours ago, Romee said:

Assembly will be used as the main language of the game, i.e. all the gameplay logic (for example, incrementing position, incrementing scores, etc.) will be done in this language. But, as input handling and graphics drawing is slightly out of the scope of my goal for this small project, I will do that by writing the functions that do that in C, using a media library, like SDL. To call the functions I make in assembly, I use the call instruction. 

Fair enough.  Split it however you want.

12 hours ago, Romee said:

I would really like to know from other if there are better/easier ways to do this.

Sounds like you have a reasonable set of tools.  As you increase in skills you'll want better tools, but it doesn't take much to build what you described.

It has been a few years, but I made several similar projects back in my high school and college days using simple text editors and command-line compilers. It can still be done today.

The best question to ask now is:  What is stopping me now?

If nothing is stopping you now, then get to work!   If something is stopping you, identify that one thing and get it resolved. Then once it is resolved, get back to work.

So instead of asking if you have the best tools, let's turn it back on you.  What is stopping you from making progress on the project?  Why aren't you typing away at your solution right now?

15 hours ago, Romee said:

Hello everyone,

For learning purposes, I want to try to make a small graphical snake game in assembly. I've thought about where to start and which tools to use and personally I thought about using SDL and C to handle the keyboard input and the graphical output, but I would really like to know from other if there are better/easier ways to do this.

Yes, libSDL2 and assembly are a good combination for game development.  I'd recommend using Linux because the traditional toolchain is slightly easier for assembly development (gas, ld, make, and gdb; simpler and more consistent calling conventions; plenty of Free libraries you can leverage) but you can bend your workflow to fit other tools if that's more your thing.

You'll want to stay away from mixing C++ or Objective-C libraries with assembly because of the complication of name mangling.  Other languages like Java, Rust, or the interpreted languages would be painful to use with assembly.

Good luck and enjoy the trip.