Homebrew sulphur mining game: Io

[PkK]

With the changes made in the last few days, the game Io has become quite playable, so I decided to post the current development version, 0.10, here.

 

Here's a quick description of some important screen elements:

 

* "Sulphur in HQ": Shows the current amount of sulphur in the HQ (you loose when this reaches 0, and the sulphur storage capacity of the HQ

* "Workers": Shows the number of free workers (i.e. those not currently working on a construction site) and the total number of workers

* "HQ Level": Current HQ level. Higher levels increase the amount of workers and the sulphur consumption. You win the level by increasing this to 10.

* "Toolbar": Shows the currently selected tool (same as cursor) and a clickable list of tools (you can also change the tool by using the right fire button). At certain moments,such as after changing the tool, the toolbar is briefly replaced by a display of the name of the new toll.

* "Sulphur Source": Provides sulphur. The suplhur can be supplied to other storage locations, such as your HQ, when there is a road or rail connection.

* "Rock": Construction is not possible here.

* "Sulphur vent": Can be turned into a Sulphur Source by building a depot on top of it.

* "Debug Info": Just some data to help me during development. Does not affect gameplay

 

The main aspect of the game is to supply enough sulphur to your HQ by building a transportation network consisting of sulphur sources, depots, roads and rail. At the start of the game, you should first connect your sulphur source to the HQ. Rail connections have higher capacity than roads, but need more time to construct. One unupgraded sulphur source supplies enough sulphur for one idle worker. Busy workers need twice as much.

 

When the cursor is a above a node (HQ, depot, source) of the transportation network, the toolbar is replaced by a status display:

 

 

It shows the current amount of sulphur in the node, the maximum capacity and the level of the node (higher levels have higher capacity).

 

The difficulty level affects the game in various ways:

* Starting amount of sulphur in HQ

* Storage capacity at HQ

* Amount of rocks on the map

* Frequency and severity of threats

 

Philipp

 

P.S.:

There is an older thread on the previous development of Io.

When released, the game will come in yellow cartridges.

 

P.P.S.:

 

Improvements over the previous version 0.9:

 

* Blink background on threat
* Level loading infrastructure
* Level editor (not part of the game)
* First level
* Fix destruction of railway curve construction sites
* Fix bankruptcy in two-player mode
* Fix demolition of railway curves
* Fix tool selection on lower toolbar

 

Planned features:

 

* Earthquakes (destroying infrastructure, opening new sulphur vents, closing old ones, toggling rock in places where rock is optional)
* More levels (with later levels possibly in a futuristic setting on Io instead of Earth)
* Performance optimization?
* Volcanic eruptions (similar to earthquakes, but affecting larger areas at a time)
* Roller controller support
* Sound or music
* Savegame codes

 

Io-0.10.rom

[AtariBuff]

Philipp, that looks like a pretty interesting strategy game (like all your other releases were). Please let me know when you're ready to put it on the market as I want one copy. Thanks!

[PkK]

Here comes 0.11.

 

Improvements over the previous version:

 

* Warn when low on sulphur
* Roller controller support
* Fix tornado at HQ upgrade construction site
* Use rand() instead of custom PRNG
* Earthquakes
* Volcanic eruptions

 

Planned features for future versions:

 

* More levels (with later levels possibly in a futuristic setting on Io instead of Earth)
* Performance optimization?
* Sound or music
* Savegame codes

* Plant growth

 

Philipp

Io-0.11.rom

Edited February 9, 2017 by PkK

[PkK]

Another update. The highlights would be the 3 different levels and the savegame codes. There also were plenty of bugfixes.

 

List of improvements since 0.11:

 

* Bolder font
* Fix saboteur target selection, tornado start point
* Plant growth
* Fix roller controller support
* Menu debouncing
* Fix simultaneous upgrade of HQs in two-player mode
* Fix effect of volcanic eruptions and earthquakes on HQ of second player
* Fix node upgrade and source node construction at construction site limit
* Queue for construction sites for in-order processing
* Make severe threats (earthquakes, volcanic eruptions) less common than other threats
* Fix restoration of sulphur vents on destruction of sulphur node construction site

* Savegame codes
* Fix late-game buffer-overflow bug
* Increased number of levels to 3
* Fix score calculation

 

Philipp

Io-0.14.rom

Edited May 7, 2017 by PkK

[PkK]

While I still have a few ideas for cheap (in terms of code isze) features to implement, there are also the big items:

 

* Sound

* Music

* Additional levels in a setting on Io, requiring a second graphics set

 

I probably won't be able to fit all of these. Which do you consider to be the most improtant?

 

Philipp

[Swami]

SGM cart too much overhead?

[Pixelboy]

SGM cart too much overhead?

You mean MegaCart. SGM is something else.

[Swami]

You mean MegaCart. SGM is something else.

Well, I suppose I meant is a megacart for the SGM too small of a market to make the production economically practical... I think... ? Although maybe sgm carts are proprietary.

Edited May 16, 2017 by Swami

[digress]

Are you using compression? Helps a lot.

 

Need music & sound for sure.

 

Make it a megacart!

[Pixelboy]

Well, I suppose I meant is a megacart for the SGM too small of a market to make the production economically practical... I think... Although maybe sgm carts are proprietary.

MegaCart and SGM are two ENTIRELY different and distinct things. You can have a game that uses a MegaCart cartridge PCB but doesn't require the SGM, or a standard 32K game that requires the SGM. There is no direct link between the two.

[Swami]

MegaCart and SGM are two ENTIRELY different and distinct things. You can have a game that uses a MegaCart cartridge PCB but doesn't require the SGM, or a standard 32K game that requires the SGM. There is no direct link between the two.

But couldn't you have a megacart that also uses the SGM? Perhaps I use the term megacart too generically to mean a cart with over 32k. I guess I also assume most SGM carts have over 32k of storage for the increased functionality as well as the increased RAM, but perhaps that is not the case. Anyhow, don't wish to hijack the thread, so MegaCart it is.

Edited May 17, 2017 by Swami

[Pixelboy]

But couldn't you have a megacart that also uses the SGM? Perhaps I use the term megacart too generically to mean a cart with over 32k. I guess I also assume most SGM carts have over 32k of storage for the increased functionality as well as the increased RAM, but perhaps that is not the case. Anyhow, don't wish to hijack the thread, so MegaCart it is.

There is no such thing as an "SGM cart". The Super Game Module is an expansion module that plugs into the front expansion port of the ColecoVision, not into the cartridge port.

 

The SGM offers two things: Extra RAM, and an MSX sound chip which can be used in parallel with the Colecovision's native sound chip. That's it. It's up to the software on the game cartridge to use these features, or not.

 

You're not using the term MegaCart "too generically", because that's exactly what it is. It's a ColecoVision cartridge PCB that uses a bankswitching method to support 128K, 256K, 512K or 1024K games. And that does go into the cartridge port, just to be clear.

[Swami]

There is no such thing as an "SGM cart". The Super Game Module is an expansion module that plugs into the front expansion port of the ColecoVision, not into the cartridge port.

 

The SGM offers two things: Extra RAM, and an MSX sound chip which can be used in parallel with the Colecovision's native sound chip. That's it. It's up to the software on the game cartridge to use these features, or not.

 

You're not using the term MegaCart "too generically", because that's exactly what it is. It's a ColecoVision cartridge PCB that uses a bankswitching method to support 128K, 256K, 512K or 1024K games. And that does go into the cartridge port, just to be clear.

 

I think I know what your terminology issue is: OpCode has one product called a MegaCart and another product called a Super Game Module, which Colecovision.dk says uses Super Game Cartridges...but the term megacart has been around since the vic20, at least in common vernacular.

 

From Colecovision.dk:

The Super Game Module = More RAM and better Sound.

The Super Game Cartridge : More advanced games, which include a Digital Save Function.

This new PCB are named ColecoVision Super Game Cartridge or just (SGC).

SGC is powered with a very advanced Bank switching and with Save feature

And in a combination together with the new SGM, is a new cartridge PCB for all new and upcoming Premium SGM games produced from November 2016.

 

I suppose one could split hairs over SGC vs SGM cart, if you wish, but SGM carts and SGM games seem like six of one half-dozen of the other.

 

http://atariage.com/forums/topic/253595-where-do-i-get-a-sgm-cart/

Edited May 17, 2017 by Swami

[Pixelboy]

The SGC (Super Game Cartridge) could be called the "MegaCart Mark II", if you will, and it's only used by Opcode Games. No one else uses it, because Opcode Games has not (and will not) share the schematics of the PCB with anyone else.

 

"Splitting hairs" is definitely required here, because I'm seeing some confusion over terms. It's true that a ColecoVision game cartridge that requires the SGM to function is sometimes called an "SGM cartridge", but I try to avoid this term myself, because it can be misleading.

 

The bottom line is, SGM and MegaCart are two distinct things, and they are related only if the game programmer wants it that way.

[Swami]

The SGC (Super Game Cartridge) could be called the "MegaCart Mark II", if you will, and it's only used by Opcode Games. No one else uses it, because Opcode Games has not (and will not) share the schematics of the PCB with anyone else.

 

"Splitting hairs" is definitely required here, because I'm seeing some confusion over terms. It's true that a ColecoVision game cartridge that requires the SGM to function is sometimes called an "SGM cartridge", but I try to avoid this term myself, because it can be misleading.

 

The bottom line is, SGM and MegaCart are two distinct things, and they are related only if the game programmer wants it that way.

So does that mean Io could be made as a MegaCart for the Colecovision, but not as a high capacity bank switching PCB that can also take advantage of the SGM's features? Or could he use the MegaCart for Io to make use of the SGM's MSX sound and 32K RAM? From an earlier post in your newsletter (from 2012), it sounds like he could use a MegaCart or the AtariMax SD cart with MegaCart ROM for over 32k ROM and could also program to take advantage of SGM features.

 

http://atariage.com/forums/topic/204212-team-pixelboy-news-bulletin-october-18th-2012/page-2

Edited May 17, 2017 by Swami

[Pixelboy]

So does that mean Io could be made as a MegaCart for the Colecovision, but not as a high capacity bank switching PCB that can also take advantage of the SGM's features? Or could he use the MegaCart for Io to make use of the SGM's MSX sound and 32K RAM? From an earlier post in your newsletter (from 2012), it sounds like he could use a MegaCart or the AtariMax SD cart with MegaCart ROM for over 32k ROM and could also program to take advantage of SGM features.

 

http://atariage.com/forums/topic/204212-team-pixelboy-news-bulletin-october-18th-2012/page-2

PkK can make a 32K game that uses the SGM for extra RAM (I doubt he would bother to use the MSX sound chip) or he can make a MegaCart game that uses the SGM, or he can make a MegaCart game that doesn't require the SGM at all. It depends on what his needs are. If his game only requires 1K of RAM, then he doesn't need the SGM.

[PkK]

Compression (RLE and Huffman) is used for graphics data (tiles and sprites). I even have my own Megacart pcb design that I could use (and intend to use for some future projects).

 

But Io was meant to be a 32K game, and I don't want to change that now. I've recently made a few improvements in SDCC to bring Io code size down a bit (SDCC now generates better code for switch statements and some comparisons). I'll see how much I can fit into Io in the summer.

One option I'm currently considering is handling it similar to what I did in SCJ3.

 

* Additional levels (with the second graphics set for Io).

* Some sound (I'm not that good at sound, so these will rather be very short music sequences corresponding to what happens in game)

* Longer Music for the level won / lost / intro screen only (so as to not interfere with the music-like in-game sound).

 

This will also keep the total length of the music short (and thus the required ROM space low).

 

Philipp

 

[digress]

Just a weird thought. but what about double using the graphic data as music data.

 

The background starts as terrain which you had to store anyways

 

Make the music data, store it in what ever format you use. Then use that music data to generate random terrain for each level perhaps with a random start point to read from.

[PkK]

Just a weird thought. but what about double using the graphic data as music data.

 

The background starts as terrain which you had to store anyways

 

Make the music data, store it in what ever format you use. Then use that music data to generate random terrain for each level perhaps with a random start point to read from.

 

The level data is only about 2 bits per tile. So there is not much potential for furhter reduction. Those about 2 bits are needed (the levels should not be fully random - I want lower or higher probabilitires of rocks in some places, want to make sure the sulphur nodes are distributed fairly, etc. Otherwise, Io already uses pseudo-randomness for the levels (via C rand()) to e.g. decide which of the 8 different-looking empty ground tiles is used for a given location.

 

Philipp

[Swami]

Compression (RLE and Huffman) is used for graphics data (tiles and sprites). I even have my own Megacart pcb design that I could use (and intend to use for some future projects).

 

But Io was meant to be a 32K game, and I don't want to change that now. I've recently made a few improvements in SDCC to bring Io code size down a bit (SDCC now generates better code for switch statements and some comparisons). I'll see how much I can fit into Io in the summer.

One option I'm currently considering is handling it similar to what I did in SCJ3.

 

* Additional levels (with the second graphics set for Io).

* Some sound (I'm not that good at sound, so these will rather be very short music sequences corresponding to what happens in game)

* Longer Music for the level won / lost / intro screen only (so as to not interfere with the music-like in-game sound).

 

This will also keep the total length of the music short (and thus the required ROM space low).

 

Philipp

 

More new classic carts to play is great, too. It looks great so far. Can't wait to see the final result.

[opcode]

When I was creating the Super Game Module, I envisioned it to be as close to the planned Coleco Industries SGM as possible, and some early designs used a floppy drive with games in floppy disks. Then the floppy disk was replaced with some internal save memory, but that wasn't very flexible, because it would require memory management to eventually allow the user to remove content in order to make space for new content. So the perfect solution was to add a "save memory" to the cartridge itself, just like the original SGM could save to the game tapes. So that became the Super Game Cartridge.

However, since I stayed away for a couple of years, the Super Game Cartridge didn't get released until last year. SGC are also much more flexible in terms of bank switching, but that benefit is harder to measure by the end user.