Topic: What is important to the users?

[Morgul]

Right now, as head of the project, I'm feeling a bit out to see as far as what to get done during the summer. There are quite a few things we could implement... and most of them are about equal on my list of importance, so I figured I'd ask you all what you think we should get done this summer. Here's the list:

1) Systems - This is ship systems. This would mean that the performance of your ship is based on these systems, which can take damage, and also have reliabilities to them. Basically, it needs to go in for combat, and it also makes it possible to start developing the ways the user interacts with things like systems (as in how to repair them, etc.)

2) Damage - The ability for systems to take damge. Pretty simple... but requires Systems.

3) Combat - Just like the name implies. This would be ship to ship combat.

4) Planets - The ability to land on planets. This requires a good deal of work... like writing the fluid thrusters for the mechanics system.. aka writing more API for the mechanics plugin for CEL, and doing more work to get out app to talk to the physics engine. Then, we'd have to get LOD working, and make the planet itself...

5) Artificial Intelligence - Basically opponents for players to fight. Could be simple, could be complex. Depends on what's wanted for now.

6) GUI - Implement an entire GUI system for the game (aside form the HUD). We'd do it with SVG graphics, but that requires us to write an SVG loader/render for CS. Possibly even an SVG windowing system. Tricky stuff.

7) Stability - Another thing would be simply focusing on cleaning everything up so that most of the bugs are gone, and that what's currently there works flawlessly... although not much fun, it would make it more stable.

8) Polish - Clean up the graphics. Make everything look amazingly cool, with awesome textures, and insane looking shaders (hell, any shaders would be a start). Also optimize it as much as possible to get the most FPS we can out of it.

9) First-Person work - Right now we've ditched FP mode in our game in favor of Flightsim. We really should go back and implement some of the things we wanted to do in Flightsim in FP as well. Hell, it doesn't even use the mechanics plugin yet.

10) Real-Time Strategy / Captital Ship - We could also start the next mode... which is like RTS. Basically, it would alow you to control more than one capital ships at a time.... like a fleet. I think we should start calling it 'Fleet mode' instead of RTS.. Oh, and about captial ships... they fly differently from fighters (which is the flying style we currently have) so they require a different way of controlling them. (If anyone's ever played StarFleet Command... we're thinking of doing something like this.) We could also impliment that at the same time as RTS (or before.)

11) Networking - This could be p2p, server/client, or a mix. We're thinking of using RakkNet. (can't find the link right now...)

So, any other ideas? Any other suggestions? We can work on more than one at a time.. and I can draw up a To-Do list from the suggestions, and update it for what's currently finished when it get completed. (maybe make a sticky thread, and update it as out ToDo list changes.. so you always know what we're doing. Anyone like this idea?)

Also, I personally vote: 1,2,3,11 and then:5,7,6 as time allows.

--Chris

[contingencyplan]

In short, here's how I would prioritize these aspects of the game:

[list=1]

• Stability
• Polish up the flightsim interface some, at least till we're really happy with it.
• Have an initial combat / damage system, even without the Systems thing.  We could just do a "unit system" - the ship is one system, and damage anywhere damages the ship as a whole.
• Systems
• AI - develop in tandem with the combat system
• GUI
• Planets
• FPS
• Fleet View
• Networking
[/list:o]

In long:

Personally, for me, I'm all about the

stability - I think that what we have should work as well as it can, given time.  As you said, it's not as much fun, but I think is better software development policy to debug as you go along, rather than save everything for the end.  That way, when a new bug comes in, you have a better idea of where to start looking (i.e., the most recent code you've added), rather than having the whole program (and all prior-known bugs) be the potential offender(s).

The same goes with the interfaces.  If there's obvious ways we can clean up, optimize, or polish the flightsim interface we have already, we should do that now, while it's fresh on our minds (well, yours anyways... ;-) ).  I'm not saying that we have to code to sqeeze every possible frame out of the interface at this point, but if there's something obvious we can do NOW, we should.  

In short, let's make sure what we have works as well as it can, then move on to bigger and better things.

Combat and Damage: No real ideas yet on that, at least not concrete enough to really start discussing.  However, this might be something we should work on as soon as possible, since combat will be a major part of the game.  I agree that damage should be as System-local as possible (especially, e.g., that a hit to the front doesn't take out the engines for no reason - make it as realistic as possible).  

Systems: I'm learning Python at the moment, and I'm gonna try making some sort of Systems system in Python so we can see how that's going to work.  I don't know how much of a neural network problem it would be - seems like a standard graph connectivity problem, at least to me.  **dusts off data structures textbook**  I personally would put it further down on the list (get some more of the programming aspects of the game up and running), but it seems pretty important to you.  And pretty interesting to me, so I'm up for it.

Artificial Intelligence: We would have to have something worth that intelligence (or at least be working towards it).  I have not seen your code, so I do not know for certain whether an AI at this point is worthwhile / feasible based solely off the demo.  As I said earlier, I would like to try coding an AI, at least a simple one.  We can start making this now, or after we make a combat system, depending on how tightly you want the AI integrated into the game.  Also, I would make it as separate as possible from the main game logic - the NPCs will more than likely running their own separate client-like programs and connecting to the server that way.

GUI: GUI programming is something that I have admittedly have no real experience in.  We might want to get started on that one, if nothing else than to have a menu to select paramaters and options for the game.

Planets: I think Vegastrike's interface to planet landing is fairly good - when you get close enough to a planet, you receive the option to land on it.  If you so choose, then it immediately cuts to after you have landed.  We could also do something where you actually land on the planet, but that's up to y'all.

First-person and Fleet Modes: Since it sounds like y'all have already started on the FPS part, I would say let's do more with that interface first, then move onto the Fleet Mode.  It all depends on what would be easiest to do, and what direction you want the game to go next.

Networking: Admittedly, networking is a weak suit of mine.  I did find that Raknet networking library you metioned.  However, I noticed that the license for the code is shareware / commercial if the project is not released under the GPL.  Since whitelynx said the project is not open-source, then that would require that we purchase a commercial license.  Until we have something a lot more concrete (i.e., we're ready to talk to publishers and get some real money to fund this thing), I don't think we should be looking at commercial licenses for anything.  I know I'm a developer on the game now, but I'm not ready to pay for any libraries this early in development.

There are some alternate projects we could use.  The VOS project is supposed to be using Crystal Space or something like that, so we might could look at them.  I was considering using them for the networking in my game.  However, I'm not up on network programming like y'all probably are, so I'll leave that up to you.  Or we could just add a networking plugin to CS / CEL... :-)

So there you have it.

[whitelynx]

I'll post my two cents here, but then the three of us should move our discussion of the details into the Developers' Discussion forum (that forum is readable by all users but only writable by devs) and leave this thread as a feedback thread for users.

1. I agree that stability should be high on the priority list. Maybe not at the absolute top, but it's definitely something we should keep in mind at all times. However, there are some bugs we haven't found fixes for yet, and since we're stuck on them, it's better to move on and just keep looking for answers in the background instead of letting it consume our time when we could get something else done.

2. Combat is definitely a big one if we're going to try getting something out to actually _show_ people. In my mind this _requires_ systems, because of the implementation of combat. I don't want to code it to work on one type of object and then have to go change everything later to make it work with our new systems implementation. contingencyplan, your help would be invaluable in this area, since it seems like you know a lot more about the type of data structures we need than either Chris or I do. (we haven't taken data structures yet... it's either this coming semester or the one after) Damage I consider part of combat, and the only one left to really consider, since we can already fire missiles.

3. AI or Networking - it's important to have someone to play against. Doesn't matter to me who it is, I just think we need someone to shoot at if we're going to have combat. Chris and I have looked at a few networking libraries, and we can contact the RakNet people to ask if we can have a temporary free license for alpha testing until we get at least a beta out. (they seem pretty open on their licensing) As far as VOS... it's an interesting idea, but I admittedly hadn't given it much thought. I should go take a hard look at it before we choose a networking library. As far as AI goes, its development can start as soon as I get the game back into a running state. We have ships, movement, and firing, so we just need to tag an AI onto one of the ships. As far as your idea of the AI running as a separate client, that would indeed be very interesting, but it would require networking internally to be able to pull it off. (we'd have to have client/server model distinctions in our program first... we just don't actually need the network between them.)

4. First-person, Fleet, and RTS modes - Capital Ship/RTS mode (I think they can pretty much be the same thing) is MUCH easier for me to implement right now, since we don't have any of the physics required to move anything around on the ground. This is also the more complex of the modes, and I feel it should be tackled first. FPS mode is also not the appeal of our game; the flightsim and fleet modes are. I think Fleet mode should be the next thing we tackle once we have combat and opponents finished, as this will show off the type of game Precursors will become.

5. GUI/Menus/Interface - I think we should leave the "prettying up" for later. All we need right now is something to let people control the game, meaning HUD (which should be done concurrently with each game mode) and a main menu. However, we shouldn't worry much about this for the alphas since they're basically testbeds for our methods, and won't necessarily reflect how things work in the final product. This is something that is best left to the later alphas and early betas, when we need to start worrying about interface.

6. Planets - addressing contingencyplan's thoughts on this, yes, we could simply have a cutscene for landing on a planet and separate planets' geometry from the geometry of space, but one of the things we decided on early in development is that we wanted it to be possible for a battle to be fought simultaneously on the ground, in the atmosphere, and in space, and for the different elements of the battle to interact. Because of the complexity of this item and the amount of planning and forethought it will require, I have put this last on the list.

Now, let's hear from the people...

Dave

[fehknt]

yes, let's hear from the people.

Make physics somewhat realistic, Systems, Damage, Combat, AI, Planets, stability, Strategy mode, stability, networking, stability, stability, FP mode, stability, GUI, polish.

now, I put stability in there so much not because I thought it was so terribly important, but because I felt that those were good spots to take a pause on "new feature implementation" and make sure stuff works.  Basically, after you get the first major, workable chunk of the game done, go back over the code, then after each major addition thereafter, make sure things still work like they're supposed to.

Maybe a major beta at each of the mentioned points?

[whitelynx]

Maybe also pause after Combat and after AI to check stability. The reason I think we should break for stability before planets is because it's actually going to be one of the more complex design issues we face, and it would be easier if pre-existing bugs were cleaned up before we tackle it.

Dave

[Chii]

Do I count as the people? Well tough because Chris told me to post some responses. I'll post to what I understand - how's that? Here's my vote:

1.Stability - If you can fix it now, do it unless you foresee problems later that might screw up what you just fixed....keep it clean as you go.

2.Systems - Get the ships to work right before you throw them into ANYTHING.

3.RTS/Capital Ship -If you have systems, you need fleets as well, everything else seems to hinge on this if you ask me.

4.AI - Now you need something to interact with....at least that's what I'd think.

5.Damage - Now that you have the ships working right and something to shoot at, you can figure out how to blow them up.

6.Combat - Now that you can blow them up, it only makes sense to figure out how combat is gonna work. Another reason I put RTS before this is because you want to work that out before you hit combat so nothing changes later because you didn't take that into account.

7.Planets - You can fight - you have something flashy to show people and get them hooked - now get to the rest of the game - the kind of thing that interests people like me - and make it good - make it so you can play the entire game on those worlds if you want so you have a bigger audience playing.

8.Polish - Once you have everything basic down, now you can polish it and give it the final touches so to speak.

9.Networking - Get everything polished and ready to go before you make it so players can actually play.

This is all very basic because my knowledge of this is very basic. I hope this helps. I know how important this game is to you guys.

[fehknt]

@whitelynx: yeah, I forgot what a big deal the planets were going to be...

@Reaka: I like your reasoning, but I think networking should go higher on the list because without it, it's going to be hard to test the game as it gets developed -- it's going to be a online-only game (single player is totally seperate, and will be done later, from what I read), so the ability to test how things work _online_ will be crucial to the testing process, after we can actually interact on some meaningful level (like, attack each other <;o)  ).  Also, I put the RTS later because it's a much different section, but there's no reason it shouldn't be worked on earlier.  Now that I think about it a little more, it may be good to have it earlier rather than later -- but I think AI will need to be done first, becaus you'll have a bunch of computer-controlled ships to order around, and so you'll need the computer to be able to control them, right?  

ALTHOUGH: I see in the future a bunch of pilots flying fighters that the RTS commanders are commanding around, followind orders of a co-ordinator, along with computer-controlled "fillers" for when there's a lack of pilots taking the jobs, fighting around a planet, and eventually troops get landed (mostly computer controlled and automated battles, but if people want to get a high paying job on the front lines where it's really easy to get killed if you don't have good armor (or a tank) then it will actually play out the battle) and then the battle is raging in FP mode, RTS mode and Ship mode, all at once, all interacting, all part of one single, coherent game.

Do let me know if that isn't the direction you are trying to push the game, so that I stop making suggestions about how best to push it towards that path...

[whitelynx]

ALTHOUGH: I see in the future a bunch of pilots flying fighters that the RTS commanders are commanding around, followind orders of a co-ordinator, along with computer-controlled "fillers" for when there's a lack of pilots taking the jobs, fighting around a planet, and eventually troops get landed (mostly computer controlled and automated battles, but if people want to get a high paying job on the front lines where it's really easy to get killed if you don't have good armor (or a tank) then it will actually play out the battle) and then the battle is raging in FP mode, RTS mode and Ship mode, all at once, all interacting, all part of one single, coherent game.

Do let me know if that isn't the direction you are trying to push the game, so that I stop making suggestions about how best to push it towards that path...

No, that is _exactly_ what we've been thinking. We want people to be able to experience the game from any point they wish to. If they want to have one of their characters go to the front lines and possibly get killed, they can choose to do that. If they survive, all the better... they may get promoted, get a pay raise... depends on the organization employing them. (or the military they belong to)

Dave

[Rosencrantz]

I think it should be something like this.

1) Stability. Fix bugs first

2) Networking. This is not from an end user standpoint, but rather from a development standpoint. Granted I have no idea what the internals are like so the client and server sides may already be differentiated enough in the current source that seperating them into executables and inserting network code may be relativly trivial. Anyway, if that is not the case then seperating them into two trunks can easily become a minor headache, and can become worse as you add more features.

3) Systems
4) Damage
5) Combat

And after those I don't really have any thoughts.