Author
|
Topic: UQM Recreation (Read 84369 times)
|
^Nytro^
Zebranky food
 Offline
Gender: 
Posts: 43
BiG BeEf DiNnEr.
|
There are several technical details that I noticed, now I'm aware that those parameters are to be corrected, but I just wondered whether they are set in purpose and so on.
- the star: the star is bigger and its gravity behaves differentlly. I myself haven't yet decided if I like it or not, but it's gravity range and force seem greater, while the speed it draws seemed to be noticebly reduced. it is now a bit harder to catch speed with a star, and plus, somehow now it is very probable to get completely stucked with the star and die moments afterwards. also, the star seem to draw ships that are WAY distant.
so I just thought- did you plan this, BioSlayer? and is this going to remain the way it is?
also, some breif notes-
- the druuge cannon really doesn't push the ship fast enough backwards during fire. at first I wondered if it even does.
-can't the ship selection screen timing be delayed in about a second (like the original) so we could watch the ship exploded with your (really impressive!) wracks scattering feature?
-in your latest develop, do the Ur Quan fighters get "lost in space" after a long period of flying, like they do in the original? besides this I had an idea, that instead of just dissapearing after a while they (the fighters) could simply "really run out of fuel"- and just stay in place, or act like an astroid- just hang in space and get drawn to the star, unless- the lovely Dreadnought picks them back aboard. (or maybe not, since it does make the dreadnought stronger).
-is the Utwig shield going to become visible any time soon?
- can the X-Form's form shift procedure be animated in multiple stages? I mean, so that we could see it actually change?
- is it possible that also the sizes of the ships will be changed to become proportional according to the original game?
lastly, I just want to say the engine really rocks, it's neat that you can actually "twist" another ship by rotating my ship next to it.
generally I enjoy playing it.
|
|
|
|
|
Logged
|
|
|
|
GeomanNL
*Many bubbles*
Offline
Gender:
Posts: 167
I love YaBB 1G - SP1!
|
Some comments:
- cool project.
- cool colorful graphics and screenshots.
- Timewarp doesn't have the best code around, but it works. I base twx on that project, and well - in the end I rewrote just about everything, but at least I didn't have to start from scratch and could replace stuff piece by piece.
- .Net should not pose any problem for a 1:1 combat game. I've read on the net some estimates which vary somewhat. Most say that the overhead by the .net interpreter is just a few percent (because the C# code is interpreted to .net format, and then compiled, and then executed), some about 10%, and one claim of about 30% CPU load. I don't think it makes any difference for this project. There's a good discussion here. http://www.codecomments.com/archive292-2004-9-280002.html
|
|
|
|
|
Logged
|
|
|
|
Draxas
Enlightened
Offline
Gender:
Posts: 1044
|
I love that shot of the fighters picking apart their hapless victim. Excellent work once again!
If what you say about the way the fighters now behave is true, this makes the Dreadnought vastly more powerful... And also a lot more realistic and sensible. There's no reason that fighters shouldn't be able to act as "portable point defense," though it does make the Dreadnought a much more fearsom adversary; a lot of the typical ships employed against them simply wouldn't work anymore. Earthlings and Spathi in particular seem to get the short end of the stick here.
As far as the "disappearing" fighters goes, though, as I recall, it wasn't so much that the fighters run out of fuel, that the substandard "slave-grade" life support system onboard just gives out after a while, killing the slave piloting it. Thus, retrieving the fighter after that point would be useless; the crewman inside is already dead. Seems like a pretty smart feature, considering that a mass of autonomous fighters could otherwise easily turn on their master and destroy the Dreadnought to make a bid for freedom.
|
|
|
|
|
Logged
|
|
|
|
Deus Siddis
Enlightened
Offline
Gender:
Posts: 1387
|
Actually, I think the fighters are automated, not slave-piloted.
|
|
|
|
|
Logged
|
|
|
|
|
|
JonoPorter
Enlightened
Offline
Gender:
Posts: 656
Don't mess with the US.
|
Sorry no ship of the day today either. A few things in the design have been bugging me so I have decided to do a massive overhaul. The main thing is: I hate it when I see the same block of code twice, and I have entire methods that are exactly the same. So I’m making major changes to reduce the amount of duplicate code and to add more flexibility at the same time. With one major change that I have done I’ve reduced the line count from 10,741 to 9,857. That’s not a small amount of cleanup. I’m also thinking about how to get rid of all the events in the code, because serialization and events are not friendly.
Here is a screenshot of a bunch of fighters blasting each other away:
(The green Ur-Quan have split into 2 sub-species the red and the blue. They are fighting over the ancient precursor artifact which will lead them to the holy blood gulch canyon.)
- the star: the star is bigger and its gravity behaves differentlly. I myself haven't yet decided if I like it or not, but it's gravity range and force seem greater, while the speed it draws seemed to be noticebly reduced. it is now a bit harder to catch speed with a star, and plus, somehow now it is very probable to get completely stucked with the star and die moments afterwards. also, the star seem to draw ships that are WAY distant.
so I just thought- did you plan this, BioSlayer? and is this going to remain the way it is?
The gravity equations in the game are realistic they are pulled from wikipedia.
I’ll most likely figure out how to break my physics engine in order to appease ya and get UQM unrealistic gravity, but it’s not on the top of my list right now.
- the druuge cannon really doesn't push the ship fast enough backwards during fire. at first I wondered if it even does.
The Druuge cannon uses the same logic as the rest of the guns in the game (they all have recoil) so all I had to do to “fix” this was increase the mass of the projectile. Now it has 4 times the mass of a Shofixti Scout, and Ships on the receiving end get quite a jolt from it.
-can't the ship selection screen timing be delayed in about a second (like the original) so we could watch the ship exploded with your (really impressive!) wracks scattering feature?
I would like to have the selection screen be delayed as well. I have put some though into it, but not a whole lot. I’ve been more concerned with the game logic. Also when I do it, I want to do it right.
-in your latest develop, do the Ur Quan fighters get "lost in space" after a long period of flying, like they do in the original? besides this I had an idea, that instead of just dissapearing after a while they (the fighters) could simply "really run out of fuel"- and just stay in place, or act like an astroid- just hang in space and get drawn to the star, unless- the lovely Dreadnought picks them back aboard. (or maybe not, since it does make the dreadnought stronger).
The fighters have the same lifetime logic as any solid object in the game. If they don’t return to the mother ship, before their timer is up they disappear just like bullets do.
-is the Utwig shield going to become visible any time soon?
- can the X-Form's form shift procedure be animated in multiple stages? I mean, so that we could see it actually change?
- is it possible that also the sizes of the ships will be changed to become proportional according to the original game?
The answer is yes, but this goes back to the question of graphics. On of the main things I want to do is switch to OpenGL so it can compile on Linux using Mono. So I really want to wait on doing any spiffy graphics until I’m sure I won’t be wasting work. The scaling of the ships would be easy for me to do but I would have to do it. I would have to find the lengths of all the ships and then scale then and the length of ships is not readily available to me.
lastly, I just want to say the engine really rocks, it's neat that you can actually "twist" another ship by rotating my ship next to it.
generally I enjoy playing it.
Thanks.
Some comments:
- cool project.
- cool colorful graphics and screenshots.
Thanks.
- Timewarp doesn't have the best code around, but it works. I base twx on that project, and well - in the end I rewrote just about everything, but at least I didn't have to start from scratch and could replace stuff piece by piece. - .Net should not pose any problem for a 1:1 combat game. I've read on the net some estimates which vary somewhat. Most say that the overhead by the .net interpreter is just a few percent (because the C# code is interpreted to .net format, and then compiled, and then executed), some about 10%, and one claim of about 30% CPU load. I don't think it makes any difference for this project. There's a good discussion here. http://www.codecomments.com/archive292-2004-9-280002.html
One of the main reasons why I didn’t join the Timewarp project is because I wanted to have realistic physics (collisions with rotation and friction) and Timwarp does not have this. I know C# is slower then normal C++, but I accepted that back when I started the physics engine, and from that I have gained a lot of knowledge on how to speed things up in C#. Also it’s a little late to switch now. The main reason why there is slowness in the game is the way I’m using Direct3D there is a wait call somewhere and it gives it artificial lag.
If what you say about the way the fighters now behave is true, this makes the Dreadnought vastly more powerful... And also a lot more realistic and sensible. There's no reason that fighters shouldn't be able to act as "portable point defense," though it does make the Dreadnought a much more fearsom adversary; a lot of the typical ships employed against them simply wouldn't work anymore. Earthlings and Spathi in particular seem to get the short end of the stick here.
If it happens to unbalance the game to much I could change it so they act like they do in UQM.
Here is how I would do it:
I would change this line in the KzerZaFighterPrimary static constructor:
DefaultTargetingTypes = new TargetingInfo(TargetingTypes.Enemy); To:
DefaultTargetingTypes = new TargetingInfo(TargetingTypes.None, TargetingTypes.Enemy | TargetingTypes.Ship, TargetingTypes.None);
About the fighters:
I did read somewhere that they are indeed piloted.
|
|
|
|
« Last Edit: January 25, 2006, 09:52:29 am by BioSlayer »
|
Logged
|
|
|
|
|
|
|
|
Deus Siddis
Enlightened
Offline
Gender:
Posts: 1387
|
Also, they are referred to as "autonomous" in the SC1 databank entry. Perhaps people mistook this to mean "automated"?
That's probably it, though I thought it also said someplace that a dreadnaught was manned only by a UQ and its dynarri translator, because they so hate the presence of others (including fellow UQ.)
|
|
|
|
|
Logged
|
|
|
|
|
|
JonoPorter
Enlightened
Offline
Gender:
Posts: 656
Don't mess with the US.
|
I’m also thinking about how to get rid of all the events in the code, because serialization and events are not friendly. And then there's me, wishing the UQM code were event driven... I'd never throw out transparancy of the general design for ease of implementation.
Let me explain a little more of what I mean, since C# is rather different then C and C++, to see if you miss-understood me.
In C# an event is basically a list of delegates (method pointers) that will run when the event is called from inside the class it belongs to. The only requirement for a delegate to be added to an event is for it to have the same parameter list and return value.
There are 2 major conflicts that arise from my design using events.
The first one is I rely heavily on cloning (could be considered the same as memcopy) When you clone an event you get the delegates that are still pointing at whatever they were. Let’s say you have a delegate that decreases energy each time a weapon is fired. If you cloned the ship it is in, then the next time you call the event it would decrease the energy of the ship it was cloned from not from the new clone.
The second is I plan to use serialization (a way to put objects into a stream.) for several things. When you serialize an event it has to serialize all the delegates in it. And to serialize a delegate you have to serialize the class the method the delegate is pointing to. The problem is you cannot restrict events to have delegates that points only to classes that can be serialize. So if one non-serializable class has a method used as a delegate in an event; it will throw an error. The solution is to mark events as non-serializable, but then the event is worthless, since when you de-serialize the event it would be blank.
Though events are very useful they just don’t fit into my game design without breaking it. If you think I should still keep the events I would like know your reasoning why.
I searched online for what transparency with programming is and found several different definitions. I was wondering if you could ask you to define what the term means to you.
I apologize if I sound as if I’m talking down to you. I assure I’m not trying to sound that way. It’s just how I type.
Yes, there is only one ur-quan. The rest of the crew are slaves.  |
|
|
|
« Last Edit: January 26, 2006, 12:39:30 am by BioSlayer »
|
Logged
|
|
|
|
|
|
Draxas
Enlightened
Offline
Gender:
Posts: 1044
|
If I recall correctly, the SC1 manual states that the crew of the Dreadnought is composed of a single Ur-Quan captain (plus Talking Pet), and the rest of the crew is drawn from the ranks of their combat thralls. However, it is a distinct possibility that some of those combat thralls might be from outside the sector that SC2 takes place in, and are thus members of races that we never get to interact with.
And the reason for the Kzer-Za's loss in the doctrinal conflict, while never explicitly stated as such, is pretty clearly laid out over the course of the game: At the end of the war with the Alliance, the Shofixti detonated their sun and wiped out approximately a third of the Ur-Quan fleet. The Kohr-Ah appeared in the sector only a short time later, and the Kzer-Za had too little time to rebuild their forces before initiating the doctrinal conflict. Since the Kzer-Za refused to use the Sa Matra against the Kohr-Ah again, they were fighting at a distinct disadvantage, and lost through the power of numbers alone.
|
|
|
|
|
Logged
|
|
|
|
Deus Siddis
Enlightened
Offline
Gender:
Posts: 1387
|
"Yes, there is only one ur-quan. The rest of the crew are slaves."
That would mean that either the slaves are Taalo, or the green UQ can tolerate other species, while the brown and black UQ cannot.
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
Let me explain a little more of what I mean, since C# is rather different then C and C++, to see if you miss-understood me.
In C# an event is basically a list of delegates (method pointers) that will run when the event is called from inside the class it belongs to. The only requirement for a delegate to be added to an event is for it to have the same parameter list and return value. I didn't realise there was a built-in type for events in C#. In C/C++ you'd have to do such things yourself. Which is more work, but it also means you won't run into problems when the built-in type isn't flexible enough.
There are 2 major conflicts that arise from my design using events.
The first one is I rely heavily on cloning (could be considered the same as memcopy) When you clone an event you get the delegates that are still pointing at whatever they were. Let’s say you have a delegate that decreases energy each time a weapon is fired. If you cloned the ship it is in, then the next time you call the event it would decrease the energy of the ship it was cloned from not from the new clone. So you'd have to update the delegates when you clone a ship. That doesn't sound like a big problem. (Also, I wouldn't use events to decrease the energy when a weapon is fired. Events are for responding to changes in state, not to be used instead of a normal method call.)
The second is I plan to use serialization (a way to put objects into a stream.) for several things. When you serialize an event it has to serialize all the delegates in it. And to serialize a delegate you have to serialize the class the method the delegate is pointing to. The problem is you cannot restrict events to have delegates that points only to classes that can be serialize. So if one non-serializable class has a method used as a delegate in an event; it will throw an error. The solution is to mark events as non-serializable, but then the event is worthless, since when you de-serialize the event it would be blank. Yes, you'd have a similar issue to handle when you work in C/C++. You just cannot include references to objects that aren't (being) serialised. In C/C++, you'd do the serialising yourself, so you can decide which fields you do not want to store, and reconstruct relations between objects instead of deserialising them.
If it's all-or-nothing in C#, then I guess you're SOL. Perhaps you could ignore the built-in event system and make your own, like you would do in C/C++.
Though events are very useful they just don’t fit into my game design without breaking it. If you think I should still keep the events I would like know your reasoning why.
I searched online for what transparency with programming is and found several different definitions. I was wondering if you could ask you to define what the term means to you. I'm talking about transparancy of design. Which basically means that it is easy to understand. Keeping your invariants simple and generic, separation of concerns, that sort of thing.
By using an event-driven design, the method triggering the event doesn't have to know anything about the listener, and the listener doesn't have to know what caused the event.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
|
I don't think that theory holds much water. All of the ur-quan that I ran into were fully crewed, at least. The reason that I remember for their defeat from the game is that the ur-quan forces were weakened during the first war.