Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Strategy Game Collaboration

Name: =+=*=F=R=O=Z=E=N==V=O=I=D=*=+= !frozEn/KIg 2009-07-19 0:46

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: Anonymous 2009-07-20 10:19

#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

Newer Posts