Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
As the mostly-under-wraps progress on Star Trek multiplayer nears the 50% mark, I thought I'd share some of the new planned features for the game, as well as share what is done.

First off, the game's source code is being hosted privately, on my private web server. Access is via ssh. Anyone who wants to help with what's left can comment the topic and I'll PM you the URL and password to the repo.



Shields

I have slightly revised the way the shields work. Originally, it was intended that weapons have an energy damage rating and a solids damage rating, for damage to shields and ship, respectively.

The new system uses a payload rating for a weapon and a dispersal rating for a shield. The shield's current dispersal rating is equal to its max rating multiplied by its current percentage health. For example, imagine a weapon with a payload of 10 is fired at a shield with dispersal rating of 10, at 100%. The weapon impact damage is reduced as such 10 - (10 * 100%) which equals 0, and the shield health is reduced by 10. The next time the damage occurs at 10 - (10 * 90%), which equals 1. So 1 damage is dealt to the ship, and full 10 damage to the shields. **If a weapon's payload is less than the shield can block, no damage will be dealt, but shields will not gain health (sorry :p). If the weapon's payload exceeds the shield's blocking ability, even at 100%, the weapon will still break through.

You will have the ability to install more than one shield module onto your ship. One module will deplete its health, and then be replaced by another. In this case, however, as long as you have one other active shield module that is online, no damage will break through, even if the current module's percentage of health drops.

Sensors and Multi-targetting

The ability to install more than one weapon module will also enable you target your ship's weapons at either one target for combined damage, or to target each module at a different ship. Sensors will enable this by displaying three different targeting interfaces. Press a key to toggle between single target and spread target.

AI Borg Cubes

In keeping with the series, the server will control several Borg cubes with powerful weapons and shielding, designed to be attacked in groups, or fled from if you can run. They will be occasionally spawned in some distance away from an online player and will pursue that player or whatever player moves closest.

Stealth Tech

You can purchase (using points) and equip stealth tech modules. Stealth tech includes: (1) cloaking devices, a level 1 cloak automatically shuts off if you fire, a level 2 does not, and the cloak drops if the module looses health, (2) EMP pulses, which knocks all power systems (warp and impulse) offline for a time, which knocks all systems offline for just as long, (3) viruses, which damage a targeted ship. You may also emit a scrambling signal, which stops all sensors in a certain range from working. Lastly, you may scan another ship to gain info about where their systems are, their shield modulations, etc.




Currently done in the game is the opening menus, most of the CALCnet routines. Still to be done, rendering and the hub. I should have a beta done in a few months.
Bump + more progress

Just completed the speed changing routines, and most of the keypress detection.

Left to go:

- system interfacing: GUIs to display ship info, status, power config, etc.
- calculating new change in position per axis, given speed and vertical/horiz angles.
- displaying map data on screen/sensors
- the hub

- and a few small other things


Anyone who has time and would like to contribute any amount of coding/sprites to this project may comment this topic or PM me. Project shared via git over ssh (pub key authentication).

Also, anyone willing to fork this project into a TI-84+ CSE version may also comment here and I'll let you into the repo as well.
As some of you know and many more don't, Slender hasn't been the only project I've been working on of late. I've been actually brainstorming ideas for my own original Slender series, and simultaneously working on Star Trek. This time, I've decided to bring the gCn server online first with basic functionality and then bring the client together, so I can test it as I go. Monkey has kindly offered to set me up with a skeleton and assist conceptually as my learning of socket programming advances.

The gCn server will be hosted on my own private server (at least for now). At my request, Deep Thought pointed a ClrHome subdomain to it. :p

In addition, I'm creating a control panel (http://sthub.clrhome.org) that will allow you to administrate your user account for the game from the computer as well. When completed, this page will allow you to change your username, password, and email address, as well as view (but not change) the server configuration file. Admins will be able to monitor and alter the users database and the loaded objects database (which is essentially the gamestate) and the server config file. It will also let them pass commands to the game server, Minecraft style, and also let them stop and start the server.

FYI: This project is my first EVER attempt at using MySQL, and so far, it is going very well!!

So now, I need advice. Obviously a MySQL table for username, calc id, password, admin status, and email works well. But for the objects database (which reflects the gamestate), where things will constantly be changing and moving... is a MySQL table the best option to use?
Wow, its been a while since I've done anything in this thread, as real life and some other projects have been in the way, and progress has been, and will likely continue to be, slow (hence why I've opened the floor to help).

The sad news is Star Trek will no longer be coming to the TI-83+/84+, because my calculator has broken and thus I can no longer sufficiently test (unless someone can inform me of a Cn2 capable emulator).

The upside is, once I learn relearn assembly for the ez80 enough to program at length, I'll be restarting this as a CE project, and then I'll see about porting it back to the z80, or letting someone else fork it.


On a related note, I've hit a dilemma. Many objects you will find in space are spheres, like planets, stars, and black holes. However, nebulae and asteroid fields and a few other things are not round. Thus, using the simple [x-coord, y-coord, radius] data block will not be sufficient, and I definitely do not want to list out every single position of a possibly 50,000+ radius-unit large environment. Also, just telling the server that this object is a "random-shape" object would cause it to render differently for each user, which is also undesirable.

Does anyone have ideas for viable alternatives for a random-shape object looking the same for every client, with minimal in-server-memory data?
Sorry to hear that you won't be finishing Star Trek for the monochome calculators; will you consider publishing the code you have so far so we can give you constructive criticism and feedback on it, at least?

Regarding your last question in the topic, procedural generation is probably the way to go. For this, you pick a random seed, and your algorithm repeatedly calls the equivalent of rand()/randInt/other deterministic random function that returns the same sequence of pseudorandom numbers on each client if seeded from the same seed. As a simple example, if you wanted to generate a 2D star field, you could seed the random number generator from the same seed on each client, then use rand() twice per star to get (x, y) coordinates. The result would be the same on all clients.

You also may want to deal with collisions; there are several well-understood techniques for computing collisions between irregular 3D objects in 3D space. According to elfprince13, who is sitting next to me at the moment, using a hierarchy of bounding volumes may be your best option. For example, you would enclose the entire planet and ship in a bounding cuboid, then if it appears there's a collision, you can step down the hierarchy and look at bounding volumes around separate smaller pieces of each model.
KermMartian wrote:
Sorry to hear that you won't be finishing Star Trek for the monochome calculators; will you consider publishing the code you have so far so we can give you constructive criticism and feedback on it, at least?


I do believe the code is open source already, hosted on a git repository on my webserver. It uses SSH protocol to communicate with the server. The link to the repository is:

Code:
git@acagliano.no-ip.biz:/home/git/repos/startrekmp.git

Access is based on SSH keys, and to this end, I am providing a mediafire link to an allowed, universal SSH private keyfile, which has access only to git. You can download it and use it to access the repo. If this happens to not work, let me know. (ps, git@ on my server is, of course, restricted to only git commands, and scp)
http://www.mediafire.com/download/97e7wqq2j73c0zn/git.universal_rsa

KermMartian wrote:
Regarding your last question in the topic, procedural generation is probably the way to go. For this, you pick a random seed, and your algorithm repeatedly calls the equivalent of rand()/randInt/other deterministic random function that returns the same sequence of pseudorandom numbers on each client if seeded from the same seed. As a simple example, if you wanted to generate a 2D star field, you could seed the random number generator from the same seed on each client, then use rand() twice per star to get (x, y) coordinates. The result would be the same on all clients.

You also may want to deal with collisions; there are several well-understood techniques for computing collisions between irregular 3D objects in 3D space. According to elfprince13, who is sitting next to me at the moment, using a hierarchy of bounding volumes may be your best option. For example, you would enclose the entire planet and ship in a bounding cuboid, then if it appears there's a collision, you can step down the hierarchy and look at bounding volumes around separate smaller pieces of each model.


I understood your entire first paragraph. Didn't quite think of using a seed in a RNG. That could solve some of my other issues too.

As for the second paragraph, a lot of collisions will be, for lack of a better term, interpolated collisions. Like a weapon fired might jump enough to carry it past a ship or another weapon, and I'll have to interpolate if a collision occurred. Does the model you propose address issues like this? Perhaps I'm not fully understanding what you suggest?

Ps: sorry about the edits. The quote tags were fighting with me
First order of business -- a remade splash screen. Feast your eyes



1. In other news, tried to assemble a version of the program that just rendered the splash screen, waited for a key, then quit. The DCS assembler gave me the following output: Shouldn't it be looking for the include files in the tasm/ directory, by default? The ti83pce.inc file is in asm/tasm/ and the images.asm file is in asm/source/.

Code:
----------------------------------
   Doors CS Assembler/Compiler
          Version 2.0L
     Written by Kerm Martian
     http://www.Cemetech.net
----------------------------------
----- Assembling startrek for the TI-83/84 Plus...
./compile.sh: line 16: ${a^^}: bad substitution
Brass Z80 Assembler 1.0.4.11 - Ben Ryves 2005-2006
--------------------------------------------------
Assembling...
Error: Could not open file /Users/acagliano/Desktop/ClrHome stuff/downloads/dcs7/dcs_sdk/asm/ti83pce.inc
Error: Error in file 'ti83pce.inc' [zztemp.asm:4]
Error: Could not evaluate 'userMem-2' (Invalid number). [zztemp.asm:6]
Error: Instruction '_clrlcdfull' not understood. [zztemp.asm:18]
Error: Label 'rcall' already defined. [zztemp.asm:33]
Error: Instruction '_clearvram' not understood. [zztemp.asm:33]
Error: Label 'rcall' already defined. [zztemp.asm:41]
Error: Instruction '_getkey' not understood. [zztemp.asm:41]
Error: Label 'rcall' already defined. [zztemp.asm:42]
Error: Instruction '_clearvram' not understood. [zztemp.asm:42]
Error: Label 'rcall' already defined. [zztemp.asm:43]
Error: Instruction '_clrlcdfull' not understood. [zztemp.asm:43]
Error: Could not open file /Users/acagliano/Desktop/ClrHome stuff/downloads/dcs7/dcs_sdk/asm/images.asm
Error: Error in file 'images.asm' [zztemp.asm:46]
Pass 1 complete. (212ms).
Pass 1 failed, pass 2 therefore skipped.
Errors: 14, Warnings: 0.
Build failed.
----- There were errors.


After that, I tried to use spasm and got this:

Code:
dyld: Library not loaded: /usr/local/lib/libgmp.10.dylib
  Referenced from: /Users/acagliano/Desktop/assembler/asm/./spasm
  Reason: image not found
Trace/BPT trap: 5

Problems, problems, problems.

2. Can someone direct me to the best lossless compression algorithm that can be used for this game, as well as an associated decompressor? Is pucrunch still recommended?
ACagliano wrote:
First order of business -- a remade splash screen. Feast your eyes



1. In other news, tried to assemble a version of the program that just rendered the splash screen, waited for a key, then quit. The DCS assembler gave me the following output: Shouldn't it be looking for the include files in the tasm/ directory, by default? The ti83pce.inc file is in asm/tasm/ and the images.asm file is in asm/source/.

After that, I tried to use spasm and got this:
...
Problems, problems, problems.

2. Can someone direct me to the best lossless compression algorithm that can be used for this game, as well as an associated decompressor? Is pucrunch still recommended?


1. What environment are you using? Looks like you're running the .sh scripts under Windows, probably with Git Bash or Cygwin, which is of course a bad idea since it just doesn't play well.

2. There's no "best," it depends on how much work you want to spend on writing a decompressor. I'd go with LZ77, or even a simple run-length encoding will do.

3. Why are you hosting Git on your own server? Just host it on GitHub, it's much easier to browse, and it's secure.

4. This animation is a bit fast but it should show you what Kerm is talking about. It's a tree-based algorithm; I think my implementation is a bit naive. Essentially, to detect a collision, you check the boundaries of your object against another object using progressively accurate bounding boxes created through subdivision. In 3D, this is an octree, but in 2D, it's a quadtree.


In the animation, we see Object 1 failing the test because at n3/n4 (depending on how it's calculated), it was not in the quadrant closest to the stick. However, Object 2 succeeds because one of its vertices is on the quadrant closest to the stick, even at the maximum iteration which we have defined to be 6.

In retrospect, I don't think this algorithm works very well for more complex objects. But I think it can be adapted.
1. I'm running on OSX.

3. I suppose I could put it on github. I just went with my own bc GitHub limits contributors.

4. Oh ok. I understand that explanation Smile thanks
Oh, those paths threw me off so much.. Just a simple /c/ or /cygdrive/c/ was all it was missing for my suspicions to be correct.
oldmud0 wrote:
Oh, those paths threw me off so much.. Just a simple /c/ or /cygdrive/c/ was all it was missing for my suspicions to be correct.


haha nah, not Windows. But not as good as pure Linux, it seems. Which is strange bc it has worked for me in the past, and I can't see why simply supplying a different include file should make it not work. I'm considering redownloading the package and seeing if that fixes things. I'll edit this to indicate.
At long last, finally got around to this. This link is the zipped source to the incomplete Star Trek MP client, for the monochrome calculators. As the USB port on mine died, leaving me unable to test calcnet without a Cn2-capable emulator, I'm releasing the source for the monochrome version and transitioning my own work to bringing this game to the CE, once Calcnet functions for it.

http://www.mediafire.com/download/7f4mmeaqrqfui1y/startrekmp.zip
Is this game multiplayer only? Or is there a singleplayer version as well? or is it included?
Caleb_J wrote:
Is this game multiplayer only? Or is there a singleplayer version as well? or is it included?

The default will be server mode. It is my plan to have singleplayer missions available, like bringing things to planets or fighting AI controlled entities while on the server, in case very few players are available. I didn't plan to have an offline (true singleplayer) mode, as tifreak is working on something like that. The BETA, when it comes out, will be a true singleplayer game, but that will only be to test the combat functions.

Not sure what the status was when last I posted, but the game is being made in C, using the libs by Mateo and hopefully the 3d engine by TheMachine (pending permission). I'm currently working on setting up the memory areas for the ships' systems, and saving/recalling from save files. Whenever CALCnet for the CE becomes a thing, savefiles will become a fallback for if online saving fails. Current progress:

- the game properly sets up an allocated area of memory for an array of structures, which will hold data on ship systems. Each structure is considered a system (module), some of which may be configured.
- Currently unused routines to initialize, modify, and delete modules, and to retrieve module field values. These will form the basis of the LCARS system when it is implemented.

Now for the main point of my post... suggestions. It is my plan to create an achievement system, similar to Minecraft's. So far, I have the following achievements:
1. No Damage: Defeat an enemy without taking structure or system damage (excludes shields)
2. No Shot: Defeat an enemy without firing a weapon
3-6. # Won Battles (5, 10, 15, 20) Defeat a certain number of ships in combat.
That brings me to 6 achievements. I have an array of 8 (which can be expanding to more). Anyone have other ideas of achievements I can give?

Edit: Also, there's a technology used in the new Star Trek Discovery series. A type of jump drive. Instant point to point transport, but highly probablistic. Should I include this drive as a VERY rare find in the game? The requisites of it would be that: (1) The drive would select a random coordinate within 10,000x10,000x10,000 of the destination, per certain number of units you are from the destination. Thus, the farther away you are, the more random your drop-out point. (2) If power is increased to the drive, its accuracy improves, but slightly. (3) In Discovery, there is a creature that, when synced with the drive, makes it work. I could have this creature, or a certain number of techno-parts, like probablistic converters or something, and the more of them you have, the more accurate your jumps become. This drive would be very energy-demanding.

Other things I plan to include:
- the ECH (emergency command hologram) from Voyager, as a rare find. If you have him equipped, and leave your ship to play a ground mission, the AI will take over for your ship).
Update

I finally have a screenshot I can share. It's not much, but I have the module installation, with data on power usage, health, and type done. I created a "fire on myself" button, allowing me to test how the ship handles damage. Obviously shields and hull armor are not implemented yet.

The intent is this. A damage amount is selected. For now it's random, but in the finished game it will be based on weapon stats. The structural integrity % is then checked. If structural integrity is below 50%, the damage is multiplied by 1.5. If it's below 25%, its multiplied again. If it's below 10%, its multiplied yet again. Thus, the lower the ships structural integrity, the more damage shots deal. A fraction of the initial damage is also dealt to structural integrity itself. (I may have to play with the numbers a bit, since structural integrity seems to drop a bit fast, considering it controls if your ship is "destroyed").


Link to Download of Star Trek CE (?MP?) version 0.0.3 pre-alpha:
http://clrhome.org/startrek/downloads/pre-alpha/STARTREK.8xp

Edit: Program updated to 0.0.4 pre-alpha. Shields now work, although only the normal function.
Shields have a "deflection threshold" which is the maximum that they can absorb without bleedthrough. How much of the damage the shields will absorb is a function of the deflection threshold multiplied by the remaining shield % strength. After absorbing that, the hull integrity is used to figure out what damage to deal, as described above.
We now have a functional System Status and Tactical Systems viewer complete. Text only, of course, for now. I'll be adding a Star Trek-style GUI once I verify basics to be working.
Update

Firstly, a question. When testing the program, I'm noticing that, from time to time, the call to os_GetCSC() isn't registering my keypress... as in I've already passed that call when I press the key, and it can take anywhere from 2 to 4 presses to actually register. Can anyone suggest any fixes for this? I cannot use GetKey. I don't want the program to pause until a key is pressed.

A good deal of progress on moving from text-only to a UI-style LCARS system. In the animation below, you'll see how the modules react to being "fired on". As you can see, when Structural Integrity hits a certain level, the grey bar above the menu tabs changes to red. There will be more graphics for a "Condition Red" alert later as well.


And just for some still shots, the Mains Status and Tactical Systems menus.



Lastly, another issue. As per Kerm's assertion to me that CALCet/gCn won't be a thing on the CE, due to the CE only having a USB port, I've been looking into (with GregsAStar's help) a way to use the CE's USB protocol, and having a client program running on a connected computer that converts whatever the CE sends into a gCn compatible packet and sends it off to the server. Kerm, could you possibly inform on if your DirectUSB protocol can be somehow reverse engineered for this purpose and implemented in this specific program? If this is doable, perhaps CE's and the older z80's could all connect to one server.
Update

Changed up the main menu. Sensors will now be no longer a Graph keys tab. I've split tactical into Shields and Ops. Shields will have a GUI indicating the shield strength using colors, as well as a healthbar, and display other information about the shields, and ability to raise and lower them. Ops will have the status and health of the weapons systems as well as various firing patterns available (firing patterns will allow you to do pre-programmed firing, such as firing in a certain pattern at one target, or splitting attacks among several targets without targeting each one---- for example, Attack Pattern Alpha 1 might fire two phasers and then a torpedo automatically).

Viewscreen is also moved to the first tab. Felt that was more natural. Next tab is shields, followed by Ops, then Systems and then Power.


Hey Mateo, I saw someone else offer a suggestion for an arc() command in the graphics lib. If you add that, I can do the same graphic for a full shield grid fairly easily.

Anyone have any other suggestions for improving the UI???
Update

- More GUI changes
- Power controls added (you can change the power allocation to each system). These power setting aren't yet used in combat tho.

Some issues:

- I'm not exactly coding for size. I repeat a lot of stuff... I'm going to start a wave of size-based optimizations soon, as the program's size just broke 10,000 bytes and I feel that's a bit big.

- Can I ask for some advice with regards to ship modeling? Would you guys think that it would be more advantageous for me to hold in memory a 3D model of each ship, or 2D views from several vantage points? Anyone here good with 3d modeling?

Screenshots:





Edit: Added flashing alerts for when shields or a system sustains heavy damage (there's also one for torpedo inventory out as well).
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement