UPDATE -- 0.53 alpha-ish

Ok, update time!!
This game took a bit of a hiatus, as many of my projects do from time to time because of real life, skill building, and other stuff.
However, I did some code reorganization at the start of the summer, then set out on an endeavor to have a working demo of basic combat (single player) by the end of the summer.

Attached is the current pre-demo release. This version is functional but has no AI or rendering engine yet. That is what I'm working on now... 3d rendering, weapons and targeting, then wrapping everything up, optimizing, and releasing. That being said, I'll talk about some of the cool features already implemented:

1. Ship Status Icon
At the lower, left side of the screen there is an icon that shows your ship and your shields. As your ship takes damage, you'll notice the shields first. They start off electric blue, then degrade to yellow, then to red. Additionally, within the ship itself, which is normally grey, sections of the ship will turn red as systems are damaged. Hull integrity causes a small filled red circle when it reaches <50% in the saucer that gets larger when hull integrity fails. In addition to that, the nacelles turn red when the warp drive is below 50%, the aft of the ship turns red when impulse, life support, or the warp core fall below 50%. As of now, this icon is locked to an Enterprise-ish shape, as are the indicators. If/when I allow icons to be customized, I'll have to modify this to match.

2. Warp Core Failure
When the warp core system is damaged to less than 25% health, the program begins attempting to trigger a warp core breach. The odds of a core breach are 1 / system health * 10. So, for a warp core at 24% health, the odds of a breach occurring are 1/240. If the warp core is at 10% health, the odds become 1/100. Once a breach is successfully trigged, a timer begins. You get 1000 game cycles to avert the breach or your ship is destroyed. I have yet to clock how long that actually is. You can avert the breach by (1) Repairing the warp core to above 50% health (see Repair), or (2) Pressing the [Del] key to eject the warp core. The ejection occurs and spawns a critical warp core behind your ship, on a slow trajectory moving backwards (relative to you). Doing so immediately stops all power flow to your ship, meaning if you have no auxiliary power module installed or no warp core to refill the slot with, you'll lose power fast! The counter continues from whatever it was at when you ejected it, and then explodes in a MASSIVE detonation that can significantly damage your ship if you're too close.

3. Power, Inventory, Core Breach, Life Support Alerts
When any one of these four things need attention, there is an alert dedicated to them. The power icon appears when any module is unable to fulfill its power requirements, meaning that your power generation is no longer effective enough to keep your ship powered. This means that it is time to (1) Bring unessential systems offline, (2) Repair your warp core (the health of your core determines your ship's power output), or (3) Switch to an auxiliary power module (if installed).
The Inventory status alert appears when an active torpedo module has exhausted it's supply of selected torpedoes (unimplemented).
The core breach alert appears when a warp core breach has been triggered, and will disappear if the core is repaired or ejected.
The life support alert appears when the life support system hits 0% health or is turned offline. If life support is not repaired and brought back online within 2000 game cycles, your crew dies and you lose.

4. Repairing Your Ship
Any module may be repaired, including shields and hull integrity. Repairing a module stops it from being supplied power, stops it from functioning, and expends a lot of power to repair it. Every 5 game cycles, the module draws its current power default and gives itself 1 unit of health. For a starting ship, this means that it takes a module 250 game cycles to fully repair to 50 health, and costs 250 power to do so.
* A repairing module is treated as OFFLINE. This means that if you are repairing your shields, they will not function. If you're repairing your hull integrity, it will not give you extra damage protection. If you are repairing your warp core, it will stop generating power. The only modules that will function while being repaired are your engines (warp drive/impulse) and your weapon systems.*

5. Damage Calculation
Damage in game occurs as two factors: shield damage and hull damage. Phasers or other energy weapons deal more damage to your shields than to your hull, while torpedoes will deal more damage to your hull than your shields. Notable exceptions will be the Narada torpedoes that will deal staggering damage regardless and disruptor phasers, which will be somewhat balanced against both.
First, the current health and current power configuration of your shields are calculated and multiplied by the shield's damage resistance value. This is the amount of damage that your shield is capable of repelling at 100% health and 100% power. To start, this number is 5. Most weapons you'll encounter at first will deal 1-3 damage. If your shields are at, for example, 60% health, they will be capable of blocking only 3 damage. If you were to then set your shields to use 200% power, they would become able to block 6 damage. In this way, you can boost your systems to help you out in combat, but at a cost (see Boosting).
The shield damage value of the weapon is subtracted from the shield's health, resulting in shield damage. The calculated damage resistance value is subtracted from the weapon's hull damage. If this value becomes 0 or less at any time, we stop calculating damage.
We then read out the damage resistance value of your hull integrity module. If hull integrity is 50% or higher, that number is subtracted from the weapon damage. If hull integrity is <50% but above 0%, the damage resistance becomes 0. If hull integrity is 0%, the module's damage resistance is added to the incoming damage. This emulates a damaged hull becoming less effective at protecting the interior from damage. Any remaining damage is applied to a system currently chosen at random, but eventually to be chosen based on the direction of the incoming weapon compared to the direction of your ship, allowing you to target specific areas.

6. Boosting Systems
Any system, except the warp core, may be boosted to allow it to perform more effectively. Here's a list of what boosting a generic system will do:
Shields: Increase damage resistance
Hull integrity: increase damage resistance
Life Support: unable to be altered
Warp Core: unable to be altered
Warp Drive: Increases maximum attainable warp speed (to a max of +5 speed)
Impulse Drive: Increases maximum attainable impulse speed (to a max of +2 speed)
Sensors: Increases maximum sensor range/targeting range
Phasers: Increases phaser damage
Torpedoes: Increases torpedo speed
Transporters: Increases transporter range
* A boosted system will use power at a faster rate than it is being recharged, and eventually run out of power and stop working. Use boosting sparingly. *

7. Warp/Impulse Speeds
The ship has 4 average impulse speeds:
1 field / cycle = 1/4 impulse
2 fields / cycle = half impulse
3 fields / cycle = 3/4 impulse
4 fields / cycle = full impulse
certain ship types and a boosted impulse module will allow additional speeds < 10.
A damaged impulse module reduces the maximum impulse speed.
The ship has warp factors 1-9, with speeds in between the major warp factors. Each warp factor increases the speed by it's factor.
Warp 1 = 10 fields / cycle
Warp 2 = 12 fields / cycle
Warp 3 = 15 fields / cycle
Warp 4 = 19 fields / cycle
Warp 5 = 24 fields / cycle
Warp 6 = 30 fields / cycle
Warp 7 = 37 fields / cycle
Warp 8 = 45 fields / cycle
Warp 9 = 54 fields / cycle
boosted warp core max = 59 fields / cycle
Intermediary warp factors supported, for example, 16 fields / cycle equals Warp 3.5.
A damaged Warp Drive module decreases the maximum speed to a minimum of 10 (warp 1) unless the module is completely destroyed.

I've been talking about it for a while. Asking questions about how to do this or that. But without any real progress.

Scroll down for a question I have about ship/terrain assets.

Well as of the past week or so, that has changed. I sat down, turned off my Minecraft (with great internal suffering) and got to work. Over the past week, I succeeded in creating the shields, the major non-combat systems, damage reception, power control, and more.

At this point in time, there is no networking implemented and the file is quite large (~15kb). Much of this is due to graphics and AI calculations which, when networking is implemented will no longer be present. The intent is also to hold graphics server-side and send the relevant sprites to the calc during runtime, which will be saved in a temporary assets file. Also, as Kerm told me that CALCnet will likely not be a thing for the CE due to differences in network protocol, I'll probably use the existing USB protocol on the CE with a computer side program to send data to the hub, which would have the ability to interact with connected CE's and CALCnet, allowing the color and monochromes to play on one server. I'll also open source this when done to allow it to be ported to the CSE.

But more on that later. I have very little left to do before I can release a demo. Basically just AI ship control, player ship control, rendering the viewscreen, and firing. In the scope of what I've done already, that shouldn't take too long.

Now, feast your eyes on some screenshots:









The Question:

This game is played in a virtual 3D world. The map objects and ships are technically 3D. My question is, would it be better, both in terms of rendering speed and data size, to create several versions of each sprite, to view the object from different angles, or to create full 3D models for the ships and the spherical map objects (the irregular objects will be rendered differently). For full 3D, I could make 16x16x16 models for each item, leading to an overhead of 4096 bytes per object, which if it's in an external assets file on the CE isn't a major issue. When this game eventually gets backwards-ported to the monochrome calcs, we'd be talking about 512 bytes per object.

If the common consensus is the latter (3d models), is there someone here who has experience making them?

Ok, some changes.

1. A complete rework the GUI. The High and Low score is moved to the left half of the top of the screen, the combo score and bonus points are moved into an inset in that top roll.

2. The combo listing is moved down, and the selected combo box is inverted. Already used combos are rendered with an X across them. When hovered over, the scored combo for that item is rendered, rather than the point value for the current roll.

3. The last box on the top row now sums the points for the first 6.

4. Die are reset after a roll. Default is a ? symbol. Screenshot and version enclosed.

Ok, update.

- as I believe this version is stable, the b has been removed from the version string
- getKey^r switched to a getCSC loop (getKey)
- roll key changed to [2nd]. Help Screen updated to reflect this.
- Hold on Roll 0 bug fixed
- Multiple Yahtzees changed to a Yahtzee Bonus

Screenshot updated has some graphical glitches I think root in jStified, since they do not occur at all on my calculator. I'll poke Kerm and see what he has to say.

Fixes for everything except the [2nd] + [ON] leak. GUI improvement. I'm waiting for Runer, so I can ask him about some of the other Axe keyscanning options.

I would just use a loop with _GetCSC, in asm:
waitKey:
bcall(_GetCSC)
or a
jr z,waitKey

I tested the game again and it seems to work pretty well, it'd be nice to be able to see all the sets at once. Also, when you pick your points after rolling, the dice aren't rolled again, you can choose to hold dice from the previous roll. I'm not sure what exactly happened, but i held dice until i eventually got a Yahtzee, and the second time i choose Yahtzee it wouldn't let me roll anymore, all i could do was press enter to get more points (see screenshot). I just tried it again and the same thing happened. Getting two Yahtzees (or maybe getting a Yahtzee after holding all five cards?) prevents you from being able to roll the dice anymore.

the game is Axe, not asm, so I can't choose. I used getKey^r because it waits for a key, so I save a loop.

The way it works is, if you score more than one Yahtzee, you score again against an additional combo before rolling again.

Lastly, I found the thing with Holding before the first roll myself on a playthrough and fixed it. That was indeed a bug, or moreover an oversight on my part. Thanks. I have improved the UI, but before spending time on it, I wanted to ensure the fundamentals work.

As for seeing all the sets on screen, in the new GUI i might have room for it, but I did want to put some of the key bindings right on the main screen. So I'll ask this here, how many people would vastly prefer all combo's shown on screen? Or would a key list be preferred?

Here is RC 1 of the Yahtzee Axe game. Please test and report any bugs/GUI glitches found here