Server Help

Trash Talk - Designing a new settings system (aka esc+c)
Doc Flabby - Sun Jan 27, 2008 10:10 am
Post subject: Designing a new settings system (aka esc+c)
I'm trying to design a new settings system (using ASSS).

My question is this. Anyone got an idea of how I could do this?

Its needs to work in a generic way.

definitions:
ship - player controlled object (central in screen)
npc - computer controlled object. (ie sonething players can interact with)

There is no limit (or at least the limit isvery high) to the number of ships/npc.

Each object/ship has abilities (e.g. this would be the weapons, repels, rockets, thrust). These abilities can be used on one or more object/ship.

The behaviour and abilities of the abilities and ships would be linked to a binary module run on the client. Thus they are dependant on the "mod" loaded on the client. However server abilities would be controlled on the server. So there are really two type of settings, those that affect the server and those that affect the client. I'm suggesting these would be separated.
Dr Brain - Sun Jan 27, 2008 10:39 am
Post subject:
I'm sorry.... what's the point of this?
Doc Flabby - Sun Jan 27, 2008 10:45 am
Post subject:
Dr Brain wrote:
I'm sorry.... what's the point of this?

Its for TCP http://www.ssforum.net/index.php?showforum=398, and its, to allow different physics models and weapons.

for example. One module might limit someones movement to two directions, and the settings would have to reflect that. Another module might allow 5 different weapons on a ship, another only 1. These modules are clientside, but would still need to download settings from the server. This is where a new settings system would come into play. As the current system is too restrictive (unless anyone has idea of how i could adapt it not to be, i might be being stupid)

The server will simply send the settings to the Module specific settings to client, it won't care what they are
Dr Brain - Sun Jan 27, 2008 12:11 pm
Post subject:
ASSS isn't (IMO) well suited to other non-continuum clients. Too many of continuum's quirks are tightly integrated into the core.
tcsoccerman - Sun Jan 27, 2008 12:19 pm
Post subject:
doc you are talking about in-game right?

i suppose we could have a treenode setup. a node foreach ship/weapon/ability which then expands to that items settings.
Doc Flabby - Sun Jan 27, 2008 1:11 pm
Post subject:
Dr Brain wrote:
ASSS isn't (IMO) well suited to other non-continuum clients. Too many of continuum's quirks are tightly integrated into the core.

I think I would have this problem with any server. Its how to express the data in an extensible and flexible way. Basically I need to create a file format where the server uses some of it, and send the rest of it to the client, only the content depends on what modules the client has loaded. arge. Its difficult to explain.

No i'm really talking about the behind the scenes stuff, where, the settings are transfererd from server to client.

The treenode idea is good tho, a tree structure might be the answer....
Dr Brain - Sun Jan 27, 2008 10:16 pm
Post subject:
Any recursive hierarchical structure can be represented as a tree.
Goldeye - Mon Jan 28, 2008 12:05 am
Post subject:
Why doesn't "TCP" work off of discretion? It's probably the best on-track client.
Doc Flabby - Mon Jan 28, 2008 5:17 am
Post subject:
Goldeye wrote:
Why doesn't "TCP" work off of discretion? It's probably the best on-track client.

Because TCP is not a subspace/continuum client.
Cheese - Mon Jan 28, 2008 8:14 am
Post subject:
tree idea good
seconded
Dr Brain - Mon Jan 28, 2008 8:21 am
Post subject:
My point is that a tree isn't an idea.
Goldeye - Mon Jan 28, 2008 10:01 am
Post subject:
Doc Flabby wrote:
[..]


Because TCP is not a subspace/continuum client.


Is it not a project surrounding a client for a game based upon subspace/continuum with a first goal of matching/replacing said clients?
Doc Flabby - Mon Jan 28, 2008 11:30 am
Post subject:
Doc Flabby wrote:
[..]
The treenode idea is good tho, a tree structure might be the answer....

Dr Brain wrote:
My point is that a tree isn't an idea.

Pedantic but, The "idea" in this context is to apply the use of a tree structure.
Goldeye wrote:
[..]
Is it not a project surrounding a client for a game based upon subspace/continuum with a first goal of matching/replacing said clients?

Prehaps you should read the projects aims topic. http://www.ssforum.net/index.php?showtopic=18804
The project is not just a client, but a server and associated support services project as well. The idea is to create a platform, on which games can be created, in this aspect it is similar to SS. Where it will differ is the power and customisability of that platform with support for modern graphics (3d accelerated) and a multitude of OS choices.
Anonymous - Mon Jan 28, 2008 1:20 pm
Post subject:
Doc Flabby wrote:
[..]


Prehaps you should read the projects aims topic. http://www.ssforum.net/index.php?showtopic=18804
The project is not just a client, but a server and associated support services project as well. The idea is to create a platform, on which games can be created, in this aspect it is similar to SS. Where it will differ is the power and customisability of that platform with support for modern graphics (3d accelerated) and a multitude of OS choices.


ASSS can readily be modified to support more and more aspects of the game as it's made. Most importantly, it is, for most intents and purposes, finished.
Discretion is designed for all POSIX OS + windows, with an architecture that is hopefully satisfactory for open expansion, which can probably be 3d accelerated through SDL pretty easily as well. (Though admitably I don't think it is built this far for 3D physics, it's still easier to work that in than work from scratch.

Not trying to say Discretion>TCP, and I don't know how far TCP is, but
a. why start a server from scratch when ASSS is there and begging to be modified
b. why not try to work on a coordinated client effort?
Doc Flabby - Mon Jan 28, 2008 1:33 pm
Post subject:
Goldeye_not_logged_in wrote:
[..]
Not trying to say Discretion>TCP, and I don't know how far TCP is, but
a. why start a server from scratch when ASSS is there and begging to be modified
b. why not try to work on a coordinated client effort?

TCP is written in c# and openGL which is cross-platform (windows, linux,macOS) compatible.

I really suggest you read, and understand what the project is. Alot of these questions i've already answered tongue.gif

a. I am using ASSS, which i am modifying, extensively.
b. I can't code in C++ (i can only just about manage C), which counts me, and numerous others out of any discretion development.
Cheese - Mon Jan 28, 2008 2:55 pm
Post subject:
cpp is ez, flabby :(

go learn it, takes like an hour :/
tcsoccerman - Mon Jan 28, 2008 3:52 pm
Post subject:
it doesn't take an hour...
BDwinsAlt - Mon Jan 28, 2008 5:32 pm
Post subject:
Cheese wrote:
cpp is ez, flabby icon_sad.gif

go learn it, takes like an hour :/


The type of coding he is talking about is a lot more than simple mervbot plugins. It's an entire game with physics and several conditional things that go on. It's like trying to dictate chaos. It isn't just sending a message. It's display graphics, changing velocity, and sending packets back and forth. That kind of c++ isn't something you learn in an hour. If that was the case, there would already be a completed client that works just like Continuum.
Goldeye - Mon Jan 28, 2008 10:58 pm
Post subject:
If you can code OOC in C#, you can code OOC in C++ with only a bit of syntactical learning. You probably need to know C (I don't believe C# has you syntactically dealing with pointers ever?)

If you can code in C, C++, or C#, you can manage mostly anything in any of them but fancy dealings with classes
Samapico - Tue Jan 29, 2008 11:30 am
Post subject:
Anyway, the C++ issue is irrelevant. He said that to justify that he can't really help Discretion.
Doc Flabby - Tue Jan 29, 2008 11:41 am
Post subject:
Goldeye wrote:
If you can code OOC in C#, you can code OOC in C++ with only a bit of syntactical learning. You probably need to know C

There in lies my problem.

c# has no concept of pointers (except in unsafe) and you don't need to emory manage.
Samapico - Tue Jan 29, 2008 12:59 pm
Post subject:
pointers are cool to work with, though. Once you understand them, you know exactly what's going on in your program. Even in C#, sometimes you're not sure if a parameter is by value or by reference, and it can be confusing...
Animate Dreams - Tue Jan 29, 2008 1:22 pm
Post subject:
Lol, it took me a while before I realised TCP was The Continuum Project, and not a protocol.... but anyway. Doc, I'm sure that by the time you're through with all the AS3 modifications you'll have to make, you'll have a pretty good idea of how to use C and pointers. Most of what I understand about how to use pointers came from AS3.

As for the tree structure, would the "nodes" be based on things like, guns and bombs(possibly in one category, Weapons), ships, items, etc., or would it be separated based on the module they came from? The latter makes more sense to me. Since a module, I assume, would be flexible enough to do something like create a new weapon, you could very likely end up with cases where a single module would add a few settings under Weapons, a new setting under Ships, new settings under Items, etc....

It makes me think of when I try to use Linux. Let's say I install Linux and it comes with Apache, or I add it with the package manager. It puts the binaries somewhere under /bin, the documentation under /docs, the config files who knows where, etc. To someone experienced with Linux, I'm sure it makes sense to them and they have little problem finding the files they need. But I prefer installing it myself so if I want a config file, I just go to /apache/config, or bin files in /apache/bin, etc.. I don't know if anyone else is bothered by things like that, but I am. From a developing standpoint, if I install a new module, I'd like to be able to esc+c and go straight to the module's settings and set them all.

As that's likely a matter of personal preference, I have another idea. I don't even know if it's plausible, but I'd like to propose it anyway. Settings could have labels. If you create a module, um... I don't know, TimedBomb, you'd have settings like TimedBomb.TimeToExplosion, TimedBomb.BombSize, or something like that. The settings could have labels like Type:Weapon and Module:TimedBomb. That way, you could sort by Module and scroll to TimedBomb, or sort by Type and scroll to Weapon. Obviously, if there was some item that came along with the module, its Type label would be Type:Item instead, and would show up under Items instead of Weapons. I haven't spent much time actually thinking about this, so I have no idea what different types of labels settings would need, or anything, but I think you get my idea. This way, different developers could sort their settings in different ways on the fly.
tcsoccerman - Tue Jan 29, 2008 5:10 pm
Post subject:
the nodes will not be based on modules, but based on files in an indicated folder (/ships, /weapons).

the zone creater will make those files, defining characteristics about each weapon. there won't be modules for each weapon/ship because that would make you need to know how tocode to make 1 ship in you're zone. that would be a great option though to be able to code a ship/weapon/ability rather than be limited by the editor that is given.

as for the last paragraph, alli can say is that you won't make modules to make a ship/weapon/ability, you'll make a file(ship/weapon/ability) with a given application.


that's how i understand it, and invision it.
Animate Dreams - Wed Jan 30, 2008 1:12 am
Post subject:
tcsoccerman wrote:
the nodes will not be based on modules, but based on files in an indicated folder (/ships, /weapons).

the zone creater will make those files, defining characteristics about each weapon. there won't be modules for each weapon/ship because that would make you need to know how tocode to make 1 ship in you're zone. that would be a great option though to be able to code a ship/weapon/ability rather than be limited by the editor that is given.

as for the last paragraph, alli can say is that you won't make modules to make a ship/weapon/ability, you'll make a file(ship/weapon/ability) with a given application.


that's how i understand it, and invision it.


I really don't understand what you're saying at all.
tcsoccerman - Wed Jan 30, 2008 8:50 am
Post subject:
that's ok.
All times are -5 GMT
View topic
Powered by phpBB 2.0 .0.11 © 2001 phpBB Group