CodeWalrus

Development => Calculators => Calc Projects, Programming & Tutorials => Topic started by: on January 01, 1970, 12:00:00 am

Poll
Question: Should the graphics (sprites) for this game be...
Option 1: Multiple 2D images, at various angles? votes: 3
Option 2: 16x8x16 3D sprites with a viewing algorithm adapted for it? votes: 5
Option 3: Other suggestion (post in topic) votes: 0
Title: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on November 19, 2017, 10:26:12 pm
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:
(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_0.0.16alpha.gif&hash=9455a08b383ab2f2016c9dcf3466198a)

(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_0.0.16_mains.gif&hash=ccea2a264947fa1181ace92e89f093fa)

(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_0.0.16_power.gif&hash=9c8f9a441c31081a1096f129e5f2118a)

(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_0.0.16_shields.gif&hash=fae0bd91d05f5e2c3f6d341c5ca17805)


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?
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: mazhat on November 20, 2017, 12:23:01 am
Awesome idea, looks complex.

I personally care more for speed than graphics,
so 2-d would be nice. I'm guessing it would look like
Turn and Burn for the Gameboy.

Note:
You can make "polls" for voting when you're making a thread.
I think you can add them later too.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on November 20, 2017, 01:06:01 am
Thanks. Poll added!
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: DJ Omnimaga on November 20, 2017, 02:28:39 am
That looks nice. It didn't look as great on Messenger because it cropped the borders but with the full-view of the screenshots it looks better. I like the layout as well. Good to see you're adding some graphics or icons, though.

As for graphics, I would be ok with 2D sprites with no 3D effect. You don't have to add 360 frames for each angle or something lol
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: Ranman on November 20, 2017, 11:24:02 pm
This looks awesome!!!   :thumbsup: :thumbsup: :thumbsup:

Ranman must go buy a CE now.

I vote for using 2D sprites for the ships and objects.  :)
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on November 21, 2017, 01:36:38 am
Thanks for the comments guys. Gotten a bit more progress done.

This is the Weapons Control system. Here you can see what weapon class and type are equipped, their damage rating, shield and hull efficiency, module power setting, module health, and eventually the name of the entity or player the module is currently targetting (via targetting sensors). You'll be limited to 3 weapons modules. An unset module simply doesn't show up, and an offline module shows up red.
(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_weapons.gif&hash=08cad36b04cfdbf59605361d6ad3ad45)


And a slight modification to the Mains system status panel. There's now an online/offline indicator, and pressing Mode with a module highlighted toggles that.
(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_mains.gif&hash=a6310b7f944475f052c5064a7c9777ec)


v0.0.18-pre  __ Saving Ship/Player data officially added __
(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_saving.gif&hash=da9e59a25a4111ccc64c9ce21c9de298)
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on November 23, 2017, 03:26:31 pm
Update

An alpha demo is almost here. Got pretty much all the basic combat systems complete. Just have to add in phaser/torpedo sprites, rendering, and target tracking. Then work out any bugs in the firing/movement/rendering system. Here's an image with the demo opponent, a Borg sphere, rendered on screen.
(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_0.0.21.png&hash=aa04b58a109508d752754533029a59f9)
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on December 03, 2017, 01:25:26 am
I need help debugging my rendering routine. Anyone fairly experienced with C and rendering who can take a look at my code?
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: DJ Omnimaga on December 06, 2017, 10:42:10 pm
@Adriweb or @Lionel Debroux might know but I don't remember if they still do CE C.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: Adriweb on December 06, 2017, 10:44:10 pm
I've never actually written any 3D rendering code myself, so I probably can't help on that part, but maybe general opts.
Is the code hosted somewhere like GitHub ?
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: Ranman on December 11, 2017, 01:10:40 am
So... I finally got this up and running on my calc and CEmu.

Is this an original idea or are you trying to remake a game that already exists. If the latter, can you provide a link as to what this should look like in action?

Looks pretty good so far. I see the issues with rendering you were talking about.

Now... i finally may be able to help.

I was unable to install the Atlassian Sourctree on my WinXP platform as it doesn't support WinXP -- go figure. So im a bit at a disadvantage. Trying to rectify. I finally downloaded Win10; but before I install it, I wanted to get a SSD and a memory upgrade from 4GB to 8GB. That should be done by Wednesday of this week.

Chat later.

Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: mazhat on December 11, 2017, 01:44:21 am
It would be nice to have some game play on video.
Just for archive reasons.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on December 14, 2017, 03:50:03 am
Hey guys. Sorry for the delay in updates.
As of now, rendering has improved substantially. Scaling is fixed, as is half of Field of Vision. Sprites now also clip to the viewscreen.

What is remaining are the following two bugs:

1) Your ship starts at an XZ angle of 0 and a Y angle of 0, a vector of 0,0. The other ship is in the viewscreen, at an angle of 3 degrees on the XZ and 0 on the Y. It appears onscreen. If I rotate my ship to the right (angle values increasing), the other ship moves off to the left as it should. However if I move off to the left (decreasing), once the XZ angle for the viewer drops to 0 and then loops to 255, it registers a difference of 252 degrees in the angles, and thus the enemy ship vanishes, despite actually still being 4 degrees away. I've added this code: if( diffXZ > 128 )   diffXZ = 256 - diffXZ; In an attempt to rectify this, to no avail. Link to code for that here: https://pastebin.com/9sAPE4HW

2) My entity tracking algorithms seem to not work properly. Projectiles do not appear to track their targets, nor does the AI seem to track the player, and since they both use the same AI subroutines, it would make sense. I DO need #1 fixed before I can resolve this tho.


As far as video footage, there are some animated screenshots on my project page: http://clrhome.org/startrek/ (http://clrhome.org/startrek/)'s gallery tab. There is no full gameplay footage yet, as the game isn't stable enough for that yet.

As far as what this is based off of.... there is a Gameboy Star Trek TNG game that was the inspiration for the LCARS interface and rendering system and sensor dialogs I will be using. As far as other calculator games go, tifreak has plans to make a singleplayer Star Trek game, though he's still learning C and he has access to this repository as well to see some code in action. THIS particular game, while the demo's will initially be singleplayer demos, eventually PvP between two calculators will be introduced as a precursor to networking via the CE's USB port, with an eventual backwards compatibility for CALCnet (at which point I'll open source this for porting to the monochrome calculators), using a CALCnet hub. This will allow older z80's to connect, and I'll probably have to write (or outsource the writing of) some sort of computer script to convert the CALCnet stuff into stuff the CE can read over USB. I might ask Kerm Martian if I can take a gander at his Direct USB stuff at that point.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: Pieman7373 on December 14, 2017, 05:10:50 am
Okay, this is pretty much the coolest thing i have ever seen! I can test stuff :3
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on December 15, 2017, 06:25:45 pm
Update

Field of Vision issue resolved.
Remaining things to do before demo: Fine tune where things show up on screen (x,y coords), and how I map the FOV to the screen over varying scales; Resolve bugged entity tracking algorithm; Remove flicker in LCARS interfaces.
Firing works---ish.

(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_0.0.25a.gif&hash=7f5de9a33d4935731f75271d34e8c15b)
(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_weaponsfire.gif&hash=2838d6ce1a7dad24c2170f1dc2bba54f)
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on December 18, 2017, 12:14:00 am
Update

After a bit of not understanding double buffering and then finally understanding the concepts, I figured it out, and created fairly smooth graphics rather than flickering mayhem. I implemented this only for the view screen, since it should be like you looking out a window. For the other tabs, which are LCARS displays, I left the faint flickers in, since I would think a refreshing LCARS display would have a quick flicker.

Here is a screenshot showing the Borg cube with the new graphics.
(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2Fstartrek_0.0.26a.gif&hash=50483d2863614410da67fcad00fdeef9)

=========================
A few more things to do (Bugs):

1. Implement a shunting yard or some other form of algorithm that sorts rendered map objects by distance, so we can render them in order. (help, please?!)

2. Projectile tracking not working. (reviewing)
----- 2-a. Projectiles do not track their targets.
----- 2-b. Sometimes, pressing the fire key fires a phaser, other times it seems not to.

3. The Borg sphere not AI'ing.
----- 3-a. The Borg sphere does not seem to track the player
----- 3-b. The Borg sphere does not seem to fire as its supposed to. This is likely the same bug as 2-b.

4. The collision detection and collision interpolation algorithms might need some work

** If anyone is willing to assist me in debugging, let me know!

I'm hoping for a release by Christmas.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: DJ Omnimaga on December 19, 2017, 03:05:02 pm
I can't see the screenshot D:. Is it the same as the one you showed me yesterday?
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: c4ooo on December 19, 2017, 04:55:07 pm
Quote from: ACagliano on November 19, 2017, 10:26:12 pm
For full 3D, I could make 16x16x16 models for each item, leading to an overhead of 4096 bytes per object,

ehh this isnt how you should be storing 3D models. 3D models are stored as a a bunch or vertices and faces made from those vertices. ;)
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on December 19, 2017, 05:42:57 pm
Quote from: c4ooo on December 19, 2017, 04:55:07 pm
Quote from: ACagliano on November 19, 2017, 10:26:12 pm
For full 3D, I could make 16x16x16 models for each item, leading to an overhead of 4096 bytes per object,

ehh this isnt how you should be storing 3D models. 3D models are stored as a a bunch or vertices and faces made from those vertices. ;)

oh. Can you give me an example? Would this require more or less a) memory and b) processing power to use than a series of sprites of ships from various angles?
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: c4ooo on December 19, 2017, 06:07:56 pm
Quote from: ACagliano on December 19, 2017, 05:42:57 pm
Quote from: c4ooo on December 19, 2017, 04:55:07 pm
Quote from: ACagliano on November 19, 2017, 10:26:12 pm
For full 3D, I could make 16x16x16 models for each item, leading to an overhead of 4096 bytes per object,

ehh this isnt how you should be storing 3D models. 3D models are stored as a a bunch or vertices and faces made from those vertices. ;)

oh. Can you give me an example? Would this require more or less a) memory and b) processing power to use than a series of sprites of ships from various angles?

What you are describing with "16x16x16 models for each item, leading to an overhead of 4096 bytes per object" seems to be a voxel engine, which are not exactly the fastest or best looking (ahem ahem minecraft).

Here is an example of how 99.99% of 3D games store their models:
v  0.0  0.0  0.0
v  0.0  0.0  1.0
v  0.0  1.0  0.0
v  0.0  1.0  1.0
v  1.0  0.0  0.0
v  1.0  0.0  1.0
v  1.0  1.0  0.0
v  1.0  1.0  1.0

f  1  7  5
f  1  3  7
f  1  4  3
f  1  2  4
f  3  8  7
f  3  4  8
f  5  7  8
f  5  8  6
f  1  5  6
f  1  6  2
f  2  6  8
f  2  8  4

(This is a cube). ( and of course you want to store this as raw data, not as text). If you want to have a texture applied, you have to also store texture coordinates.

As to the question of "Would this require more or less a) memory and b) processing power to use than a series of sprites of ships from various angles?", well, i really dont know. The "sprites of ships from various angles" method will probably give you better results of far away objects, where as 3D models would be better in up-close ship to ship dog-fighting. Since the game seems more of the former then the latter, i would go with the "sprites of ships from various angles" method. You could probably make and texture the models in blender, then render them from different angles. You might also want to take a look at TheM02's 3D engine for the CE.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on December 20, 2017, 03:53:50 am
Yea, that 3D engine is definately something I want to use. It seems to look beautiful, but im not entirely sure it would be compatible with my map format.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on December 20, 2017, 05:40:28 pm
Ok so I need some advice.

The Problem: When I'm rendering the weapon sprites, the weapons should seem to move from lower on the screen, and then move towards the center, and the ship. I thought of drawing triangles (gfx_FillTriange) to create a perspective beam phaser effect, but that's very hard to control with the degree I need to. I'd need to be able to calculate the starting point and ending point of the phaser beam and draw a line or series of lines. The starting and ending point may not always be on screen, especially when the game goes multiplayer and you'll sometimes see a phaser fly across your viewscreen, heading elsewhere. This seems to not be a problem with the torpedo sprites, as torpedoes are more in one place than beam-like.

The resolution: I could give every phaser a *trail length* value that's like some % of the weapon's speed. For each phaser, we calculate the phaser's position and the trail's ending position, draw the phaser in position, and then draw a line or triangle from the phaser to the trail end. GregsAStar also suggested stretching the phaser's sprite out so that it goes from the phaser's position to the trail's end.


Does anyone have any other suggestions?
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on December 31, 2017, 03:15:12 pm
Would I be able to recruit some debugging assistance? I've gotten this game mostly debugged, but I'm still struggling with two remaining issues that I can't seem to remove.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on August 13, 2018, 11:52:01 pm
UPDATE -- 0.50 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.

(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2F0.50_statusicon.png&hash=89cbdbf12d02a9af85e1508b0276aa25)
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on August 26, 2018, 10:47:44 pm
Update -- 0.65 alpha

Significant additions to the program:
1) Phasers/torpedo modules added to the ship. Only phasers shoot currently
2) Ability to quick fire or charge fire phasers, at different power costs.
3) Splash screen added
4) Navigational display for viewscreen (overlay) added, indicating ship rotation and pitch, as well as current sector position.
5) targetting display for viewscreen (overlay) added, with a crosshairs that moves on the screen and text showing the type of weapon we are firing.
6) Bug with rotation/pitch removed, thanks to MateoC

(https://codewalr.us/proxy.php?request=http%3A%2F%2Fclrhome.org%2Fstartrek%2Fgallery%2F0.65_navgui.png&hash=9ec8eafd2c3cb4d7dcfbb21c9fb45237)
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on August 20, 2019, 01:52:06 pm
A few major updates to this project, which is very much not dead, just slow moving due to RL stuff.

Anyway. The project has been split into 3 distinct segments, each with a different team working on it.
The client side program, for the calculator, is being mainly developed by myself with some help from beck on the 3D rendering of the map.
The server is being worked on by myself, Greg, and beck, with a web-frontend being worked on, which I am working on solo.
To interface the two, we are awaiting the completion of the USB device library in the C libs.

The web frontend will be at http://srv.titrek.us (please do not register on there yet), with the main project page at http://titrek.us. I am hosting the server for the time being on the raspberry pi 3, but am looking to upgrade that to the new RPi 4 with 4g of RAM, which will likely be the final resting place of this server.
Anyone wishing to contribute to this goal, feel free to donate at http://titrek.us/contribute.php.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: DJ Omnimaga on August 22, 2019, 05:34:38 pm
Interesting. I didn't know this game would be online in some ways. I'm glad this is still being worked on.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: ACagliano on October 01, 2019, 09:21:16 pm
UPDATE

Progress has been made on the User Interface for TI-Trek. Here are some screenshots:
The Main Systems module overview screen
(https://codewalr.us/proxy.php?request=http%3A%2F%2Ftitrek.us%2Fgallery%2F0.86_mainsscreen.png&hash=0b41815456f79c4ae30ce4c88018a893)

The Tactical Systems module overview screen
(https://codewalr.us/proxy.php?request=http%3A%2F%2Ftitrek.us%2Fgallery%2F0.86_tacticaloverview.png&hash=725bb52dd9c4de41099770167799774f)

The module configuration/info popup, accessible by pressing [Enter] on chosen module
(https://codewalr.us/proxy.php?request=http%3A%2F%2Ftitrek.us%2Fgallery%2F0.86_moduleinfo.png&hash=085d0a1772f4526ae0a7b72518f7462e)

Some changes to the power system setup also. Module efficiency (how well it performs its task) will be a function of module battery charge (current power level * 100 / max power storage) multiplied by power draw setting (set power draw / base power draw). Power draw meaning how much power a module will take from its source (core, auxiliary, or internal reserve) every power cycle. Each module will also have a maximum draw, which is the maximum amount of power a module may be set to draw before the module incurs a damage penalty every power cycle. For instance, if the module's max draw is 8 and you have it set to 10, the module will take 2 points of damage every time it draws power. This means you can set a module to use as much power as you want, to super-boost it, but keep in mind the higher you set this, the faster the module takes damage.
Title: Re: Star Trek Multiplayer (CE Edition) nears first demo release
Post by: DarkestEx on October 07, 2019, 05:37:50 pm
That looks impressive, nice :D