Peter wrote:Dave wrote:I've been writing one. It *needs* 4 players, but is better with 6 or 8. I'm not a programmer, though, so....
Runs quite quick on the Q68 though.
Any screenshots? In which language is it written?
It's just blocks at present, so I'm quite embarrassed by it. Sorting out the basic functional game-play. Just working out the NPCs that fill in when there's a shortage of real players has been.... interesting.
Essentially, if 4 people play, three are assigned "zombie" status and the fourth "survivor" status. So it's a bit like Pac Man except the people chasing you are actually PEOPLE. Also, the environments aren't just blank maps, but rich graphical environments, and you have missions.
In each round, the zombie that catches the survivor plays the survivor in the next round. They get to continue with their story.
You have to make it out of your house to the supermarket. Through the parking lot. Through the store shelves. Out through the back. Through the warehouse. Countryside. Farm. Army base. Secret lab. To make it interesting, the zombies can only see the survivor if he's moving and has line of site, and for a few steps after that. More steps if the survivor is running, less if they are walking or stopped. Also, the survivor has stamina which wears out, so he can outrun a zombie *at first* but if he continues running he gets tired and slows. So sometimes hiding is a better strategy, and for the zombies (who can always see each other) spreading out and actually searching is the best strategy - IF they decide to co-operate. If 6 people pay, 2 are survivors. If 8, 3 are. They can either team play and get everyone through by tun use of running and distraction/leading away. SHIFT arrow makes for running. CONTROL arrow is "making noise" to lead the zombies a certain direction. The zombies do not know how many survivors there are. I might mix it up a bit more and make it so the survivors and zombies are semi-random and don't know how many of the other side there is.
When it's a bit further along, I'll public beta it, but it is written for the ESP32. There can be plug-ins for other ethernet chipsets or serial bridges.
Between rounds, there is a telnet-based chat facility so players can chat between rounds. This gives time for people to join/leave, and something to do if they join while a game is in progress. It requires a server, which is a QL. The server does the intercommunication (which is UDP)
Peter wrote:I picked the CP2200 ethernet controller for the Q68 because I wanted the software on SMSQDOS side, as a principle. Offloading everything to a different CPU/OS like the emulators or the chips you mentioned is far easier, but it tends to move software development away from our wonderful 68K architecture.
Another point for the CP2200 was that it can directly and efficiently interface the QL, because of its parallel 8 bit 5V tolerant bus. This allows a trickle-down effect from possible Q68 developments.
I think the CP2200 choice is pure. My inner conflict is the same as Andrew's. Who is going to develop the drivers and any software to use it? It's a catch-22. My frustration is that I am facing the same catch-22 daily with the lack of driver for the serial card. I know I sound bitter - it's just really hard to develop hardware and not be able to go any further with it because it doesn't work due to weakness in an area where I am quite inadequate. I'm a brute force programmer, limited to BASIC for the most part. I have a couple of hand-coded assembly bits in my game that just do screen draws. Everything's word-aligned so the burden is quite light.
Just saying, I understand the decision a lot better now I have been on the receiving end of it, and I empathise!