»doc flabby Posted May 28, 2009 Report Posted May 28, 2009 Just to start out, this is a critial post, but please don't take it as an attack on discretion, it is far further forward than STF, and i may be wrong, but i would be interested to see the counter arguements. Discretion has a badly designed module system and is also using a C system like on top of C++, which makes is difficult to develop for: - Having separate modules that depend on other separate modules, is not a good idea. - Modules should only depend on the core program, interdepedant modules are a nightmare in design terms. - Would be better to write it all in C++ and use Object Orientation to allow people to extend and contribute classes. - Keeping to pure, modern C++ would make the code more readable and more java/c# like for us newbie coders - It would be also be far better to provide a scripting interface, than use a module interface, for the user side development. Writing in LUA is easier than C++. Most people will just want to create pre-scripted events, or change the graphics of physics behavior on the client side. - It would avoid the need for all the nasty pointers and (void*) casts. - It would be easier to develop and debug. - It would still be easy to extend if you only allowed scripting (i mean everyone has the source anyway), and more control would be retained over the program execution. External modules that run in-process are going to make it simple to add cheat module to the game. However none of these problems are unsummountable, but i think they are the main reasons there has been very little outside help in terms of development with discretion. I've got code already for creating a radar and map screen, from LVL files in c# that could faily easily be translated in to c++, I had a look at how i could add this to discretion..and my mind went...wtf... http://wiki.minegoboom.com/index.php/Listening_for_Key_Presses%2C_Displaying_Text%2C_and_Per_Player_Data its just too difficult for me to work out what i need to do to add them. Quote
Dr Brain Posted May 28, 2009 Report Posted May 28, 2009 I though the whole idea of having client side modules was a very bad one, and sort of stopped paying attention to discretion. It's a huge security risk, after all. I don't think limiting it to scripts would be sufficient, either. Better to extend the protocol to allow more client<->server interaction and make it server side. That fundamental design decision has caused me to pretty much ignore discretion. In response to your C++ notion: All of the truely horrible code I've seen has been written in C++, and I've never seen and *good* code written in C++. I'm sure writing good code in C++ is possible, but it's an uphill battle the whole way. I used to think that having ASSS written in C rather than C++ was a mistake (as I'm a big OO fan), but the more I looked around, the more I realized that objectified C was the correct decision. Quote
Samapico Posted May 28, 2009 Report Posted May 28, 2009 I used to think that having ASSS written in C rather than C++ was a mistake (as I'm a big OO fan), but the more I looked around, the more I realized that objectified C was the correct decision.Why? Quote
Dr Brain Posted May 28, 2009 Report Posted May 28, 2009 Well, for starters, I actually wrote a dynamic loader in C++, and it was awful. You couldn't get any more type safety than C, and the inheritance was limited because everything had to statically inherit from its parent (and you still have the same void * casting in many places). You couldn't utilize any of the real niceties of object oriented programming, because they don't translate across dynamic loading boundaries. Basically, the only benefit from C++ in a dynamically loaded situation is that you can use Class.method instead of function(Struct). Talking with Grelminar, it sounded like he had a similar experience with ASSS. He originally planned to make it C++, but switched to C once he ran into these sort of issues, as C was more natural. Quote
Sass Posted May 28, 2009 Report Posted May 28, 2009 Interesting. I'm still wondering if SS will have much of a population left for new client/zone development. Here's hoping! Quote
»doc flabby Posted May 28, 2009 Author Report Posted May 28, 2009 The problem with dynamic loading C++ classes was part of why it would be better to not have loadable modules at all and to use scripting instead. I agree if you are going to do use dynamic loading, you a are better off sticking to using pure C. (or in the case of more "enterprise applications" use something like COM http://en.wikipedia.org/wiki/Component_Object_Model which is not something i would use unless I had to, for example writing addin programs for MSOffice) My idea with the scripting is that the server would be able to execute scripts on the clients, the clients wouldn't be able to run them by themselves. Basically the server would be able to run custom stuff on the client (so instead of only the graphics it could change a whole lot more, and in a dynamic way) Quote
Bak Posted May 31, 2009 Report Posted May 31, 2009 I agree perplayerdata is poorly designed... I'll probably change it to something better. if you don't like c++, you're welcome to write your modules in pure C. I'm more productive with things like STL, so that's why I chose to use C++. Scripting is a bit of a challenge, although in the long term someone might make a scripting module. In terms of code readability, I find most of the modules easy to read, even the ones I wrote years ago. There are a few exceptions I was thinking about redoing (Chat, most specifically). If the implementation scares you the header files that define the interfaces should be easy to understand, although I do think there needs to be a better system for looking up which module is needed for which functionality (like say I want to pid of the current player, which module should I use to get that information). The void* casts are only at the interface level (unless you use them in your code), in which case you can think of them as a black box that will make your module work. Alternately I think I could make my compiler issue warnings for missing void* casts, but I don't like programs that have hundreds of warnings since it makes it difficult to fine legitimate ones. Quote
L.C. Posted June 6, 2009 Report Posted June 6, 2009 (edited) I believe more people would contribute to Discretion if a secondary dumbed-down "newb" Subgame-clone (accurate and precise) of AS3 were compiled, but with extra settings features included in the ESC+C menu that relate to Discretion/AS3. It would be the same thing as if PriitK had released a major update to Continuum with loads of new features everywhere. I believe that making a dumbed-down edition of AS3 that completely matches to the level of Subgame users despite it's "ultimate lack of flexibility in its original form," (which is psychologically always necessary if you want to reach "lower"/"common" people/player who barely knows enough about computers/software/editors/tools/gaming/etc just to get around with Subgame and no more; would be kind of the same difficulty many computer users may feel when installing Continuum and trying to create a profile for the first time). If you want to move forward and you want to bring newbies/beginners/common players over, you have to talk at their level too -- not just at the advanced level of people who know how to program in languages like C#, C++, Python, etcetera. Subgame is one of the few things that have specially kept the game alive because of it's ease and broad basic coverage of game features. AS3 is more like a complete product through reverse engineering, NOT made by VIE; it's "extra". If every existing copy of Subgame were deleted in 2001 and replaced with the best copy of AS3 today, the population would have taken a greater dip downhill because there wasn't any decent developmental support for newbie players who wanted to just have the basic ability to make and play a map with customized settings of their own (and to some, just basic LVZ to replace shipsets, sounds, etcetera). But with AS3, similarly to Linux, you have to go through a whole series of steps (which happen to be beyond most people's heads [common/newb/beginner people's]), rather than a few simpler, stress-acceptable steps on Windows. I suppose AS3 can do more things with LVZ than what Subgame2 allows as well, is this a correct assumption? It's all extra -- and that's not going to cover the game for easy/newb/beginner/common player people like Subgame does. EDIT :: And I am not attacking AS3 as bad. AS3, like Linux, is an excellent piece of software. But it is designed for people who have the proper experience (programming, compiling software, etcetera) to operate such flexibility. AS3 is the wrong tool in the hands of a newbie, whereas Subgame would be a better, "righter", more appropriate tool. Edited June 6, 2009 by L.C. Quote
Kilo Posted June 6, 2009 Report Posted June 6, 2009 You don't need to program or compile or etcetera to use asss, but that is the way you unleash its full potential. Without those, you have the same thing as subgame, just with a slightly different method of accomplishing the same tasks. So you're mistaken. Quote
»doc flabby Posted June 6, 2009 Author Report Posted June 6, 2009 I believe more people would contribute to Discretion if a secondary dumbed-down "newb" Subgame-clone (accurate and precise) of AS3 were compiled, but with extra settings features included in the ESC+C menu that relate to Discretion/AS3. It would be the same thing as if PriitK had released a major update to Continuum with loads of new features everywhere.I don't really see what any of this has to do with discretion. Discretion could easily be modified to work with subgame as well as ASSS. Quote
L.C. Posted June 6, 2009 Report Posted June 6, 2009 (edited) oh. X-P Fail on my part. Sorry. <_< Edited June 6, 2009 by L.C. Quote
Sass Posted June 7, 2009 Report Posted June 7, 2009 No player will care about new features in as3, subgame, or discretion if we cannot figure out a new game play style that fits with those new features. Right now 2D games only offer so much... Quote
»Lynx Posted June 7, 2009 Report Posted June 7, 2009 (edited) No player will care about new features in as3, subgame, or discretion if we cannot figure out a new game play style that fits with those new features. Right now 2D games only offer so much... Unquantifiable argument. 2D offers as much as our imagination lets it offer, same with 3D. This game wouldn't be what it is now if it was 3D, plus crippling what we can do always spawns more creativity. -L Edited June 7, 2009 by Lynx Quote
Samapico Posted June 7, 2009 Report Posted June 7, 2009 No player will care about new features in as3, subgame, or discretion if we cannot figure out a new game play style that fits with those new features. Right now 2D games only offer so much...People already found a LOT of game play styles with the current limited features of subgame. A lot of people also had ideas that failed for the simple reason that the client or server was missing a few very simple features to make their idea work. Quote
»Lynx Posted June 8, 2009 Report Posted June 8, 2009 (edited) oh sorry, what zone do you run? good day. What? Edit: Dumb answer. Edited June 9, 2009 by Lynx Quote
»jabjabjab Posted June 9, 2009 Report Posted June 9, 2009 Well all i can contribute at this point is my support, and maybe ill play around with servers when this is complete, maybe some gfx or what not. Anyways, i had fun logging into discretion wars on continuum, then getting on the same zone with discretion and checking it out. Most of the weapon and player location things are out of whack, but i could see myself talk on it, and see myself on the player list, which was very neato. Quote
Sass Posted June 9, 2009 Report Posted June 9, 2009 Lynx - my point being this - it's easy to find holes in the notion that 2d is a hard medium for gaming, but stating it like you did emphasizing that we would simply overcome the 2D game barrier as if it does not exist makes us wonder what successes you've had. Beyond just a great idea is the need for total graphics support, total code support, and well - more support than the game has in its current state. We all hope that a great zone will arise from discretion, but it ain't easy. Sorry for busting your chops. Quote
Caster Posted June 9, 2009 Report Posted June 9, 2009 I'll help where I can, used to be good with things like this. Quote
»Lynx Posted June 9, 2009 Report Posted June 9, 2009 Lynx - my point being this - it's easy to find holes in the notion that 2d is a hard medium for gaming, but stating it like you did emphasizing that we would simply overcome the 2D game barrier as if it does not exist makes us wonder what successes you've had. Beyond just a great idea is the need for total graphics support, total code support, and well - more support than the game has in its current state. We all hope that a great zone will arise from discretion, but it ain't easy. Sorry for busting your chops. Yes it is easy to find holes in 2D being your only option for development, but at the end of the day (let's be realistic), how good of a 3D game are we going to get from one or maybe two developers? I see absolutely no reason on creating an entirely new game - [because that is what a 3D game would be - completely damn different to Subspace] when all that is going to require is a shit load more code, for those who are actually going to make zones 3D - a shit load more work, and inevitably a shed load more problems which the community (as development is currently doing) obviously don't have the time to correct. You're asking me what successes I've had? I've administrated zones for a damn long time, therefore know what works in a zone and what doesn't, and I have a good idea of how much more code it's going to take not only for the developer of the project to create a 3D version of subspace, but how much more our current (thin) developer community is going to have to learn to make something woth-a-wank out of it. The simple fact is that only one zone has savvy enough coders to take advantage of 3D - Hyperspace. How much Subspace as a whole will benefit from a 3D spin-off - I don't know.. Time will tell (if 3D ever gets completed to a playable standard), I guess? Furthermore, the as soon as 3D steps into the equation - it's not Subspace. It will lose it's feel completely, so unless you get some damn good addictive gameplay out of it, it won't last. Of course, I say all of this not knowing exactly what kind of 3D you're aiming for... But I think you get the gist of where I'm coming from. If we've still got a for-sure Subspace feel, and maybe some 3D features (which will look... Odd), then it will probably be cool, and if 3D is easy to implement for the newbs, then great.. But again, time will tell. In my humble opinion, I'd say make a Subspace clone first, then work your way up from there. Fixing current bugs, and making improvements where we need improvement. If I wanted to play a 3D shooter - I'd get the XBox alternative. Ultimately, though - if 3D is what is keeping you active on whatever project, then keep doing it. For anything Subspace, only do it if it's fun. If it's not fun, then don't do it. Everything I've seen from any developer so far has been amazing, and I don't intend to cut anybodies morale or anything, just stating what I think... (On a side note to what I already wrote to Sass originally: It is still a completely unquantifiable argument. We've had masses of originality steam from our 2D game, and fuck-loads of improvements over the years. 3D can be a huge improvement, but only if it holds the population and works as it should. Plenty of zones have come out with amazing ideas that have been everything but amazing in practice. Sorry to be blunt, but you drew first blood. -Lynx Quote
Gannon8 Posted June 11, 2009 Report Posted June 11, 2009 Scripting is a bit of a challenge, although in the long term someone might make a scripting moduleBy scripting, do you mean like pymod in ASSS? I could do that, although I might not be able to do all the pyincludes like pymod does. However, it seems like you people are going against modules that work together, so it shouldn't be a problem if I implement everything. Quote
Bak Posted June 11, 2009 Report Posted June 11, 2009 it would untrusted scripts that come from arbitrary servers that run on client computers. It must be very restricted (no examining the filesystem or writing arbitrary files). Something akin the the trigger system in Starcraft comes to mind. Quote
Gannon8 Posted June 25, 2009 Report Posted June 25, 2009 I could add a "discretion" python module, with, say, an AllocateClientFile function to give a file to a module, so that they can store clientside data, then just examine the script for imports of libraries that could harm the system, or we could just restrict imports to using only the math, cPickle, hashlib, and a few other non-system modules. While were at it, lets just rewrite Discretion with python and twisted (jk) Quote
Bak Posted June 25, 2009 Report Posted June 25, 2009 That's still too unrestricted for my taste. We absolutely want to prevent a zone owner from being able to do anything malicious to a client's computer. Maybe it's a better idea to figure out what sort of scripts are desired first then build a system around that. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.