I wanted to have two DS communicate. Not Wifi per se, as they are not communicating via a router or Internet, but known in the indie DS community as NiFi (direct DS to DS).

The base communication commands are quite simple and part of the Wifi_RawTxFrame functions in the dswifi libs. The complexity is in creating the application's infrastructure beyond the base functions in the indie dev kit.

Wrote a very quick short program that takes input from one DS then passing it to the other DS; it was a thrill to move a block on the DS and its movement is mirrored on the other one. From that beginning, I progressed onwards to code supposedly a simple application, the classic game "Pong".

The game worked well except for a minor complication of random dropped communication packets. The intermittent loses were smoothed out (movement extrapolated from last known position to new one), at worst it appears as a slight stutter.

Added more game elements such as scoring and replace the blocks with sprites and tile background. A start screen was created, to allow mutual entry to the game, basically to setup communication between the machines.

Some gameplay changes. The paddles are only controlled horizontally, and not by the stylus, but after a successful hit the paddle will rise by a paddle height (maximum to 2/3 of the screen height) and its size shrinks. The speed of the ball is similiarly increased.

Makes the game a bit more challenging while still maintaining the spirit of the original one.

The Star Trek franchise has been a curse as a game theme. The reason is mostly due to the inability of the format to compete with each fan's unique view of the Trek universe, hence unrealistic expectations. A better way is to assist their imagination than compete with it; this is achieved by playing as a training session, just showing the starship's instrumentation.

This minimalistic approach would allow the players to imagine the battle in their mind's eyes, beside other advantages such as simplification of my part and less strain on the DS resources.

Though this was another project in DS-to-DS play, it was not as stringent in the communication aspect like the "Pong" game. Any problem between DS's could more easily be resolved behind the scene than the glaring real-time openness of ball and paddles in the previous game.

A solo training choice is created with some of these opponents.

However the intelligences of these enemies
are, to say the least, stupid at the moment.

The design focus was with DS-to-DS play.

One player must hold (create) a session so others can join. This does not mean it is playing the role as a server, a DS does not have the power to truly host. Rather it is a central meeting point, it assign to each DS's a name (or tag) and makes them known to all participating players, polling sequences and wildcard command names.

Though it shows four players slot. Only tried it with two players, though designed it for more. Click "OK" to start.

click on the box of one to join.

Now that mutual communication has been established, please select which starship to command. Only two ships for now. By the way, if Solo Training was selected, this would be the first screen.

The tactical screen is where external interaction occurs. The command buttons, tabs, indicators and guages on the touch screen are self evident (I hope) of their functions.

The target lock guage shows the target and its strength, the word (lock) will vary from blinks to solid according to the lock status; the better the lock, more damage.

Similiarly an indicator below your ship, blinks to solid, showing the enemy's weapon lock and potential damage (use the counter-measure button or evasive manuevers to break off).

Movement is by the thumbwheel; turns and directions have a progressive and inertia feel. Note, it is the background that convey the movement, the "grid" is static.

The upper screen is compose of the larger closeup tactical battle view and a smaller enemy locator in the corner. The hunting of the enemy is really via the smaller directional indicator.

The exact position is not a major factor for DS-to-DS play to score damages. The target lock is strictly DS controlled, its effectiveness is influenced on positions AND certain variables in the "system" screens.

As such, unless you played both DS's side by side and looking at each others screens, you may not notice on rare occasions that things are not exactly right due to the rare communication packet drops. This minor difference should not hinder enjoyment as other factors contribute to the fight and these rare faults could be explained or passes away. If everything does becomes horrendously way off, some distractions may be invoked to get the communication back in sync without breaking the mood (see further down).

Some major Ship Systems that will need occasional review to ensure performance, also survival.

Initially everything on top display indicates the status and available resources, bottom display, are full. As the strain of battle rages and damages occur, it will be upto the player to manage what remaining resources to drag into the systems needed.

These systems have interactions amongst each other and have consequences, for example a very low COMMAND and COMPUTER will impact the target lock effectiveness. No LIFE SUPPORT, crew will shortly die (game over). So a careful balancing and micro management of resources is required. But more continuous damage will mean less resources.

However be quick about it because outside of the Tactical screen, you are dead in space and any enemy will enjoy a sitting duck.

Repair the engines which is the main power; bypass,rewire and try not to cross circuit anything. Without repairs, the ship is a brick.

If you do mess up, a new pattern will appear after a slight delay, and try again. Not meant to be complicated just take up time, while the enemy blast you or get away.

By the way, if DS communication is out of sync...suddenly every player will have engine problems. This time allows communication to be corrected.

Any lull in action would also be an opportunity to verify player's communication. Sometime just the act of the "ALERT" messages is enough.

In this section, the player may Warp into a particular sector in space but only to an adjacent one per jump. Only six sectors in the demo. Allows for an escape and hunt. Each sector has a different feel (background).

There is a delay per jump and the time between jumps depending on the ship's condition.

The major obstacle to get this game to production...approval from Paramount for the Star Trek rights. Really, the Trek universe would be the selling point. Now with that out of the way, some game ideas to fill this into production quality.

Right off hand, have more ships and races to command, with unique flight models (handling and strengths). The above two ships are exactly the same except for the stylized theme. So no complaint about one is better than the other or mismatch, it is an illusion (or fan delusion).

But in reality, DS-to-DS play should not be a prime motivation to keep playing (hence sell/buy). Rather it should be about exploration. Even the Klingons gather information, but unlike the Federation wanting to become friends, rather gain intelligence for potential conquering.

The revised Solo Training section will be a major seller for any production version. The mission is the accumulation of the Trek Universe knowledge sprinkled through a huge region, along the way encounter with the strange, also conflicts and quests.