G33X Nexus Entertainment > Precursors

What is important to the users?

(1/2) > >>

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... :D

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

Navigation

[0] Message Index

[#] Next page