Experimental RTS/Space sim Collaborative Coding Project.
The goal is to design a game with structure/settings/balance of Starcraft and scale of Eve Online(i.e. huge space battles, space empires,etc).
Though this wouldn't stop anyone from contributing code/feedback/criticism, i'll be coordinating the project.
All code/ideas should be posted in this and subsequent threads which i'll start as needed.
step #1: We will collaboratively create a name for our project.
Each suggestion must explain why this name fits the project and why its better then any other generic name.
Name:
Anonymous2009-07-20 4:39
>>156 If your testing is flawed then you'll have bugs no matter what language you use or how many tools you test your code with.
And you think you're somehow going to concoct the perfect testing technique that detects all bugs in the program? The rational thing to do is use languages that don't create unnecessary opportunities to introduce subtle bugs.
Name:
Anonymous2009-07-20 4:46
>>160
But no one except us will know it's a reference, this would be our small ironic metajoke.
Name:
Anonymous2009-07-20 4:50
>>159
You're the worst kind of person. The kind that talks whether they know what they're talking about or not. Enjoy your failure.
>>161
You said it yourself. The testing process should test as much code as possible.
You don't always have the luxury of choosing the language you work with, be it because your task demands it, or because your boss demands it.
Name:
Anonymous2009-07-20 4:52
Haskell: It compiles to native optimized assembly.
It has extensive and concise syntax which would significantly reduce code size.
GHC is free and contains bindings for OpenGL.
Its easy to rapidly develop applications in Haskell.
Haskell is well documented.
Haskell is garbage collected. No memory leaks.
Haskell has efficient bounds checking code.
>>164 Valid arguments, except "easy" which is subjective(no proof given) and "well documented" which is required for any language. Contender #2 is Haskell
______________________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
When you look at the whole life of the planet, we - you know, man - has only been around for a few blinks of an eye. So if the infection wipes us all out... that is a return to normality.
Name:
Anonymous2009-07-20 5:01
>>163 You said it yourself. The testing process should test as much code as possible.
And how did you turn that into, “Reckless language choices are good because there are ways to check for some bugs”?
You don't always have the luxury of choosing the language you work with, be it because your task demands it, or because your boss demands it.
That's not what we're talking about.
--Multi-paradigm programming(functional, imperative, OO, meta-programming). CLOS is one of the best object systems out there and macros allow creating new DSL's languages with ease.
--Fast native code compilers: SBCL, OpenMCL, Allegro and others.
--Existence of compilers which compile to C, in case you want to inline C code, or don't want to have a large LISP image (10-20mb unless a tree shaker is used): ECL
--Quick prototyping is possible, code tend to end up very extensible
--There is no need for a scripting language engine, you can make a quick domain specific language in LISP itself, and script the game in it.
--Wastes less time of filler code, one can just express their ideas directly
- Cons:
--You might have to roll up your own bindings for DirectX, I think there's some for OpenGL, but not so much for DirectX. If you want to interface with external libraries, you'll need to do it for them too ( for example: libpng, zlib, libvorbis, truetype, etc). This isn't a hard task as there are automated tools for doing this.
--The language offers many features, and a novice programmer could make parts of the code hard to maintain, but this is true for other languages too.
--Large image size for true native code compilers, unless a tree shaker is used, if that bothers you, you can compile directly to C.
--Language is not known by a lot of programmers. Finding new developers might be hard.
The main problem here is that you will have to write enough code to get people interested, and I have no idea if you know LISP well enough.
C#:
- Pros:
-- Well known in the public, attracting developers would be easier.
-- Easy to use DirectX bindings.
-- I've seen a couple of 3D games made using C#, speed was very decent. Just because your .net executable runs 3 times slower than the C++ equivalent doesn't mean it will matter much, you will be spending a lot of time executing native code (graphics, sound, i/o) which is already optimized. The game logic will execute slower, but there are many possiblities for optimization and dropping in to run native code isn't hard ( for speed critical parts ). Machines are fast enough nowadays for this to not matter much, besides a Starcraft clone is not likely to need as much resources as Crysis.
- Cons:
-- Expect having to code a lot of repetitive boilerplate code, but not as much as needed in C.
-- Lower speed than native code, but not enough to matter.
-- Some OSS coders hate C# because it comes from MS, even though there's Mono. Java is an alternative, but it's worse.
C++ is the natural choice in the industry, due to being possible to use OO, which while I don't consider the natural solution to all programming needs, is a very natural way of representing a game world. It also retains C's speed to some extent(of course too much OO wankery can be slow, I've seen a case of a C# written clone of one game which was originally written in C++, and the C# game was much faster and responsive. It just shows that properly designing a game and using the right (fast) algorithms will give better speed than using a slow algorithms with a fast natively compiled language.
I don't see how this discussion has much of a point as you need to know the language before you can chose it, it's not like /prog/ will code for you, unless you make it interested enough: present a working prototype with a good enough codebase.
>>169 3 valid arguments for Lisp:
*Extensible macros/syntax
*Quick prototyping
*Fast native code compilers
C# - require Runtimes.
C++ - No valid arguments.
Contender #3 LISP.
_______________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
There are periods in the life of human society when revolution becomes an imperative necessity, when it proclaims itself as inevitable.
We have reached 3 languages for review: Scheme, Haskell and Lisp.
Anyone like to contribute more?
______________________________ http://xs135.xs.to/xs135/09042/av922.jpg
How do ideas come? What a question! If they come of their own accord, they are apt to arrive at the most unexpected time and place. For the most part the place is out of doors, for up in this northern wilderness when nature puts on a show it is an inspiring one. There seem to be magic days once in a while, with some rare quality of light that hold a body spellbound: In sub-zero weather there will be a burst of unbelievable color when the mountain turns a deep purple, a thing it refuses to do in summer. Then comes the hard part: how to plan a picture so as to give to others what has happened to you. To render in paint an experience, to suggest the sense of light and color, air and space, there is no such thing as sitting down outside and trying to make a portrait of it. It lasts for only a minute, for one thing, and it isnt an inspiration that can be copied on the spot...
Name:
Anonymous2009-07-20 5:25
>>166
>And how did you turn that into, “Reckless language choices are good because there are ways to check for some bugs”?
Like I said, you don't always have many choices. Any sort of protection at run time against crashing bugs comes at the cost of performance. If part of your task description is "the result has to be ready in this many microseconds" you'll want to save as much time as possible, rather than waste it on automatic processes you can do yourself.
No one is saying this is always the case. Writing a payroll program in Assembly would be moronic. This is why we have so many languages available.
And, of course, like >>169 said, the choice of algorithms is also the difference between an exponential loss in a linear gain, and an exponential gain in a linear loss.
What the fuck? FrozenVoid hates Haskell and Lisp, check the other threads. He only codes in eye-raping non-indented C which looks like javascript. You are going to get trolled hard.
>>173 The language chosen would be most suitable for /prog/ not for me.
If you all agree to program in e.g. haskell and haskell is suitable for the project it will be chosen as development language. My personal preference are irrelevant here.
_____________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
Why do you insist that the human genetic code is "sacred" or "taboo"? It is a chemical process and nothing more. For that matter -we- are chemical processes and nothing more. If you deny yourself a useful tool simply because it reminds you uncomfortably of your mortality, you have uselessly and pointlessly crippled yourself.
Name:
Anonymous2009-07-20 7:08
174 posts later, no work is done.
None of you faggots can do proper code anyway, you're all just a group of masturbating monkeys yanking it to toy languages.
>>175
It took you that long to realize this? What a retard
Name:
Anonymous2009-07-20 8:38
Use C.
Good things:
* Everyone knows C.
* C has a lot of libraries.
* Speed for path-finding.
* It's the standard for open-source software.
* Patches to C code look better than with Haskell or LISP.
Not so good things (maybe):
* No portable binaries (but we are in /prog/ after all).
* Cross-platform code can be annoying in some cases (with a proper set of libraries it should not be a problem).
>>175
We have chosen the name and a short list of viable languages. That's about one and a half steps out of 10 proposed, so actually we have done almost 15% of the work!
From that we can estimate that we'll need only 6.66 days and 1166 posts to make a full-featured "Frozen Void: The Game".
>>178 Ok. C has the benefit of fastest speed. 4 contenders:
#1 Scheme
#2 Haskell
#3 Lisp
#4 C
______________________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
We are all looking for emotions, basically. It's only a question of finding the way to experience them
>>180 Actually each step is exponentially longer then previous.
______________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible.
lets build a feature tables to better access viability of these languages
Language Syntax Ease Speed Libs Bugs (rate on scale 0/10 - 10/10)
-----------------------------------------------------------------------------
#1 Scheme
#2 Haskell
#3 Lisp
#4 C
____________________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
Justice is not revenge - it's deciding for a solution that is oriented towards peace, peace being the harder but more human way of reacting to injury. That is the very basis of the idea of rights.
#1 Scheme
Syntax:
Lisp like, very simple, easy to learn, flexible.
Syntax can be extended through syntax-rules, but not as much as you can do in Common Lisp. 8/10
Speed:
Fast with a good native compiler, but it's easy to write very slow code if the coder is unexperienced. 7/10
Ease:
Code is easy to write, but lack of libs means you have to roll a lot of your own code. 7/10
Libs:
Language is minimalistic, you have to code almost everything yourself, lack of true macros makes it less extensible than Common Lisp. Many user-made libs. 5/10
Bugs:
It's garbage collected and safe, bugs are usually logical errors. Typing is lose, more possiblities for bugs are possible at runtime. 8/10 ( higher score means less bugs )
#2 Haskell
Syntax:
Powerful syntax, but somewhat complex. 7/10
Ease:
It's purely functional and strongly typed, and this can cause trouble to people who are not used to thinking in this way, and in some cases, it may even get in your way. 5/10
Speed:
Can be faster than Scheme or Lisp as long as the programmer knows what he's doing, but it's very easy to write slow code.
9/10
Libs:
Many user made libraries, but a lot are not mature enough.
8/10
Bugs:
Safest from the list.
Garbage collected - hard to leak memory, but easy to write recursive code which overflows the stack.
Strong typing and purely functional style weed out many possible bugs, but some other kinds of bugs are more prone to happen. 9/10 (safest)
#3 Lisp
Syntax:
Everything is a list, very simple syntax, but reader macro characters can make things a bit more complicated, especially if you're talking about macros with nested backquotes. Syntax can be extended to be anything you want it to be. 9.5/10
Ease:
It's very easy and natural to code in, but it's possible to write unmaintainable code if someone is doing bad things on purpose.
9/10
Libs:
ANSI Common Lisp is large and flexible, but it doesn't include everything. There are many user-written libraries, but don't expect to find everything, you may have to write or import foreign(written in C for example) code via FFI. Some portability problems when using FFIs can exist. 8/10
Bugs:
Garbage collected, but weakly typed (not in the bad PHP way).
Recursion/functional style is not enforced, there are loops, but the standard does not gurantee tailcall removal, however, most implementations do that. Debugging bugs in macros can be slightly hard.
The condition system is excellent, allowing for very easy recovery from errors. It's more bug prone than Haskell, just because some bugs are caught at runtime(due it being weakly typed), and not at compile.
8/10
#4 C
Syntax:
I don't find it hard, but you have to write a lot more boilerplate code than Scheme/Haskell/Lisp. It's a low level language, that's to be expected. No easy syntax for strings and other common things.
If your goal is writing low level applications 9/10, if the goal is to write high level applications 5/10.
Ease:
Low-level: 8/10
High-level - 6/10
Way too much work required to write complex games.
Speed:
Fastest out there, except if you rewrite the routines in assembly. It's not hard to write fast C applications. 10/10
Bugs:
Memory leaks, buffer/heap overflows, and all other kinds of bugs that you can think of are possible. Unless properly designed and thought over, you may have to spend years fixing a large codebase. 3/10
>>185 Let me to summarize your opinion
Language Syntax Ease Speed Libs Bugs
-----------------------------------------------------------------------------
#1 Scheme 8 7 7 5 8
#2 Haskell 7 5 9 8 9
#3 Lisp 9.5 9 ? 8 8
#4 C 5 6 10 ? 3
__________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
Man's unfailing capacity to believe what he prefers to be true rather than what the evidence shows to be likely and possible has always astounded me. We long for a caring Universe which will save us from our childish mistakes, and in the face of mountains of evidence to the contrary we will pin all our hopes on the slimmest of doubts. God has not been proven not to exist, therefore he must exist.
>>185
Lisp:
Speed - Fast native code compilers, but easy to write slow code. Professional LISP development has usually 2 stage:
1)Prototype - may be slower at first as more runtime checks are built in. 6/10
2)Optimize - add type declarations, improve algorithms, use less costly data structures. 8-9/10
____________________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
The facts we see depend on where we are placed and the habits of our eyes.
Name:
Anonymous2009-07-20 11:09
>>185
It is possible to write fast code in Haskell, but that code is often ugly and harder to work with.
Name:
Anonymous2009-07-20 11:14
I'd like to suggest C++ as having basically the same ratings as C, but with a more complicated syntax and a greater ease to write higher level programs thanks to the STL. The speed is the same, any C library is also a C++ library, and it has the same bug proneness.
_________________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
There are two kinds of scientific progress: the methodical experimentation and categorization which gradually extend the boundaries of knowledge, and the revolutionary leap of genius which redefines and transcends those boundaries. Acknowledging our debt to the former, we yearn, nonetheless, for the latter.
Name:
Anonymous2009-07-20 11:33
>>192
C++ is horrible for collaborations. Enjoy having some guy use craazy shit like classes.
>>195
Yes, all the languages in that list except C have features which allow you to abstract better and save time, I'm not even talking about OOP here. Code can be made unmaintanable by an unexperienced programmer, but would coding everything in C be that much better? You'll have to write a lot more boilerplate and repetitive code than in the other languages. It may be true that everyone will understand it, but at the same time, it will take much longer to write and maintain, not to mention that keeping programmers interested full time would be a challenge.
>>196 Coding in C/C++ is bad for large projects,
most programmers won't produce usable code: it will have to be debugged and checked many times.
I don't blindly advocate C, just because i know it. Its a hard language to develop in.
________________________________________ http://xs135.xs.to/xs135/09042/av922.jpg
Doctor, will you tell these fools? I'm not crazy. Make them listen to me before it's too late.
Name:
REPOST OF ROADMAP2009-07-20 12:39
#1 naming the project. Unique,non-copyrighted name which sounds good.
#2 choosing a Language/Library platform from which we will code the project.
#3 choosing a common compiler toolkit, so that everyone uses the same version of design software.
#4 Creating or reusing existing engine into a space simulator.
#5 Adding physical effects and game features into simulator, until playable demo (single ship) is working.
#6 Adding player interface and dialog systems.
#7 Adding multimedia assets,character designs and unit textures.
#8 Multiplayer support.
#9 Distributing the alpha/beta via Sourceforge/Megaupload/Rapidshare/etc
#10 polishing the game so it has balance,intuitive interface and free of bugs.
I have read this thread. FV which of these goals have been completed?