Proof of Concept - Soccer game

Paragon (1138)

02-02-2021, 23:35

Hi,
I've been working on a MSX2 soccer game prototype for a few weeks now.
I've added to my C library all the features I needed (screen-split, music/SFX, sprite-text, etc.) and I think I now have everything I need.
I put everything together in a test version to check the feasibility of the project.
It's a bit slow, but it's playable and there's a lot of room for optimization.
I use a lot of bitmap sprites so I'm mostly limited by the VDP (I still have a lot of CPU room to add gameplay).

Here's what I have at the moment:
- 14 players and 1 ball bitmap sprites on the field (updated every frame for the moment).
- 1 player can be controlled with the keyboard with very-basic gameplay (Arrows to move, Graph/Alt to change player and Space to shoot).
- HUD using HW sprites.
- Hardware scrolling with screen-split to scroll beyond the 256 pixels page limit.
- All assets (sprites, music & sfx) are place-holders (riped from somewhere else).
- The whole thing fits in less than 32K (I'm aiming for a 48K cartridge).

If you could test this prototype on real machines (MSX2 with 128K of VRAM), I would like to be sure that there are no technical problems: gos_0_5.rom

I already tested it on my Philips NMS 8250.

If you want, I can provide information on some technical aspect of this prototype.

Aangemeld of registreer om reacties te plaatsen

Van Grauw

Ascended (10821)

03-02-2021, 01:05

Nice, it looks good!

And I think a while ago I read here that there was a lack of good MSX soccer games .

I am always interested in hearing technical development background stories!

Van geijoenr

Champion (392)

03-02-2021, 01:12

Hi aoineko, it looks very cool, I assume you are reproducing the style of sensible soccer.

I tried in a turboR and indeed is very slow. I would focus in either optimizing the speed a lot or adding complexity to what the players can do. I mean either the players can dribble and do tricks so that the gameplay focuses on that, or they go very fast and the gameplay is about speed, like in sensible soccer.

Van Grauw

Ascended (10821)

03-02-2021, 02:18

Some constructive thoughts;

Since the split for the 2-page scroll affects the sprites, what about using a regular circular scroll where you copy new lines in the border as it scrolls? You could use CPU-VRAM transfer if you want to keep the VDP commands free for other things.

For the player sprites, did you consider hardware sprites? They are mostly one colour per line, so maybe if you tweak them a little it will look good with a single sprite per character. Otherwise you could go for two or-sprites per player and employ flickering. Possibly only on the 2nd sprite so that even if it flickers the characters still stay visible, just shimmer a bit in some of the pixel details. Assuming the AI kind of avoids all players bunching up on a single line and there are never more than 8.

If the characters are sprites the background could even be done in screen 4 to reduce the VRAM bandwidth needed.

Van andrea.denara

Expert (73)

03-02-2021, 08:05

Fantastic!
It just needs some speed

Van mzoran

Master (161)

03-02-2021, 09:54

Looks very nice. I am actually doing a football game myself but for MSX1 and can relate to your problems needing to be solved. I fear that, if it is already so slow, it will not get any better with AI included. The graphics stuff is the easy part, making a game is another. That is why I will hold off presenting my work until I feel the game is actually playable. Good luck with your work.

Van TheKid

Paragon (1238)

03-02-2021, 10:56

Very nicely done!

Van santiontanon

Paragon (1832)

03-02-2021, 15:11

Not a fan of soccer, but this is very cool, and looks really professional even if it's just a demo! Looking forward to hearing which techniques are you using to gain speed

One little detail on playability is that usually in these types of games, when you press the key to change player, instead of rotating over different players, you switch to the player that is closest to the ball, maybe that can be implemented here too?

Van aoineko

Paragon (1138)

03-02-2021, 23:03

geijoenr wrote:

Hi aoineko, it looks very cool, I assume you are reproducing the style of sensible soccer.

I use the sprites of Yoda Soccer, a clone of Sensible Soccer, but I'm not aiming at the same kind of gameplay at all.
I want something less arcade, more tactical.
If I can otpimise, it will be to have something more smooth, not faster.

mzoran wrote:

The graphics stuff is the easy part, making a game is another.

I know, but I'm quite confident.
The graphical part take 3-4 frames (at 50 Hz) but the CPU part take less than 1 frame.
We'll see.

santiontanon wrote:

For sure. I plan to have 2 change methods: cycle between 2 nearst players, and change to a player in a given direction.

Grauw wrote:

If the characters are sprites the background could even be done in screen 4 to reduce the VRAM bandwidth needed.

The problem with soccer games is that all players can be lined up on certain phases of play (such as corners).
And anyway I'm going to need HW sprites for different HUD elements (timer, score, 4 player selectors, stamina/shoot power gauge) and to save 2 VDP commands on the bottom goal posts.
One of my ideas was to replace on the fly players away from the ball with sprites. But if I can avoid it, I prefer.

Van aoineko

Paragon (1138)

03-02-2021, 23:08

Here are some technical details:

I'm using Screen 5 (Graphical mode 4) with 212 lines.
The terrain is 256 pixels wide and 384 pixels high.
The terrain's scrolling is done via register R#23 of the V9938 (VDP of the MSX2).
I use line interruption (h-blank) to change the page displayed when the scrolling should make the display to loop on the same page. For example, if I'm displaying page 0 and my vertical offset in R#23 is equal to 100, the 156th visible line on the screen (256th line of the VRAM) should display the 1st line of page 0, but the screen-slit allows me to display at this moment the first line of page 1 (so I can "continue" to scroll over the next page of the VRAM).
I use a classic double-buffering method to draw on a different VRAM space than the one visible.
To draw my bitmap sprites I use a classic technique : restoring the background (from frame N-2), backup-ing the background in VRAM (at the updated position), drawing the sprite.
My bitmap sprites are compressed by a simple algorithm I called Crop16: I store in 4 nibbles (half-bytes) the min/max positions X/Y of the visible part of each sprite to limit as much as possible the amount of data processed by the VDP commands.
The complicated point is as my gameplay frame lasts several graphic frames (~3), I have to manage the h-blank and v-blank several times during a single gameplay frame.
Since I use hardware scrolling, I have to update the Y coordinates of the HW sprites used by my HUD elements (score, timer, selection) each frame to give the feeling they are immobile.
I use a custom palette that will allow me to have 2 unique colors per each teams (in addition to the common colors)

That's all I can think of at the moment.
Don't hesitate if you have any questions.

EDIT: Here is my VRAM layout : http://msxvillage.fr/upload/vram_layout.jpg

Van Grauw

Ascended (10821)

04-02-2021, 02:17

Nice!

To avoid the back-up copy of the background for each sprite, you could use a third, clean copy of the background which is never drawn onto as the source. This would not fit into VRAM, however since the background has a lot of repetition and the sprites are not tall, the restore-source can be compacted into much less lines so that it will fit in the space around the BG-Backup area. This way the nr of copies per sprite is reduced from three to two.

If you know in advance the sprite is not walking across a line or another sprite, then you can draw them with a HMMM copy (if green = color 0). You could use a look-up table to check if this is the case, marking where the lines and other players are in an 8x8 grid.

If you make the assumption that they move only by a few pixels at a time, if you increase their size with some padding you could even avoid the background restore copy.

Maybe some useful ideas.