A lengthy history of The Singularity Trap, a cheap little "niche" game you are probably not interested in and almost certainly have never heard of. PART 3 – techy stuff Let's take a closer look at that layout in the upper section. We have the name of the game with the name of this particular war underneath it. Over to the right are all the other players. Way to the left is the current player. The player names showing here can be changed but just remain as the colors everywhere else. Directly above the map is the current level being displayed. When the mouse is over the map the Pointer Coordinates fill in as you move (ok, the image map of circles leaves tiny bits at the points of the hexes not covered). Over to the right are the current movement phase, that inverted brown X (this exits to the lobby page of the game, equivalent to looking up from the gameboard), and current Economic Points. Then we have the map itself, the levels panel, and the actions panel.

At the bottom we have allies and enemies, a blank space that will fill in if any orders are stored (keeping count), and a blank button that was originally intended for an exit button but got stolen by another function (which is why the exit button got crammed in up at the top later). The map itself and the levels panel are part of the main page, while the actions panel is an insert that has parts rewritten by the main page. Down below this in the paperwork section the flee list shows ships in mobile, stationary, and (in any orders have been transmitted) in transit groupings. A lot of dynamic elements involved here along with the static info grabbed from the database. Stationary ships will not appear in the select list for move orders. If you select a civilian ship the Slip option vanishes. Military have no Jump option and the final move vector appears only if Slip is chosen first.

At the time all the rules were in a text file that kept getting modified but the movement rules were final including that encountering an enemy ship at the end of any move segment would terminate further movement when move orders were being executed. A whole slew of mouseovers, mouseouts, onclicks, oncontextmenus, onchanges and such later, including some error correction for the vector functions, and we were ready to tackle the submit to the database portion. On my computer – it had Windows 7 at that time, ZoneAlarm, and Malwarebytes running – Apache ran slow and I was running into delays of several seconds during submit and then return so I made a couple of moving gifs to overlay the map with Transmitting or Acknowledging while this was going on. The transmit to page just processed stuff and looped back to the map page. I had figured out that at least several sections could use the same page with different inserts for the action panel. After all moves had been ordered by all players, movement was processed and the Navigation log displayed. The combat phase would begin after all logs were reviewed by the players (including any blank logs).

Now the rest of the paperwork section was completed. Various groupings of ships in the fleet listing were used for the various phases. The method used here eliminated ships being repaired from showing as options to be hidden – the old game and the human both agreed that was a good thing and did not need to be fixed and it became part of the rules. The map was made slightly interactive with the build action panel so clicking on an owned planet would select that planet in the select field on the action panel. The final move sequence was decided upon around now.

I did the Movement first because it was hard and involved and if I had any sense would have modified the database setup instead of jumping through hoops to make it work as it was, then looped back to do the Maintenance and Construction because those action panels would fit into the same space on the map page (and only Repair was a little bit complicated).

Combat still looks like a brand new page since we can have several going on at the same time (and we need to figure out the actual combat rules) so the old game and I leapt boldly into action on the EcoPolitical part instead. Alliance settings were as simple as expected. The terraforming decided to fight back from the game design side. The original plan – which allowed to terraform in either direction and was optional - still had furious fancies hiding out in it. After the dust settled it was no longer optional, semi-automatic, and only offered a choice of color where there was a choice to be made. Best of all we could do it as an action panel.

When you transmit alliance settings it is always a transmit and finish so the button stayed red. There might be more terraforming choices so that transmit button stayed yellow. You have probably noticed the green/yellow/red traffic light type color scheme the buttons adopted.

Somewhere in my brain the whole allies getting to see your locations but enemies cannot thing was generating a growing suspicion that a fundamental change in the game had happened, but it was deep in the brain and I am pretty sure the old game was sitting on top of it to keep me moving blindly forward. So, how to handle combat that might involve 6 sides with overlapping alliances? The combat charts from the old game were not much help at all.

Those old charts were an attempt to both determine hit/miss and what damage in a single chart. But why a chart anyway? Using attacker/(attacker+defender) = to hit chance is mighty simple. Allocating damage randomly to remaining nodes after the armor is gone is also simple in concept. If the system node gets hit the ship goes dark. If weapons+drive=0 the ship is destroyed. All damage is applied for the round so a ship can go dark and still be destroyed or take additional damage in that same combat round. But how to handle overlapping alliances? Finally my head turned around backwards and looked at is not as your firepower but your enemies firepower. You defend against the total firepower of all of your enemies with the total firepower of the attacker's enemies and attack against the total firepower of your enemies with all the firepower of your target's enemies. (defender enemies)/(defender enemies+attacker enemies) In case I didn't mention it before, I was attempting to use the database sparingly. Used the file system for the images and some temporary data files (navigation reports are an example). Since the info for combat is going to be stored then sequence processed after all the orders are in, temporary files are made and added to in order to record the attacker, target, number of shots, and odds as attack orders are submitted.

Those same files get rewritten as combat reports when the shots are processed and damage allocated. There was a lot of flipflop on the combat rounds. Some players will not be involved in combat – or no longer involved. After a lot of testing and changing things we settled on this.

Those allies can be a help but they can also get underfoot and in the way. I mean, you and your ally swoop in and then find out neither gets to own it. That and revealed information is really starting to flesh out the whole alliances thing. Good thing they can only change sides at the very end of a turn so you get to build again before they shaft you. Not that pinning forces in place isn't a shaft in itself. Did a whole bunch of testing. Tried to do full tests. Tested with players in various sequences. Made the mistake of testing in just one section before moving on to the next. Noticed that waiting on other players to enter their orders before you could start typing was a real drag pass-and-play with more than a couple players. Maybe at least having the pages auto-reload (pass-and-play with several browser tabs) at least the next stage will already be waiting for you when it gets passed to you. It will also imitate online players checking things all out of any sort of sequence. This was when that blank black button got stolen. But I still needed an exit button so squeezed in the brown inverted X. It went to a basic page with the name yourself and resign options and a link back into the game. Lest you think this beginning to approach some sort of logical method in game development, finally, I should point out that the lobby page was originally intended to be a page shared by all players from which you would enter a game or resign from a game. Logins to make online distant play prevent cheating had not opened up its eyes and said anything yet. So I made the auto-reload function. Before I tested it I also played back and forth with the very beginning of the game to decide on starting economic points. Made the initial game goals/blurb/scenerio statement.

This might be a good spot to end this section. The farce will continue in Part 4, but we will end Part 3 here. As always, feel free to go look at things at http://thesingularitytrap.com Guess what comes next.