This is a screenshot with the player’s game screen updated with the various sprites. And also on the screen, it shows the updated status information at the bottom. This has 8 sprites being used for each player’s screen. There are 6 city sprites, one Command Center sprite, and the Missile sprite. the missile sprite is shared with the Explosion sprites whenever one of the objects get hit. There are 2 types of explosion sprites used in this game. One is for typical hits on any object. then when an object is fully destroyed, there is the Nuke Explosion sprite to signify that the City is completely wiped out – or the command Center.
Here’s a first look at a screenshot of Space Command with 8 players connected to the C64 server. The game screen shows the command center in the middle with the cities beside it, with 3 on the left and another 3 on the right. similar to the ol’ arcade game from 1980, Missile Command. But now with multiplayer networking. This is still shown running a simulation for 9x C64 computers on my desktop. Each screen will be a separate C64 computer that each player will control. With the 9th being the C64 Server which manages the multiplayer networking.
The screen is in Multi-Color Char mode, and so I haven’t the optimum choice in colors at this point – versus Multi-color Bitmap Mode, but this consumes more memory. This is something to work on later once all the kinks are worked out of the game. Jeff Brace <Arkaxow72> helped work on the additional sprites and sound effects, So we will have sprites showing the damage, explosions, even a Mushroom cloud from a Nuke strike. And the sound effects will include things such as Red alert sirens when a missile is inbound, missile launch, and a cruising missile. There will be more sprites that will get added for gameplay. I plan to add the additional support for the players to take turns at the controls.
Getting to this point was an arduous process. With getting acquainted with the TCP/IP network code running on a 6502 CPU from 35yrs ago. And also getting the game code to fit together in only 64KB of memory. Now I have to make sure the missile they will launch can fly across all 8 computer screens without getting lost. And hope the radar screen in there helps to keep them on track too.
been a long while for an update,
Trying to get this project ready in time for the next event. So busy with updating the game code to add network support for 8 player. Here’s a screenshot of the latest[click below]. I have 9x instances of VICE running here, This shows all 8 players connecting to the C64server. Now that this is stable, I have to finish updating the rest of the game code. Still have 12 days left till VCF East 9.1
Tonight, I managed to get a test program running to check the functionality of the Multicolor Character mode. Using the export files from CharPad where I created the background screen, I was able to get the program to load these files properly and display the background screen perfectly. It took some extra work to finally convert that multicolor bitmap screen. But that’s because there isn’t really a clean or smooth method for converting between these two formats because of the color limitations. the current color scheme will get us going for now so we can finish the game code.
CharPad actually has you export several files from your design. But the documentation provided is a little ambiguous. It spends effort describing these extra features within the tools while the existing method is already what’s possible using the available export files. I had already made a test program using the original method for loading a screen using Character graphics mode. And I found out, after all, that the same method can be used with the export files from CharPad — besides what’s described in their docs. As you’ll see the test program, it’s using the same method as before – nothing fancy going on.
When exporting files from CharPad, there is a Character Set file which contains the Custom Characters and Tiles – which you can also create inside this tool. I used only 1×1 Tiles in this design. I have the test program load this data at addr $D800. Then a Map file which contains the Screen codes for the Screen Memory at addr $400. Also a Tiles Map and Attributes Map. At the moment, there is no need for these last two files. I’m trying to find more information as to what advantages there are to using these lookup tables. From what I see so far, you can make use of these to change the screen codes within the screen memory during runtime. Now back to the game code……
While changing direction with the graphics mode options, – hopefully for the last time – I’m using the CharPad tool now together with the Timanthes tool to organize the background screen using Multicolor Character graphics mode. One of the things I found out this past week is that the Timanthes tool doesn’t properly convert that background screen I made last time using Multicolor Bitmap mode, I tried to convert that into a Multicolor Character mode. Even though you can change Layer 2 in the Layer properties window from Multicolor Bitmap to Multicolor Character and re-save the project – it doesn’t warn you that your design is using excessive colors. So I continued to use the CharPad tool to build the new background screen. Below is the current view of the background screen with the cities and command tower.
Unless you plan to use raster splits – eventually I do plan on this – to increase the colors per raster line, then you only have 4 possible colors per cell [reference] So I took the Tiles that were generated by Timanthes from the bitmap screen – I mentioned in my last post - and loaded it into CharPad. I can then view the Tiles in the Character set. Even though the colors are not being tracked accordingly, since we’re converting into in Multicolor Character graphics mode, the basic view of the Tiles are manageable. Then I’m using the CharPad tool to recreate the same background screen by using the Tile map and assemble a new Screen map in this tool [insert screenshot]. Also some of the Tiles need further editing to improvise the limited color scheme. Next, I will have this exported into a file which i can load using another test program to check everything operates according to plan. [link to code]
The background screen is organized into several sections. The first being the view of your city with the Space Command right in the center. Next there is the command console below that view. This is subdivided into 3 sections as well. the center being the Radar view to see incoming missiles from the opponents on the network. The radar view shows the 8 players in the foreground. If one of them fires a missile, then it will be projected on that radar screen. As the missile approaches your facility, it will come into view on your screen. The left and right sections contains various information for your facility and game status.
It’s been a while since my last post, These winter nights can be a drag without enough caffeine. So it’s time for a ”coming up for air” to write another update, so to speak, on this network gaming project with my crime-fighting cohort, Jeff Brace (Arkaxow). One of the refreshing attributes to programming on 30yr old computers is knowing it’s limitations. No matter how many advances, mods or upgrades there might be from 3rd party suppliers, there will be always be the familiar restrictions when programming on 8bit computers such as the C64 or others.
The biggest concern, of course, is memory. The past couple of months we have been scouring the manuals and websites about several options on what method to use for the background screen for our current network gaming project. I’ve been coming up with options to create a new C64 background using one of the various cross-platform development tools called Timanthes. One problem with this is that there’s no ‘Help’ file to go along with this tool. So it took quite some time to dig up some info online thru various searches to get it to cooperate. Eventually I managed to successfully create a Multicolor Bitmap screen which i can load into the C64 [screenshot].
I wrote a test program to check the functionality on how to manage the memory mapping between the screen memory, color ram, etc [screen10.asm]. The bitmap screen itself requires 8KB of memory to hold the graphics display. I currently use bank0 for the VIC-II so this loads in at addr $2000. There there’s an additional amount of memory need for the various colors – since this is a multicolor bitmap (4 colors/2pixels) The horizontal resolution is cut in half but you get more colors in return. So there’ an additional 1000 bytes needed which is stored in the Video Ram at addr $0400 for color1 and color2 attributes. And there’s an additional 4KB for the Color Ram at addr $D800 for the color3 attribute. There’a one other color register in the VIC-II at addr $D021 for the background color (global attribute)
And so it appears that we keep running out of memory with the current graphics mode option. The Network library is rather large (13.8KB) – used to interface with the C64NIC+ cart – and so is the packet buffer space (21.4KB). So this keeps limiting our graphics mode option. No matter how I fiddle with the memory map for the game code, I can’t continue to use the multicolor bitmap graphics mode without running out of memory. For this next step, I’ll have to switch back to using Character Graphics mode in order to save space.
After organizing the *.d64 images for each instance of VICE running here, I managed to get 4 players to connect to the Server. There was one small moment of a gltich where player#2 didn’t connect completely. So I restarted everything and tried again. I suppose this is one of the pitfalls when working with UDP. I’ll have to investigate that another time if it becomes a bigger problem. In the meantime, I’ll have to add some retry mechanism so I do’t have to restart the VICE emulation.
Below is a screen shot of what I have so far. The screenshot shows the 5x instances of VICE running here. The larger VICE screen on the right is the Server. And the group of 4 instances of VICE on the left are the 4 players.
You can see on the Server screen the various status messages when each player connect. The screen scrolled off so you don’t see player 1 connection, but it did, since I connected with that player first. I changed the sequence a little. I added an extra prompt to ask when the player is ready to start the game. This also helps me monitor the status messages on the player screen as well, since it will pause at the “ready’ prompt before changing to the game screen.
Something I noticed just now. Even though I could get several instances of VICE to run on my PC using the same *.d64 file, it must have been using the same ‘ipconfig’ file from that image.
Even though I would run ‘Configure’ in the beginning for each instance of VICE, the ipconfig file was actually holding the network settings for the last instance of VICE only – which is last player !! You can see the player name and player’s IP Addr in the ipconfig file generated by the ‘Configure’ network tool.
I thought the game only needs to load the ‘ipconfig’ file just once in the beginning – which is true.. But i was running ‘Configure’ at the same time in each instance of VICE. So the ipconf file must have been getting corrupted when several instances of VICE were trying to save to the same ipconfig file. aarrrgghh
So now it looks I can skip having to hookup several PC’s to my network to run VICE. And I will make individual copies of the *.d64 image for the game eveytime I make a new build. –stay tuned !–
I’m starting to notice that glitch more often now. I have 4x instances of VICE running on the same PC. I wasn’t sure what was going wrong for a while. But then I saw the Server mysteriously connect with one of the Players as soon I started the Server. And that one Player wasn’t even running Duel yet !! I would only do a Hard Reset in VICE for each instance before I would load the next build of the game code.
So then I would restart all instances of VICE every time I loaded a new build, but I would experience some of the same quirkiness behavior. Some players would connect and others don’t, and then vice versa. It appears the VICE networking support may have a glitch with multiple instances on the same PC.
I think I have to get separate PC’s and run only 1x instance of VICE on each to test the game code. I have an old laptop I can dedicate to this. So I will stall have 3, including the C64 to test the game code. Where one is always the Server and I will have 2 players. But I’m looking around for another junker PC to run VICE so I can get 3 players to connect again.
Once I get the extra PC, I’ll use Wireshark to analyze the network traffic during the game. I’m hoping this quirkiness disappears once I try this.
I’ve been making progress on the multiplayer Artillery Duel. I’ve been discussing with Leif Bloomquist(Schema) for quite some time about his C64 network game, Artillery Duel, which he made several years ago. This happens to be the first C64 Network Game. I’m working with Jeff Brace(Arkaxow) in getting a multiplayer version running. We’re using the C64NIC+ cart from Retro Innovations. And I use the source code which Leif sent us. And this makes use of the TCP/IP stack for the 6502 called NetLib64. The code is built using the DASM assembler.
I have 4x instances of VICE running here, and it’s not getting that slow yet. Eventually i will try and get 8x instances running here to fully test the multiplayer options. I have one instance running as a server on Duel. I managed to get the other 3 running as players to connect with the server. The 1st VICE running as a Server is changed where it doesn’t play the game as before. At the moment, I have it sit and waiting on the “Listen for Announce Packets” screen.
And there I can see the status messages on the Server screen – eg, player name, player IP addr – when all the other players connect to the server. Then you get another confirmation that each of them have connected when all of the payers switch to the game screen.
One thing I noticed, one of the players had a glitch where it didn’t connect the first time. So I had to restart that one. I was thinking about adding an option to let you retry the connection within the game. So you don’t have to reload the game each time.