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!  

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?