Okay, now that I've proverbally broken ground (I started coding ) I have a design level issue that needs to be resolved. So, like any great engineer, instead of making a design decision, I'll put it to a vote (Heh, if any of you out there are engineers, sorry, didn't really mean that :p)

Here are the two possibilities:

1. Have a static system object type (new) that would appear in the very background behind stars and ships/systems (like nebula's etc) that wouldn't move on the screen as the player moved. Leave spobs as they are...

2. Have no static background (Which is technically refered to as an underlay buffer) and instead have an extra flag for spobs which, when active, would make the spob NOT show up on the radar screen, thus creating a steller object that would move off the screen instead of remaining static on the screen.

Either way, I'll have support for nebula type objects (and there will be no silly 4 spob/system limit) what I need to know is if you guys want an underlay buffer for static images in the very background of the screen...

BTW: Apple's game sprockets are REALLY COOL !!!!!

------------------

(This message has been edited by kberg (edited 03-23-2000).)

Oh, and I should add that, in adding a few features (namely having networking) I've had to make some tradeoff's and scrap any plans to make a 68k version of this program... I may be able to make a 68k version that does not contain networking, not really sure at this point. I can see after I'm done coding the framework.

------------------

Hmmm.... :frown: I guess that everyone else here has already given up for the night. Well, I might as well keep posting design possibilities.

How many people are in favour of having sprites for Spobs? This would let a planet rotate, or a station spin... And what about orbiting Spobs? I would try and provide a flexible orbit mechanism that would go smthing like Spob 1 is the center of this solar system by default. Spob 2 would have the option of orbiting Spob 1 either clockwise or counterclockwise and would have a speed field. Spob 3 would have the option of orbiting either Spob 1 or Spob 2 with similar settings and so on... This would allow someone to make a whole dynamic solar system with a star(s), planets, moons, and stations quite easily. The only problem is that defining a star also defines where your light source should be coming from, which would almost certainly conflict with the game sprites... Is this a worthwhile tradeoff?

Oh, also, in order to clean up a few problems with network play, there are substatially more keys (37) in this program then in EV/EVO... I'm taking advantage of Apple's input sprockets, so theoretically, when I'm done, you could play most of the game using speech recognition, or a joystick, or anything else that supports Input Sprockets for that matter...

------------------

Heh, I guess everyone here has been so demoralised by previous attempts to make an EVMP that they don't want to reply...

Anyways in order to cut down on game-play key's I've introduced a game panel that will allow the player to type commands to his ships computer. Pressing a computer key during gameplay will make the panel visible, and then the player can type commands like (J)ettison, (E)ject, (D)estruct, (M)ap, (S)tatus, (I)nfo, and (T)alk. Basically anything that required a dialog in EV/EVO now is accessed through the computer. Talk will have a set of operators as well to determine the scope of your broadcast... Default will be the target, (A)ll, (T)arget, (P)lanet, (H)ostile, (F)riendly, (E)scorts??? If anyone has a better name for allies that has a unique first letter, let me know...

Also, please be prompt with responses to my first questions... It would be nice to finish off some of these classes before moving on.

------------------

(This message has been edited by kberg (edited 03-23-2000).)

Quote

kberg wrote:
**Okay, now that I've proverbally broken ground (I started coding:D ) I have a design level issue that needs to be resolved. So, like any great engineer, instead of making a design decision, I'll put it to a vote (Heh, if any of you out there are engineers, sorry, didn't really mean that :p)

Here are the two possibilities:

1. Have a static system object type (new) that would appear in the very background behind stars and ships/systems (like nebula's etc) that wouldn't move on the screen as the player moved. Leave spobs as they are...

2. Have no static background (Which is technically refered to as an underlay buffer) and instead have an extra flag for spobs which, when active, would make the spob NOT show up on the radar screen, thus creating a steller object that would move off the screen instead of remaining static on the screen.

Either way, I'll have support for nebula type objects (and there will be no silly 4 spob/system limit) what I need to know is if you guys want an underlay buffer for static images in the very background of the screen...

BTW: Apple's game sprockets are REALLY COOL !!!!!
**

I have for a long time dreamed of some way to see a static nebulae behind the passing stars. That sounds like a fantastic idea. Let me know if you will pursue the project.

------------------
Mace means no.

Quote

Gandalf wrote:
**I have for a long time dreamed of some way to see a static nebulae behind the passing stars. That sounds like a fantastic idea. Let me know if you will pursue the project.
**

You wouldn't believe how easy it is to implement...

So, is this in agreement? The reason I ask is, if hardly anyone wants the feature, then I might as well save memory and double Spobs for nebula using the already described hacked method.

------------------

Please, if you are trying to make a EVMP then leave things as much the same as possible. I think that all the nebula backrounds, moving spobs, etc aren't necessary. It is already proven how the simplicity of EV makes it a great game. Also, if you are going to make this you need to remove plugins, since to do that would mean you would have to host a different game for each plugin. My advice is keep EV the way it is, maybe just add a few features and multiplayer. However, this is your decision, and do what you would like best, since if you enjoy programming it, it is more likely to be finished.

BTW, when you get this to a stage where it is functioning at all I would love to be a beta tester (hint hint)

------------------
Raddy

No beer and no TV make Homer something something...

I kinda agree with Raddy. Leave it as it is now, except of course for the multiplayer part , and just work on getting it to work, unless of course, you can't fo back and add the feature afterwards. So leave it the same, get it working, then go back and add anything. The reason I say this is, if you're really going through with this (which I doubt, no offense to you, many good programmers have tried and failed), it's going to be hard enough as it is without extra features, but once you've got the main engine, then you can go back and add spiffy features.

But since you're on the topic, I'd like static nebulas and such in the background, or maybe if they moved just very slowly. And I think a spinning planet would be good, but not nescarrily an orbiting one which would make it confusing having to search for the planet. But, just with spinning planets you could create orbiting moons, which would be neat. You'd just have the moon move in each frame.

------------------
-Shade

"Cannibals are people to."

(url="http://"http://www.theonion.com")The Onion, America's finest news source(/url)

Don't worry... All the extra features described here form a superset of the standard EV/EVO universes. That means, if you want a simpler game, you just don't use any of the new features. There will be a some major differences that are unavoidable however, like the changes required for mission interactions, etc... Keep in mind that this is a completely different code base from EV/EVO as well. I'll also try and post a compiled binary somewhere for people to check out and play around with once I get to that stage. It would probably consist of a networkless game with a simple ship that you could fly around an empty system. Primarily it would be to let U guys see the new engine, see how I defined the ship, see the new interface and stuff rather then beta testing. Oh, how many turret positions do people want? Currently I've defined 8 with x & y coordinates.

------------------

About turrets, I had this idea a while back and was waiting for someone to bring it up. Instead of having to put a turret in the sprites for each ship, I think you could pull it off using a third color in the mask. Then each turret would have rotating sprites, and the actuall turret would always be the same size. That way you could easily make turrets that appear on the ship. Get what I'm saying, kinda?

------------------
Raddy

No beer and no TV make Homer something something...

Quote

ShadeOfBlue wrote:
...The reason I say this is, if you're really going through with this (which I doubt, no offense to you, many good programmers have tried and failed), it's going to be hard enough as it is without extra features, but once you've got the main engine, then you can go back and add spiffy features...

Heh, be nice... Wasn't it you that posted somewhere else how much you wanted to have lateral thrusters? Already implemented, took a good half hour to figure out all the trig though, been a while since I took physics. I could post the source even if you want.

General update. MPW sucks... I'm going to splurge on Metroworks as soon as I get the chance. Heck, even all of Apples source is compiled in Metroworks rather then MPW. Go figure...

------------------

WOW kberg you really seam to have this programming thing down. Wow, at the pace you're going you could have this done in a week. Just Kidding of course. I say that if you enjoy doing this and you can do something fairly easily you might as well. Obviously all these extra features are something that you would like so just go ahead and do them. Remember, this is your project, and make sure that you make something that you would enjoy because that will make the best results.

------------------
Raddy

No beer and no TV make Homer something something...

Hmm, one week... Doubt that. Anyways I've got a data structures project due next week as well, so I'll have to slow down the pace a bit. I might have a demo by that time however... Also, 8 bit masks. As I'm painfully finding out, I'm going to have to code in support for this rather cool feature myself. Not that it's hard at all, just will slow things down substantially. I'll be able to figure out just how bad the performance penalty is soon (once I finish off some more of the drawing class). But suffice to say, using 1bit masks allows for some rather powerfully optimised drawing routines. Apple has been kind enough to provide these at a very low level with copybits and copymask, which I'm sure EV/EVO is making use of. So 8-bit masks is up in the air at this point. :frown:

Oh, Raddy. Could you explain your turret idea a bit better? I'm not quite sure what you were trying to say in your previous post.

------------------

(This message has been edited by kberg (edited 03-26-2000).)

How cna you stop the 4 limit?

------------------
Lance,Captain of the White Swan.

Quote

Lance wrote:
**How cna you stop the 4 limit?
**

I assume your talking about the four spobs per system limit? Uhm, I guess I should explain to you just what I'm doing... This isn't a plug-in or anything like that. This isn't an update to EV/EVO. Right now I'm trying to program my own game, from scratch, that will look and function like EV/EVO but will also have the capability of handling network play...

On another note: I've upgraded to codewarrior pro version 5, which should arrive tommorow. Hopefully codewarrior is capable of linking to precompiled libraries, especially ones created by Apple in the first place... Well anyways I'll be able to see how everything looks, and hopefully it all works as well as it should in theory (I'm done debugging, and everything compiles cleany, just won't link properly to Apples sprockets) Next thing to tackle... weapons

------------------

Kberg - I realize that my question comes too early in the development process to tell, but I'll ask anyway. What are you planning to do with plugins? If you're planning to allow plugins, I suggest implementing it like I said in the other EVMP string - host plugins on central gameservers, and distribute the modifications at the start of each game.

------------------
We come in peace, shoot to kill, shoot to kill, shoot to kill...

Quote

Obormot wrote:
**...host plugins on central gameservers, and distribute the modifications at the start of each game.
**

That's pretty much the general plan at this time, yup. Though the client will check and update whenever the player lands, same as how the player saves his current state in regular EV/EVO... The general plan is to allow small scale multiplayer and single player modes as well that would allow people more freedom in how they play their games. Allowing plugs, etc...

One problem that I should discuss. The current resource based model is too limited to allow larger scale scenario's, and so I'm currently basing my designs around a more package based design. This would mean that a plug-in would be a series of directories in a strictly orginised pattern. Whatever, needs some work. Anyways the trade-offs for this more flexible design is that each object (ship, weapon, system, stuff like that) will require a unique designation number. The range of possible numbers will be rediculously large, probably an unsigned 32bit integer which means 4 billion maximum for ships, systems, spobs, and things like that. It will be up to plug designers to try and make sure they choose a unique number. Well, too early to really talk about this at this stage. Right now I'm in the stage of strugling with a rather wierd bug in codewarrior where using an = operator on an empty string causes the program to crash??? Whatever, after doing all my programming in *nix, going to the mac toolbox is rather unpleasant. I guess it takes some getting used to.

------------------