What would be easier for a first ever attempt at Assembly programming

[BuckMulligan_]

I'm planning to teach myself assembly and write a game, but I'm wondering what would be easier to approach as a first project:

A) A basic arcade style game, i.e. simple game rules and input, a few limited graphics but a lot of movement and object interaction stuff

or

B) An RPG style game, i.e. fairly complex game rules and input, but barely any graphics and no real movement or interaction stuff

[Alone Coder]

Both are hard for a beginner. Maybe a board game will do?

[BuckMulligan_]

Both are hard for a beginner. Maybe a board game will do?

I should clarify beginner at Z80 assembly, not at programming in general.

[Alone Coder]

Arcade game will require a lot of non-trivial tricks. (Or else it will run at 10% speed)
People sometimes start with puzzle games.
RPG is a good option if you have programming background.

[dfzx]

Arcade game will require a lot of non-trivial tricks. (Or else it will run at 10% speed)
People sometimes start with puzzle games.
RPG is a good option if you have programming background.

I'd go the other way.

A really basic arcade game, like pong, would be quite straightforward and will cover most of the concepts required.

I've never done an RPG, but I'm guessing it would involve lots of data structures and algorithms to create the characters and "drive" the world. I'm not sure Z80 assembly language would be a great choice for that, and much less so for a beginner.

[Einar Saukas]

I suggest implementing a simple classic arcade game like Space Invaders.

It will give you the opportunity to learn most technical aspects without spending too much time.

[Matt_B]

Yeah, go with a very simple arcade game. The hardest part of making any game is finishing it off, and picking something with a minimal amount of graphics and logic where you won't have to engage in a lot of optimization, is going to help a lot towards that end.

Pong, Bomber, Breakout, Snake and Pac Man are all pretty good first projects. I'd tend to view Space Invaders as the next tier up; although it's still fairly simple you've actually got quite a lot of objects to keep track of with all the invaders, missiles, shields, plus a laser base and potentially a UFO. Games that involve scrolling - unless it's straight upwards in character-sized increments - are best avoided for beginners too.

For RPGs, I'd think that you' be better off coding in a high level language, especially if they're text-only. Although plenty were written in assembler back in the day it's much easier to calculate a 20% buff in a language that gives you IF statements, multiplication and floating point numbers, for example. Also, you're unlikely to need the performance of hand-optimized assembler for anything other than graphics anyway.

[Morkin]

I would've gone for (B) and done something RPG-ish. But that's because the game sounds interesting... But I'd say go with your gut, as you need to keep yourself motivated.

I found it easiest to build up a game bit by bit and let it evolve slightly - e.g. start with a graphic, then get it moving, then put some boundaries in (for collision checks) or whatever. See what 'feels' right to you.

One thing I'd suggest is decide early on how the main sprite will move, get that right so it feels good, and then stick with the decision (like in this thread) - number of pixel steps, frames of animation etc., whether to use a mask etc. Only because when you have to go back and re-write a drawing/movement routine it's a real pain and can take forever.

[R-Tape]

I'd go for A, but as Morkin says—as long as the idea motivates you, I reckon you could make either work. I find it easier just to start coding something, e.g. getting a sprite moving around, or drawing a grid, and letting ideas spring from that, rather than starting off with 'what genre should I do?'.

In case you're after resources, Jonathan's How To Write Spectrum Games is pretty comprehensive and has game examples (the PDF is in 'main file downloads on that page), and if I may be so bold, my own sprite tutorial.

Looking forward to seeing what you come up with.

[Ast A. Moore]

These are all great suggestions. I’ll just add a couple of my own.

For me, the most difficult part about writing a game is, well, designing it. Back in the day, I wrote many game prototypes in BASIC. Unfortunately, only Yankee has survived and prompted me to rewrite it in assembly.

That said, I often work on games in chunks. I write and optimize specific routines that deal with specific tasks. That way I don’t have to take on the huge undertaking that is writing a game from scratch. For example, I could work on a particular effect or character movement, inertia, optimized attribute placement, player input handling, text rendering, sprite drawing, etc. Then I stitch them together while making the necessary changes. Oftentimes, optimizations in one area open opportunities in another one, so the game develops as I go along. Then again, code optimization (primarily for speed) is one of my favorite pastimes.

[bobs]

You have to write something you’re interested in, otherwise it’ll be too much of a chore and it’ll gather dust. Aside from that write anything you like! All types of game have their own pros & cons. Personally I always find Tetris to be a good starter though.

And don’t get too bogged down on trying to write ‘perfect’ code, it really doesn’t matter to begin with - clear and understandable code is much better to start with. Get it working first, then worry about it looking nice and being fast.

As a wise man once said, you can’t have icing without a cake, but once you have the cake, put on lots of icing!

[Sparky]

Whatever you end up doing, don't forget this book!

https://spectrumcomputing.co.uk/entry/2 ... r_Spectrum

[Turtle_Quality]

The easiest one I can think of would be Breakout. You can start displaying bricks, bat and ball only as attributes, then if you get things working maybe change the bat and ball to sprite movement. Collision detection with the bricks can be based on attributes.

Whatever you choose, let us know how you get on !

[Bubu]

A really basic arcade game, like pong, would be quite straightforward and will cover most of the concepts required.

I agree with [mention]dfzx[/mention], a simple PONG game. You'll cover how to paint the screen (it's not so intuitive), read the keyboard, and above all how tu struct a game (begin, loop, end).

[FFoulkes]

I'd go through Darryl Sloan's tutorial. Then read this book.