This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - ACagliano
Pages: 1 ... 59 60 [61] 62
901
« on: March 19, 2010, 12:21:55 pm »
In my first version of the game, there will be only multiplayer. In subsequent versions, there will be AI, though perfecting it will take time and it will probably be several releases before the AI is even a challenge.
################################
Also, there will be strategy loops programmed in, in both MP and the later SP. There will be two shield sections, a rear shield and a forward shield. You can transfer shielding power between them if one gets low. Also, different systems will be in different portions of the ship. For example, if you wanted to knock your enemies sensors offline, you would aim at the rear of the ship. If you wanted to knock out their warp drive, you would hit the front (these are examples-im not yet sure where each system will be).
Edit (quite a fast double-post)
902
« on: March 18, 2010, 07:44:03 pm »
If my mental code writing is correct, method 2 would be easier as well.
*Yes, I plan out the major parts of the code in my mind before I code them.
903
« on: March 18, 2010, 07:35:21 pm »
i would prefer option #1, especially since coordination between calcs is difficult enough. Also, dont want people getting lost and not being able to find the enemy ship P: but, that's just my opinion.
Well, know that regardless of which method I use, phasers will be a direct shot. But, photon torpedos can be locked onto target. Once locked, there is no way to shake them, as they constantly get your coordinates and recalc their trajectory. And, you would always be able to find your enemy, regardless of the method I use through the sensors, so long as the sensor system has not been destroyed. Also, as an important note for gameplay (and strategy): A ship with sensors knocked out cannot lock weapons onto an enemy.
904
« on: March 18, 2010, 04:10:50 pm »
Yes. we can assume one byte for each term in the list. I will confine the variables to not larger that 255. And, yes. Let neither of them wait. I'll deal with making sure that there is an opponent.
905
« on: March 18, 2010, 12:55:04 pm »
Can someone please write me a subroutine in assembly that will send to another calc, without the other being in receive mode. The variable to be sent should be written into Ans at the sending calc. So for instance:
"L1
subroutine
would send the variable L1 to the other calc and store it as L1. I hope this is possible and quick to do. Thanks all.
906
« on: March 18, 2010, 12:52:46 pm »
I dont know. I wont until its coded and i look at it.
907
« on: March 18, 2010, 12:37:21 pm »
Ok. Request to the assembly community. Can someone please write me a subroutine in assembly that will send to another calc, without the other being in receive mode. The variable to be sent should be written into Ans at the sending calc. So for instance:
"L1
subroutine
would send the variable L1 to the other calc and store it as L1. I hope this is possible and quick to do. Thanks all.
Now, a question of preference for game play. I can use one of two methods for viewing the battle:
1. Bird's eye: both ships are fully visible and viewed from above.
2. Window: Only a small section of the real battle is visible, through a window. All other locating is done via sensors and locking onto targets. Note: This is how it is actually done in the movies.
908
« on: March 18, 2010, 12:34:51 am »
It comes with the Axe parser download. Now, another question: the zcomm file-the send command. What does it do at the other calc? If I use
"L1
Asm(prgmZSEND
Would it take the contents of L1 and store it to L1 in the other calc? And, does ZGET need to be running on the other calc? I hope not.
909
« on: March 17, 2010, 06:48:16 pm »
910
« on: March 17, 2010, 06:36:29 pm »
To DJ, I have a prog on calc to turn sprites into hex. IDK what the file name is, but the program name is HEXPIC.8xp
To Gale: When you do, I am interested to know how smooth the gameplay is (how much the linking subroutines slow it down), and I will need to know of any bugs that occur. I will be unable to test the 2-player part myself, as I have no link, so I'll be relying completely on 3rd party testing.
911
« on: March 17, 2010, 06:33:14 pm »
Well, of course, for the most seamless linking, you would be better to write your entire code in assembly. But, if your like me and cannot program in assembly, the one I'm using is vComm. You can find it in the TI-file archives.
912
« on: March 17, 2010, 06:25:02 pm »
Thanks Gale. Once the program is done and uploaded, I will provide the link. Also, to coordinate movement between calcs, I will be using an assembly subroutine, not the calc's TI-Basic commands, for exactly the reason you say.
913
« on: March 17, 2010, 03:00:14 pm »
Ok. I am against making pics, as I've had bad experiences with pics as subroutines. What would the hex string be for this sprite:
0 0 1 0 0 1 0 0
0 0 1 0 0 1 0 0
0 0 1 0 0 1 0 0
0 0 1 1 1 1 0 0
0 1 1 1 1 1 1 0
0 1 1 1 1 1 1 0
0 0 1 1 1 1 0 0
0 0 0 1 1 0 0 0
this is aiming down. I will need a hex code for each of the four cardinal directions (or can someone tutor me on how to do it).
914
« on: March 17, 2010, 09:19:28 am »
Can someone please explain how to use the "sprite drawing" command in xLIB. Or is it possible to do it any other way, easier?
915
« on: March 17, 2010, 02:13:07 am »
The first release will not have a SP part. In subsequent ones, AI is a goal.
Pages: 1 ... 59 60 [61] 62
|
Show Posts