Souverän Soccer [WIP]

[nikosidis]

Some facts regarding Amiga soccer games and joystick.

FIFA international soccer for Amiga could not really be played with a joystick.
As you might know Amiga do support 2-button without any active parts and FIFA supported that but the game was made on other platforms to use 3 buttons and therefore keyboard was the real alternative on Amiga or CD32 that had active parts in the joystick and supported a lot of buttons.

The most popular soccer game on amiga is SWOS. Still played by many including myself.
This is a one button game. Lots can be done with only one button like in SWOS.
It is not so difficult to get a 2 or more button joystick for Amiga.
There are for example playstation controller adapters or joysticks to be bought.
Example is the greek stick. https://tgsjoystick.wordpress.com/
I have build joysticks for Amiga myself with 2-button. It is not that difficult. No active parts.
All the same it might limit the audience that will buy the game.
I guess most only have 1 button joystick.
In some way it is possible to have support for both.
I'm not sure if this football game aim to be very realistic or more of a action football game.
Personally I think that we have a great action football game called SWOS.
I might prefer this one to be a little more realistic and in that regard I would prefer 2 button.
If the game will be action football, why not almost copy the SWOS controls. That way you have
something most are familiar with.

I'm not a fan of to much buttons like FIFA use now. I think FIFA is to slow and therefore quite boring.

Like Daytona675x say. Let's see how this turns out.
It is for sure a very exiting project

[Daytona675x]

@nikosidis
Thanks for that summery!

I'm no fan of too many buttons neither, but two are nice to have.
While all Amigas technically support two buttons without any stunts, it's just that for some weird historical reasons 1-button sticks are so common among users; a fact which I cannot ignore, unfortunately.

So my definite goal is to have controls that work with just 1 button, with optional support for a 2nd button (e.g. to easily distinguish between shooting and passing).

Also, I'm more the action orientated type of player, so I'd prefer to trade in realism for action and ease of use. More or less cloning SWOS controls is certainly not a bad idea. Playtesters can then come up with adjustment request, they will have the last word on the control details for sure.

Speaking of "ease of use", I want the game to be fun for total losers on the joystick too, which is why I'll certainly add an optional ball-glued mode.

[nikosidis]

Sounds perfect to me
1 button game with 2 button support.

I tried this SWOS clone on Playstation 3, I think it was.
It used 3-4 buttons and it just did not feel right.

[Daytona675x]

New wip video #22

https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

This time it's mostly about visual quality improvements and first gameplay logic functionality. I already mentioned the most obvious visual improvements:

• mip-mapping for the playfield's circles to massively reduce "gaps" at certain distances. It's not perfect yet, still needs some fine-tuning.
  
• the circles' resolution has been doubled.

Those were the two improvements which I showed off with those screenshots two weeks ago. Since then some more things have been done:

• the horizontal sub-pixel feature was accidentially disabled in at least some of the previous videos. At some point during development I added a define to toggle between subpixel- and not-subpixel support (which ultimately simply adjusts the coresponding lookup tables), actually just to be able to compare the difference, out of curiosity. This flag was still there and active...
  
• the crowd's Chip-RAM usage has been reduced significantly, all in all by a whopping 74k! I simply had forgotten to adjust some memory allocations depending on zoom-level, so it always allocated enough memory for the highest level, which is unnecessary of course.
  
• the crowd's animation is at a constant rate now. Before it was somewhat unwantedly linked to the zoom factor so it tended to toggle when zooming in or out.
  
• more optimizations. My coding style is to first code everything in C/C++ and to only asm-ify the parts which actually make a significant difference. So when I identify a performance-critical area for which the C compiler produced suboptimal code (surprisinlgy often), then I use inline-asm to improve that section while keeping the original C code as comment. This approach works very well - unless the compiler's inline-asm support is broken... This time I tapped into such a trap: I wanted the compiler to put a table's start address into some free A register. This table was traversed earlier in the code through a temporary pointer variable which had been increased in the process. Now the compiler wrongly reused this modified address register content instead of reloading it for the inline-asm part... The workaround I came up with was to tell the compiler to give me &table[1] in the asm block, which I then manually decreased with a SUBQ as first command. This forced the compiler to actually reload the address register. Every other obvious syntactic mod still triggered GCC's false asumption. Oh boy
  
• the referee's whistle sound has been added. After I recorded and prepared this video I noticed that I forgot to add the whistle-triggers for certain events, well, forgive me for not re-recording...
  
• first real gameplay logic functions added. For now this means detection of and (partial) reaction to all those standard ball situations like ball out, ball in goal, kick off, own goal, corner kick, etc. Internally this is just a small state machine which allows certain state transitions and reactions like triggering whistle sounds, alter ball position, increase goal numbers, change the ball-owning team and show messages so far.
  
• speaking of messages: those are very simplistic / rudimentary for now. Just a bunch of simple characters inside the free area at the top of the screen.

Apart from all that I also started to code a Win64-based AI simulator for the game. But this will likely be the topic of the next WIP video
As always the video has been sped up during load- / precalc- / boot-time.

Cheers!

[Havie]

This is coming on so well - keep it up!

[Daytona675x]

@Havie
Sure thing

@all
New wip video #23 (occlusion detection visualized)

https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

This video visualizes one of the game's internal optimizations when drawing the players.
The players are of course blitter objects. You can configure the Amiga's blitter in various modes, some being more costly than others in terms of performance.

Here in this game you can often get away with a very cheap simple copy operation. Unfortunately there are also situations where you can't: if a player partially occludes at least one other player or the ball, then a masked copy which preserves the background has to be used.

So some sort of occlusion detection would do the trick. Because the blitter always operates on 16bit words and because all the objects are already sorted from top to bottom this can easily be achieved with just a handful lines of code and a bit of bit-fiddling, at practically no cost with perfect results

Here in this video the players which are drawn using the cheap copy are drawn sort-of inverted. You can easily see how the blitter works on 16 pixel boundaries and how it needs an extra word depending on whether an object's actual picture ends up between two 16-pixel blocks on the display. When an overlap is detected the respective object in front is being drawn with "transparency".

As you can see this is highly efficient. In a typical game situation most of the players can be drawn using the cheap straight copy mode. Among other optimizations this buys me enough frame time to always keep 50 frames per second while not sacrificing visual quality.

Cheers,
Daytona675x

[amipal]

Sounds like you're progressing well!
I'm really enjoying reading about the different iteration of this project, and how you're solving the various problems you're coming up against.

[Daytona675x]

@amipal
Thanks, man! Yes, progress is great, as you can see below

@all
New wip video #24 (serial fun and more)

https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

For "Souverän" 2021 development ends with quite a blast: Many optimizations under the hood, important addons and a little surprise. The surprise first:

- I bought a null-modem cable But see for yourself Also, many thanks to Toni Wilen for adding serial-port support to WinUAE! And cheers to DDNI who suggested that feature.
Under the hood the serial-link support required not just serial protocol code etc. but also some additional features like playfield mirroring. Internally both machines have the exact same game-state and therefore all entity positions are identical too. So without that mirror-feature (which also mirrors the joystick input...) both playfields would appear identical instead of showing the respective team's perspective.
Of course we are still at 50Hz with serial-link too

Other than that:

- the player drawing has been further optimized, exploiting frame coherency. As you know from the previous wip video 23, the game contains logic to detect occlusions between all the entities to select a cheap non-transparent blitting mode if possible. In that case the clearing of the previous frame's content at such a player area is now being skipped if the new word-aligned blitter rectangle fully occludes the previous area because this means that the clearing is implicitely done while drawing anyway. The results are even better than I expected: there's no situation where this doesn't give a significant boost.

- player-BOBs which are only partially visible at the bottom are now properly clipped. This also helps to cut down the avg. frame time and saves some KB of precious Chip RAM.

- Fix: while I was at it I noticed and fixed a potential crash bug in the ball-shadow drawing. In situations when the camera is fast moving, e.g. after a goal when resetting the ball to the playfield's center circle, it could happen that the shadow-blit happened outside the bitplane area...

- the grass' distance shading has been improved to be even smoother. I hope this can be noticed after youtube video compression. If you sit in front of the real thing it's highly noticable

- active player markers have been added. For now both are simple colored bars, reusing hardware sprites 0 and 1. Until now sprite 0 was used for the ball when it's flying so high that it leaves the player-bitplane area; and sprite 1 was used to draw one top corner flag-pole and the near bottom corner pole (only one near pole can be visible at a time). Sprite 0 was pretty uncritical: because it was only used for high flying balls it was always above all players and therefore also above the markers, so reusing this one for one marker is just a matter of setting up a DMA structure for the ball plus one marker. However, sprite 1 wasn't usable with the current setup: the bottom corner pole's position would vertically overlap with a marker if the respective player walked near the pole, so the pole would just disappear if put into sprite 1's original structure :P To free up sprite 1 I had to completely change the bottom corner pole's handling: now sprite 2 is being reused to draw the pole. Sprite 2 was (and still is) used for the far and near goal's left part. Luckily the near goal is never visible if the near corner pole is, so I ended up having two different DMA structure's for sprite 2 which are loaded depending on the near corner pole's visibility. This again allowed me to reuse sprite 1 for the 2nd player marker. However, because the upper corner poles change in size depending on zoom level, a rather static DMA structure is not possible here. Therefore sprite 1 is fully rearmed once the grass begins - which is where the pole ends and which happens to be the top-most position the marker can possibly have (+1 ). Phew!

- the players which are closest to the ball are being marked. Usually the markers are drawn right below the players, unless the player's feet are clipped at the bottom, then it's drawn above the player. If a marked player is outside the view then the marker is placed at the respective edge to indicate the current position. This wasn't as trivial as it sounds because the display position values aren't calculated for invisible players.

- added some simple player controls for testing. You can walk and kick, two joysticks supported. If you get near the ball it will glue to your player.

- camera tweaked: if a player owns the ball then the player and not the ball is being focused, otherwise it looked a bit choppy when changing direction. And I zoomed out quite a bit so you have a better tactial view. Maybe I need to adjust the ball's size accordingly or even make it zoom too, but not for now, last not least because only real playtesting will reveal the optimal camera distance.

- real ball physics, with correct acceleration, gravity and friction.

Cheers and happy new year,
Daytona675x

[vulture]

looks great, happy new year m8!

[nikosidis]

Thanks for the progress report. Have a great new year

[DDNI]

Great progress Dan. Happy New Year.

[P-J]

Just came to say this looks sweet! I hope you're able to find the energy to get this over the line. It feels like after Sensi, everyone just stopped trying.

[P-J]

Originally Posted by nikosidis

Some facts regarding Amiga soccer games and joystick.

FIFA international soccer for Amiga could not really be played with a joystick.
As you might know Amiga do support 2-button without any active parts and FIFA supported that but the game was made on other platforms to use 3 buttons and therefore keyboard was the real alternative on Amiga or CD32 that had active parts in the joystick and supported a lot of buttons.

The most popular soccer game on amiga is SWOS. Still played by many including myself.
This is a one button game. Lots can be done with only one button like in SWOS.
It is not so difficult to get a 2 or more button joystick for Amiga.
There are for example playstation controller adapters or joysticks to be bought.
Example is the greek stick. https://tgsjoystick.wordpress.com/
I have build joysticks for Amiga myself with 2-button. It is not that difficult. No active parts.
All the same it might limit the audience that will buy the game.
I guess most only have 1 button joystick.
In some way it is possible to have support for both.
I'm not sure if this football game aim to be very realistic or more of a action football game.
Personally I think that we have a great action football game called SWOS.
I might prefer this one to be a little more realistic and in that regard I would prefer 2 button.
If the game will be action football, why not almost copy the SWOS controls. That way you have
something most are familiar with.

I'm not a fan of to much buttons like FIFA use now. I think FIFA is to slow and therefore quite boring.

Like Daytona675x say. Let's see how this turns out.
It is for sure a very exiting project

I think context-sensitive controls are a good thing if you only have one or two buttons. I love Sensi to death but the controls really prevented it from becoming a tactical experience rather than just end-to-end action.

So with that, totally agree that a game with a little more nuance would be a welcome addition to the old Miggy.

[Daytona675x]

@vulture
@nikosidis
@DDNI
@P-J
Thanks guys

@P-J
I'm still not sure about the controls, only that it has to be one-button, maybe with optional 2nd button for convenience. I want the game to be fast paced and that you don't have to think about the controls too much. With just one button this actually implies some sort of a context-dependent controls scheme, e.g. if not facing the goal but rather a team member, asume that the button-click is meant to be the command to pass the ball, stuff like that.
However, at the moment I'm still brainstorming and comparing and studying the different control schemes of the most famous Amiga soccer games...

[Cherno]

Just stopping by to say that this looks great and is surely a lot of fun to play! Best of luck with your project.

[Konrad]

Two-Button controls as in Super Sidekicks would be great.
Player has the ball: B1=shoot, B2=Pass
Enemy has the ball: B1=nudge(?), B2=Slide tackle

One-Button is rather difficult I think to get a proper feeling.
But what about implementing above scheme with short and long (>=0.5sec) button press
Player has the ball: long=shoot, short=pass (to facing team member. If not facing a team member, then pass to closest team member)
Enemy has the ball: press=tackle (don't think that two options are needed, but would of course be fun)

[vulture]

@Daytona675x

Well, for 1-button controls, you can't go wrong by doing what Sensi does. For 2 buttons, what Konrad said makes sense.

[Daytona675x]

@Cherno
Thanks, mate

@Konrad
@vulture
Thanks for the input! Yes, most likely it'll end up being something like that, at least for the start.

@all
New wip video #25 (replay, in-game keys, markers, improved grass)

https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

Because the last video was handy-cam only to demonstrate the new serial-link feature, video quality was pretty bad naturally, so let me first mention again the two most important visual improvements since video #23:

- player markers added. Since the last video I further improved the marker positioning for players that are out of view.

- the grass' distance shading has been improved to be even smoother. This couldn't be seen well in the previous video.

Completely new stuff in this video:

- hitting "Esc" abandons the match.

- hitting "P" pauses or unpauses the match. Sound is being silenced during pause mode.

- hitting "F10" toggles the crowd chants on or off.

- hitting "M" mirrors the playfield so that each team is playing into the respective opposite direction. This is a purely visual adjustment, the internal logical entity positions etc. remain untouched, which is why internally directional joystick input is being mirrored too. This feature was already present in the previous version because it was necessary for the serial-link mode. However, back then it was tightly coupled with that mode and couldn't be toggled on the fly.

- and, tata, hitting "R" starts the replay of the last couple of seconds (at the moment up to 7 sec. which means 7*50 = 350 frames are being recorded to be exact). Hit "R" during replay to toggle slow-motion on or off. Of course the other keys also work in replay mode, especially "M", you can mirror the view whenever you like. Of course this implies that all 22 players have to be recorded all the time. However the full recording's data is already pretty compact and eats up 49k for everything (up to 350 frames of positions, animations, sound triggers, etc.). Anyway, it still needs some additional cosmetic love later, like the good old big R-letter, the game time at the point of the recording (right now the clock just stops) and maybe a quick begin/end curtain effect to better indicate the game's current replay mode state.

- oh, and at the end of the video you can get a sneak peak on the game's AI Simulator (Win64) which I'm working on in parallel. At the moment I'm trying out different approaches on basic targetting and running with the ball. I'll explain the AI and the simulator in detail once it's good enough to be transplanted into the actual game.

Cheers,
Daytona675x

[Reido]

Brilliant!

[nikosidis]

So nice progress
Thanks for sharing.