Bay 12 Games Forum
Dwarf Fortress => DF General Discussion => Topic started by: ChJees on August 15, 2008, 07:06:06 pm
-
How many programmers exists on this forum ???
Starting with me.
-
Me. Are you wondering if a large portion of DF players are programmers? I suppose it's likely.
-
I do Flash.
-
Yo.
Currently workin as a Senior Creative Developer.
-
I do web development. It's not really related to DF though.
vb.net and C#.
-
Two years at Uni with HTML, CSS, Actionscript, PHP (although I haven't touched it in years), SQL, Javascript. About 2 years with Python, although I'm horribly out of practice. Knew enough Visual Basic in High School to do a Dating Sim game for my final year software project. Knew enough of C++ once upon a time to know that it would crush my soul forever.
Currently relearning Python and glancing over C# (for the purposes of dabbling with XNA at some point)
-
I tried, I really tried.
I took some programming courses in high school and failed out of all of them. Just couldn't get into it.
I'll leave programming to the programmers while I draw pretty pictures.
-
I am.
I do professional game development - BSc, just over 5yrs of C++ (2yrs professional), and various others for tools, hobby projects, etc.
I'm thinking there are a LOT more of us on here. :P
-
Full time software engineer here. Currently that's full time education software, maybe full time games some day ;D
-
Name a language that isn't esoteric, Flash, Python or Objective-C and I probably can write some programs in it. As long as it isn't esoteric, I can probably write a hello world program in it, provided I have previously read code written in the language.
Assembly language is a special case, I know a few variants (x86, x64, PIC), but there are many more I don't know. Optimization is a whole other story...
I have no life.
-
Piet (http://www.dangermouse.net/esoteric/piet.html) is one of my favorite esoteric languages.
-
I do perl, c++, and a lot of database stuff.
-
I noodle around with C++, SDL and OpenGL.
-
Attempting to learn Python. Not much progress yet, though.
-
Nothing professional, though I have played with various languages since I was about 10, starting with BASIC on a Commodore 64. From there: Pascal, C/C++, VB, Java, Javascript, SQL, Oracle, C#, and Python. Right now I'm focusing on C++ and Python.
-
I do Flash.
Huzzah! Flash here to!
Although I can't really do much with it. I tried to make a space shooter, but things.. don't fall into place. Also, a total brick wall with tiles.
-
I've actually managed quite a bit (http://www.kongregate.com/games/Draco18s/dragon-run?referrer=Draco18s).
-
Python is my favorite, though I spend more time in Matlab lately.
-
C++, OpenGL, perl ;D
-
Sort of an aspiring student programmer. I've probably been programming for about... five or six years? But I only got into it seriously a few years ago, back then it was just minor things.
C++, (Spidermonkey) Javascript, Python. Quite a lot of us here... interesting.
-
We should totally do a game together. I'm thinking... a Dwarf Fortress Kart game ;) Or a First-Person Elf Shooter (as in, you shoot Elves, not play as them)
-
Here's my resume :P
10 years of programming: Basic, C, C++, C#, Java, Common Lisp, Scheme (functional langs FTW), Lua (my fav. scripting lang), and several other minor scripting languages like CLIPS.
Did some programs in x86 assembly language but I mostly forgot about it.
Haven't programmed in Piet but I'm also a fan of it.
I even have designed my own prototype language (a mix between a functional lang and a declarative lang like Prolog) and written lousy interpreters for it. That's how hardcore I'm about programming :P
Also, I'm all for collaborating on a game project: I specialize in AI, game logic and complex algorithms.
-
IT Engineering student here. 'nuff said. :)
-
I'm one as well. It consultant, so I will do anything as long as you pay for it ;)
But i prefer C# though.
-
Common Lisp programmer here.
-
Meh - tried programming but it's not my cookie after all. I'm all for design etc and I am going to hunt for capable programmers (and a modeler/animator or two) in the future once I'm done with writing up/designing a project that I will want to realize eventually (which will be a several-years long project obviously).
-
Hi!
Ambitious amateur with too short an attention span, I guess. I have dabbled with various languages and specialized languages/game engines over the years. No real completed projects, even though I feel at home in the terrain (^_^;;
Deathworks
-
I write code. Not exactly programming. I'm an aspiring engineer by profession, a game making guy by hobby ;)
-
C++, Java, C# are my main languages, and C++ is my strongest skillset.
I can write VB.NET too, due to the .NET framework being so standardised, but it takes a wnile for my brain to get into the right syntax mode.
I also could probably write classic BASIC if I had to. Used to love that language as a kid.
-Angry Lawyer
-
Interesting :).
I wonder what would be if all of the programmers here would team up and do a Dwarf Fortress Tool\Utility :P.
-
We'd all strangle each other over commenting styles.
-Angry Lawyer
-
i am studying informatic too ...
but make something for DF is hard i don't realy beliv it is a code i thing it is something new that evolving by himself and Toady is an AI hows personality it is using for caverage :D
-
C++ Game developer, some SQL. Currently working for a company that make MMOs and MMO middleware.
Give me any API that works with C++ and I can probably use it.
Working together could work during the following critera, we find something that all the programs can comunicate by. We plan and structure in detail what data should be sent between components.
Everyone works on their own component where noone is allowed to complain whats going on as long as the component gives the data specified. ^^
And no, I still wouldn't be intreseted. But that could work. ^^
-
But then you'd get the "Why" issue. Why would a program that imports heightmaps need to communicate with one that simplifies sticking bodyparts together?
-Angry Lawyer
-
All in one app?
Or why not just make a huge package of separate Applications and one "Launcher" application :P?
-
I know ruby, VB.NET, C#.NET. I'm going to a programming school next year.
So far, my favourite part is to build up AI, and DF literally made me fall in love with emergent gameplay ;D
-
/me too
I'd love to see toady open up the game a bit more, so all this potential doesn't have to get wasted by searching for memory addresses ;p I'm not saying "open source", more like GUI API - see WoW e.g.
-
I do data analysis in a large corporation - I do some coding in SQL and some scripting/ visual basic for applications (MS Access), and database development, macros.
I don't consider myself a 'real' programmer, but I certainly no a few things.
-
I tried to teach myself Python at some point but I just don't have the patience for it.
-
I know enough FreeBasic to be comfortable with learning more, if that makes sense. Right now I'm waiting for them to improve their OOP support before continuing a project I'm writing in it.
-
Electrical engineer here, but I do code as a hobby and a tad for work. I'm one of those terrifying hardware-guys-that-knows-just-enough-code-to-screw-everything-up. I favor Python and Java on my own time, and use bog-standard C for work.
And yeah, a real API for apps would be awesome, because I think there are far more of us that would be able to code something with an API that are a little out of our depth when we have to do the memory address hunt and peck.
-
Interesting :).
I wonder what would be if all of the programmers here would team up and do a Dwarf Fortress Tool\Utility :P.
Quote Zen Programming: http://www.canonical.org/~kragen/tao-of-programming.html (http://www.canonical.org/~kragen/tao-of-programming.html)
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''
``It will take one year,'' said the master promptly.
``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''
The master programmer frowned. ``In that case, it will take two years.''
``And what if I assign a hundred programmers to it?''
The master programmer shrugged. ``Then the design will never be completed,'' he said.
-
I've been programming professionally for fifteen years. I do C# almost exclusively anymore (and all the bits and pieces that go with it). Of that, ninety percent is probably designing rules and prediction systems.
-
I've been programming unprofessionally for the last eleven years. I recently got a job working on a commercial MMO, but due to my non-disclosure agreement, I'm not allowed to say which... =P
I'm versed in C/C++, Java, PHP, Python, Ruby, DM, JScript, HS, and a bunch more languages I don't even care to mention.
I think this game attracts people of an intellectual nature, and not just that aspect keeps us around, I believe it's the urge to create that really draws people to this game.
There are really two types of gamers, those that love destruction, and those that love creation. The latter seem to be much less common, which is why DF is such a Niche game.
-
I'm mostly self-taught having learned C++ and C# on my own but having also taken two one-semester courses in program design consisting of a little of everything from the basics up to threading. For the most part I've stuck with C++ however I'm trying to learn C# with the goal of getting into XNA 3.0 when it is released at the end of the year.
I recently got a job working on a commercial MMO, but due to my non-disclosure agreement, I'm not allowed to say which.
If the MMO is Flyff, say hello to Deadlydata and SilentX when they next hack your servers. I hear they've been doing that a number of times in the past few weeks. ;D
-
And yeah, a real API for apps would be awesome, because I think there are far more of us that would be able to code something with an API that are a little out of our depth when we have to do the memory address hunt and peck.
I attempted that, see: http://www.dwarffortresswiki.net/index.php/User:Jifodus/Dwarf_Fortress_Utility_Framework
However, at the moment, it's currently on my backburner pending a working automatic address locator; since I learned that maintaining the complex structure format was a real pain. OTOH, it also was the most flexible, and an easy-to-use engine.
-
We'd all strangle each other over commenting styles.
...you comment your code?
-
We'd all strangle each other over commenting styles.
...you comment your code?
(http://divisionstreet.files.wordpress.com/2008/05/no_comment.jpg)
-
Self-taught C, C++, PHP, Perl, all of which was expanded upon by currently attending College. Thanks to school, I also know Javascript, HTML, CSS, and M68000 assembly.
I am also capable of adapting to and learning any language put in front of me within a few weeks at most.
Currently, in regards to APIs, I am mostly self-teaching myself the OpenGL API currently. I am also looking into Linux software development and other more complex things.
-
C++ and Python, self taught and a bit of schooling. Just finished making the Python UI for Civilization4: Colonization. Would love to re-write this game UI from scratch. The pages and pages of responses are rather clear that this game attracts a programmers like a moth to a flame (learned about it myself from another programmer as I suspect many others have).
-
[...]
There are really two types of gamers, those that love destruction, and those that love creation. The latter seem to be much less common, which is why DF is such a Niche game.
I like to build things to blow them up. I actualy planed to make a game where you build a structure, then people and explosives are randomly placed, then you take responsibility for guiding a character trough the inferno to help survivers.
-
Self taught mishmash of web and application languages (no database languages yet though now that I am learning PHP I need to change that).
-
Aspiring programmer here.
I've done things primarily with Java, I'm learning C++, C# and Python though. I also know a good bit of SQL.
-
I myself is self taught :P.
I know PHP, C++ and some SQL.
-
I've forgotten more about programming than I'll probably ever relearn.
That being said, I downloaded Visual Studio 2008 Express C++ and the DirectX SDK the other day, so maybe its time to test that theory.
-
Mostly self-thought semi-professional Virtools programmer, and knowing the basics of of C++, C# and PHP.
And getting a Master's degree in Game Design this year.
-
Java mainly, but also C++, C# and Delphi.
-
Not programming much at the moment, but I've been a programmer for 20 or so years, the last 10 in professional game development (N64, PS1-3, Xbox, 360). Primarily C++.
-
I'm a freelance programmer.
-
I program telemetry devices, mostly in Python.
-
I'm a webmonkey, so I end up working with perl, php, javascript, and SQL mainly. I work for a small 30 person company that does not have a technology focus, so I do all the client-facing webstuff as well as the care and feeding of all the internal servers and employee machines. While being able to make all the tech and purchasing decisions is cool, it's also means if I'm swearing at myself when I go "Who programmed this mess?", "What idiot decided to go with this vendor?", etc. (Fortunately that doesn't happen very often.)
I also know enough Python, C, C++ and Java to be dangerous, but being a webmonkey and sysadmin is what pays the bills.
-
Yo, I do C++.
Tis very fun.
-
One more here. SDET Java and Flash.
-DB
-
I'm currently employed as a programmer of scientific simulations (as well as programming as a hobby). I know C/C++, Java, C#, JavaScript, FORTRAN, x86 ASM, and lua.
-
I programmed ASCII Pong in Pascal, but beyond that, I have preeeetty much zero experience.
-
I make 3D simulators for a living (not by myself mind you), although my background is in applied physics. Mostly programming in C++, but I like Fortran and python as well.
-
I make 3D simulators for a living (not by myself mind you), although my background is in applied physics. Mostly programming in C++, but I like Fortran and python as well.
Got any negative refraction paperweights yet?
-
...
Got any negative refraction paperweights yet?
Yeah, I'm trying to build myself a cloaking device. Actually, all I have is a couple of polarizers I accidentally pilfered from a lab and never remembered to return.
-
I like to brag. I do C/C++, Ruby/Ruby on Rails, some basic HTML, and Flash.
And I'm young (think pubescent teen), but, heh, i'm not immature as people generally stereotype to us.
-
PHP-based web developer here (including all usual stuff like AJAX, SQL and so on, but no flash).
-
I do Basic (lol), Java/C/C++, and a bit of asm. Currently studying software engineering.
-
Minor. I fooled around with VB to make a treasure generator for D&D that combined words from text files. It was quirky and probably the lamest way to do it.
I've messed around with simple HTML. Nothing to be proud about.
I also fooled around with RPGmaker or something for a while. Again, nothing special.
And I programmed for Ultima Online freeshards in Sphere 55i for about two years. I'm confident that I could script every gameplay system in the server given time and interest, but the emulator scene has moved on and I'd have to relearn a lot. And I never got into server administration.
-
I like to brag. I do C/C++, Ruby/Ruby on Rails, some basic HTML, and Flash.
And I'm young (think pubescent teen), but, heh, i'm not immature as people generally stereotype to us.
-
Me calling myself a programmer would probably be an overstatement, but I can read most code that's english-based, and I can write something in it as long as it follows at least some of the common structures like if clauses, loops, and so on.
I did make the pretty Modbase thing, but that's more a project of boredom than actual work - it's VB.NET, so as to think better.
All in all, I can probably manage C/C++/C#, Basic of all kinds, Delphi, and even something like Logo (you wouldn't believe the crazy stuff we did with that at school...). Can't say I'm adequately proficient in anything that doesn't come with an equivalent of MSDN help libraries.
-
I like to brag. I do C/C++, Ruby/Ruby on Rails, some basic HTML, and Flash.
And I'm young (think pubescent teen), but, heh, i'm not immature as people generally stereotype to us.
lol it was one of those times when you get tired of always trying not to brag
but still, generally I'm a good kid ;D
-
Hey since all you programmers are here... can you answer me a stupid question?
Since DF isnt (and probably never will be) multi-threaded... would it be possible for toady to instead migrate fluid flow computing, or pathfinding, into a separate program which then communicates with DF.exe & lets me have a ton of waterfalls without killing FPS?
Then i could run water.exe on one cpu & dwarffort.exe on the other. Right?
Or is there a fundamental flaw in my understanding of how programs work?
-
Well...
That's basically the same thing :P.
The program must be able to communicate with it's sub-processes. So still the same work involving as making it multi-threaded.
TL;DR: A program uses ONE thread (process) normally.
-
Hey since all you programmers are here... can you answer me a stupid question?
Since DF isnt (and probably never will be) multi-threaded... would it be possible for toady to instead migrate fluid flow computing, or pathfinding, into a separate program which then communicates with DF.exe & lets me have a ton of waterfalls without killing FPS?
Then i could run water.exe on one cpu & dwarffort.exe on the other. Right?
Or is there a fundamental flaw in my understanding of how programs work?
reinvited the concept of multi thread ;) you should be programmer ...
-
But yes, basically, if you would run a background "physics calculator" that you would just pass data to, and get end data from it, you would get the most basic form of multithreading.
-
Well i should come clean & admit that i havent done any programming since around 1985... and i was 10 years old then (hey there wasnt anything else to do on those old TRS-80s)
-
My first coding attempts were in 48K Basic, on a ZX Spectrum-based "console" called Delta-C. The most complex "game" I made was like X-Com, only without the tactical aspect, and the global map. Just basically one base that you build and that gets assaulted by aliens, and the combat results are determined by dice. That one was fun, but waay too random.
-
Ive been playing around with a little app for Flightsim called wideview. It lets you run flightsim on a multitude of displays (we're talking over a dozen) without any loss in framerate. It does this by running Flightsim on multiple computers each running a couple displays all synched up over the network.
Im not sure if it really counts as clustered computing, because each system is running its own copy, theyre just all following a "slew" mode & repeating the positions sent by the master.
It got me to thinking about my framerate issues in DF.
-
my first was also a ZX Spectrum .. but i haven't made big things on it ... i was born too late to use it too much (i am from '86 :D) but i liked it ... i made programs for a big basic manual wich haven't worked so well becouse it was for later versions of basic (if i remember rigth but it was when i was like 7-8 so i am not sure)
And for the phisic program .. i heard about cards wich are like graphic cards but they calculat phisics :D ok it is not DF like phisic it is more 3D but not bad as idee those cards ...
-
I despise C with every ounce of my soul, hate C++, Java, python, perl, and FORTRAN, dislike C# and SML (I'd feel the same way about o'caml I'm sure). Maybe by the time I die we'll have figured out how to program without aiming dangerous weapons at our feet, and I'll be happy. But most of what I program in is LaTeX, if you can call it that.
-
I used to write text adventures for my brothers to play on the ol trash-80. Mostly dungeon hacks with some very limited RPG elements. I also wrote a boxing game that let us all put in our own boxers & then did dice-roll bouts through the league & up the ladder.
I never had a disk drive, the tape drive was unreliable (you had to go in after loading & clean up a multitude of errors before your code would run) and i only had... um... 16k of ram (after an 8k upgrade) so my options were limited.
But it was a lot of fun. Later on in life i tried to re-enter the world of programming, taking some VB courses in college... but college didnt go so well for me. Nowadays i think im just way too far behind the learning curve, its probably best to let the pros handle it. Ive tried tinkering around with things like gamemaker (ive got a couple pretty kickass game ideas) but just cant seem to get my brain wrapped around code anymore.
see what happens when you get old?
-
Used to program all the time in Arm BASIC (which was, as BASIC goes, very nice), had to learn C++ at uni but hated it. Haven't really programmed recently at all, too much like hard work.
-
Working on a game with Keiseth. Currently learning Python, mastered TIBasic.
We need people to make tiles, if anyone's interested. Also, someone to look at the code when we are stuck on something would be nice.
-
I despise C with every ounce of my soul, hate C++, Java, python, perl, and FORTRAN, dislike C# and SML (I'd feel the same way about o'caml I'm sure). Maybe by the time I die we'll have figured out how to program without aiming dangerous weapons at our feet, and I'll be happy. But most of what I program in is LaTeX, if you can call it that.
Wow, you must have worked only with terrible code done by others. I hate python and perl, but maybe for fundamentally different reasons. Python use of whitespaces as delimiters is bad bad bad. Specially for people like me who work with several different editors (including notepad) and machines at the same time to code. Perl's anything-goes syntax is just a lovecraftian nightmare.
-
I would love to develop with a program that are like Multimedia Fusion but has the same complexity as C++ :P. Would make coding considerably easier to do. (Do programming module based. I.E: You just set how the classes and vectors are as Blocks as logic and then cram in all code you want there.)
Maybe i should make a C++ helper program :P. (Or at least try to)
-
Wow, you must have worked only with terrible code done by others. I hate python and perl, but maybe for fundamentally different reasons. Python use of whitespaces as delimiters is bad bad bad. Specially for people like me who work with several different editors (including notepad) and machines at the same time to code. Perl's anything-goes syntax is just a lovecraftian nightmare.
And any language that allows
for(;P("n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); to compile should be tossed in the round file.
OH WAIT, THAT'S C CODE.
-
that's not C code even if you brilliantly devise the P function to have it increment for the loop and return a check for breaking the loop, all while taking one parameter of a string.
-
I started off in QBASIC (age of 10), made a few text based fighting games for my friends. I know a fair bit (i.e, I once did a forum game tilemap generator) of VB6, but I'm currently learning C++ (on and off for the past 2 months). I made a "stress tester" (read: computer-slower), a calculator-y thing, and a simple game in it.
I'm aiming to go to university in 2 years and study Software Engineering. Eventually, I'd like to wind up working for a software company. Is this a wise/interesting choice, oh programming geniuses?
-
<snip>
oh programming geniuses?
Calling me an genius would be a overstatement :P.
-
that's not C code even if you brilliantly devise the P function to have it increment for the loop and return a check for breaking the loop, all while taking one parameter of a string.
Your C fails. R- is the key. There are other reasons for why it may fail to compile. However, since you don't have the rest of the program you can't tell.
-
I do C++ as a sometimes hobby. I went to school for programming roughly 7 years ago, but most of what I learned, outside of C++, is pretty hazy. If pressed, I could probably pick up QBasic, SQL, COBOL, RPG, Java, or Visual Basic again (not that I would want to for a few of those...).
Can't say I'm adequately proficient in anything that doesn't come with an equivalent of MSDN help libraries.
MSDN is how I continued learning C++ after school. Everything I know about the Windows GDI I learned from MSDN. And thanks to my poor memory, it's my C++ programming lifeblood ;D (Which order do those arguments go in again?, etc.)
The next goal is to learn DirectX or OpenGL so I don't need to rely on DC's and BitBlt() anymore for my graphical work.
-
And any language that allows
for(;P("n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); to compile should be tossed in the round file.
OH WAIT, THAT'S C CODE.
You can write horribly obfuscated code in any language you want. The trick is that you would need to actually know what are you doing in any of those languages to get it right without the compiler or interpreter throwing you lines of error messages before it even runs.
In Perl, your obfuscated code can be riddled with doom bringing bugs due to simple typing errors and the interpreter wouldn't even notice since a great deal of those mistakes can be interpreted as valid instructions.
On the other hand I have criticisms for all other languages. C is primitive and ugly. C++ is a failed experiment of a OO language (which is still primitive and ugly as C). Java is too verbose and bloated. C# is getting more and more bloated and all the advantages it had over a C++/COM+ combo are evaporating with each new version of .NET. Common Lisp, like C++, it's a failed experiment in OO with a primitive syntax. Scheme is better in that regard but lacks a standard OO implementation. Lua is still very young and lacks a lot of features, compared to python, along with more proper documentation.
Edit: Of course all of this is my personal opinion. I'm sure I would be barely able to defend it.
-
Mffmmrrggmmmffgggrrraaaaaaaaaaaaaaaaaaaaaaaaaa!!!!!!!!
*Ahem*...
C and all its variants may be primitive and ugly, but when you understand how code gets from executable to a processor, you'd realise their hidden elegance. It's like calling assembly code primitive and ugly - it's a moot point because it's the fastest code you can get without passing direct binary instructions to the processor.
Yes, Python, Lisp, Perl, Piet, BASIC and all the millions of other languages out there can be pretty, elegant, simple or esoteric, but above all, they're slow.
Anyway, that's my little rant for today. Feel free to rip it to shreds.
Yes, I'm a Novice C/C++ programmer.
-
Zemat, the perfect programming language will never exist :P.
-
Anyway, that's my little rant for today. Feel free to rip it to shreds.
Since you asked... first off, execution speed is often a secondary concern: if my code quickly computes the wrong answer, or quickly crashes, it's pretty worthless code. If I spend more time making it fast than is ever saved by it running fast, that was a waste (unless it needs to be fast for some other reason).
Secondly, the algorithm often matters more than the language. For example, this morning I wrote up a cubic-time algorithm: I did a linear scan in the inner loop rather than a hashtable lookup, because I was writing in C it was too complicated to do all the work to build a hashtable. The obvious perl code for the same problem would have run in quadratic time, so it would have been faster on even fairly small examples.
I can look at ML code and have a pretty good idea of what it maps to in terms of assembly instructions; it is harder than C, but you really shouldn't need to think that hard about how your instructions will be translated except once in a rare while.
Wow, you must have worked only with terrible code done by others
I have plenty of experience with other peoples' terrible code in various contexts, but also plenty of experience writing my own, including a bit of experience designing languages and implementing them. But my beef with programming languages is how error-prone they all are. While some are much less bad than others, I wouldn't call any of them good.
I tend to use either C++ or SML for ~10k SLOC projects, and perl for things that need to read input and produce output and not compute much in between -- though I did write a mesh refinement code in perl once. C is useful because there are some very freakishly fringe compilers for it (like cilk, for parallel execution), but it's pulling teeth to write correct code in C.
-
Zemat, the perfect programming language will never exist :P.
Heh, I know that, and I love programming. Right know for my pet project I'm both using C++ and Lua. Most stuff that needs high precision and performance I'm doing it on the C++ part of the project. The rest of the stuff that doesn't require high performance I'm doing it Lua because of the language's simplicity and flexibility.
The code is 60% C++, 40% Lua. But actually the C++ part does very little compared to the Lua part precisely because Lua requires much less code to do the same compared to C++. But the C++ part of the code is used 80% of the time (RNG, noise, graphics, etc). Hence the performance requirements.
-
Secondly, the algorithm often matters more than the language. For example, this morning I wrote up a cubic-time algorithm: I did a linear scan in the inner loop rather than a hashtable lookup, because I was writing in C it was too complicated to do all the work to build a hashtable. The obvious perl code for the same problem would have run in quadratic time, so it would have been faster on even fairly small examples.
I'm a terrible coder TBH, but I have this pet project that has a for loop inside a for loop to find out if one of one set of objects is intersecting (2D) with any object in the second set (first set with first set doesn't matter, ditto second set with second set). Is there a better way to do that? My array size is determined at run time, though typically is about maybe 20 objects and 40 though the first set can go as high as about 50 (I've never really counted).
-
There is one simpel lesson for all of this.
What >EVER< (try to challange me on this one) language you choose, there will be trade offs.
What >EVER< language you choose to learn do it well and you will have no problem with obscure code.
Never challange someones choise of langauge because it's slow, hard, complex. The person doing the code probably have more experience in it then you do. Making the problems you try to push on the language non existant. A code is only better for a certin task if the programmer him/her self is fluent in that language. If not the time consumed to write accurate good code removes all benefits. Using the comment "well learn it well then" doesn't apply becouse the objective itself might be such a small task compared to the big picture it's a waste.
For people to understand me, i usaly write engine and rendering code and doing it in anything other then C/C++ would be branded as insane from my part.
I can read almost our entire codebase att work (c++) without being confused about what the goal or purpose of a specific part is.
This is an MMO, for those who do not know thats a freakin HUGE code base.
Everything boils down to the time you been programing. If you spend the time you can learn almost all languages fluently.
Just to test some comments people have made I have a plan to make a really easy project, a complete project, make it playable, and port it to as many languages as possible. Thats the only way to compare them. And thats just for one project. It will anyway contain the tre corner stones of a game, physics, input, graphics so I think i will get quite a fair overview and test of each design.
-
Secondly, the algorithm often matters more than the language. For example, this morning I wrote up a cubic-time algorithm: I did a linear scan in the inner loop rather than a hashtable lookup, because I was writing in C it was too complicated to do all the work to build a hashtable. The obvious perl code for the same problem would have run in quadratic time, so it would have been faster on even fairly small examples.
I'm a terrible coder TBH, but I have this pet project that has a for loop inside a for loop to find out if one of one set of objects is intersecting (2D) with any object in the second set (first set with first set doesn't matter, ditto second set with second set). Is there a better way to do that? My array size is determined at run time, though typically is about maybe 20 objects and 40 though the first set can go as high as about 50 (I've never really counted).
Work on a one object basis, and only do intersection code with objects that are withing a possible range from the object, removing tests from all objects that doesn't have a chance to intersect. Also remove collision checks from all objects that can't move, it's the job of the moving object to inform the stationary object thats it been hit if this is necessary (at least for a small game with lots of stationary objects)
One list goes trough all objects one and one except those with the "stationary/geomatry" flag. Test this against a list containing all the objects you can collide with, including geomatry/stationary. The simplest test to optimize this is, if you are moving right you can't hit objects to your left, if you move up you can't collide with anything belove you. So if your X movement is positive. You can remove everything on a position less then your current X position.
This can also be improved by splitting the world into quadtrees, and just check the objects in the area you are next to.
QuadTree = split the world in to separat quadratic sectors and let each sector keep track of all objects in that sector and only check against those. Allowing you to instantly eliminate all quads and objects in quads that doesn't concern you.
-
I get the theory behind that (I kinda understand what to do if I was doing the work) but I don't have the faintest idea how to code that (probably why I failed Programming Language Concepts where the final project was a working compiler for some language I'd never heard of...though I didn't really get the theory either). Kinda why I left computer science.
I'll ponder it, feel free to hit me with a PM (http://www.bay12games.com/forum/index.php?action=pm;sa=send;u=973) or email (draco18s2@hotmail.com). If it matters, I'm working with Flash, though likely not for the most part (I call ActionScript an event based C++ because I learned C++ first and AS used a similar syntax and syntax is the hardest thing for me to learn when looking at a new language (prefix operator langs (i.e. + 3 2 instead of 3 + 2, or postfix: 3 2 +) are a b*tch), my comp sci friends hate AS because you can put your code literally anywhere and it still works--for me it's great, I can put code literally ON the relevant object).
</ramble>
-
Well i should come clean & admit that i havent done any programming since around 1985... and i was 10 years old then (hey there wasnt anything else to do on those old TRS-80s)
Ooh! I also had one of those (it's still somewhere in the basement I think)! Really loved the high-tech "Color Computer".
Oh, the memories... Now I'm getting all melancholic... Won't be able to do any work today... :)
-
In Perl, your obfuscated code can be riddled with doom bringing bugs due to simple typing errors and the interpreter wouldn't even notice since a great deal of those mistakes can be interpreted as valid instructions.
The work around for avoiding almost all "invalid but the interpreter will allow what it thinks you meant is" is just about this simple:
use strict;
Personally I like PERL because it lets me:
1. Write stupid little scripts to automate some of the worst parts of my job. This is basically just shell-scripting on steroids, and while I've commented them a bit so I know whats going on, they are not really meant to be maintained.
Example: I have to check that all the links on various parts of a site are pointing to valid anchors at times and it sucks. But, I have a stupid little script that will crank through the whole site, record all the anchors and links it finds, then it gives me a report on any that are bad.
2. Write OOP web apps. These are "real" applications, which are commented, have POD so if I get hit by a bus the next programmer can pick up where I left off, etc.
The flexibility to do both of those things is the real appeal of the language to me. Yes, you can write REALLY sloppy code with it, but if you use strict and taint checking it's a lot harder to write bad code.
Note: I'm fully aware that it's a touch silly that you have to turn on all the checks rather then have them all on by default and you have to turn them off. :P
-
I'm a terrible coder TBH, but I have this pet project that has a for loop inside a for loop to find out if one of one set of objects is intersecting (2D) with any object in the second set (first set with first set doesn't matter, ditto second set with second set)
Oooh, geometry, my favourite!
Without more assumptions about the two sets of objects, I'm not seeing an obvious way to do much better than testing all pairs in O(mn) time, where m is the number in the smaller set and n is the number in the larger set. If you know that the objects in each set intersect each other only a little bit (for example, each one intersects at most a constant number of other members of its set), then you should be able to do a variant of the standard sweep-line algorithm and run in O(n log n) time. If one set is very small, then all-pairs is faster than that, but it sounds like you have m ~ n.
Given that your n and m are pretty small, throwing in some quick hacks like quadtrees or bounding box hierarchies might get you to decide that the naive algorithm with hacks is fast enough in practice, and simpler than the sweep algorithm.
If your objects are moving, there's a lot more that can be done to avoid redoing checks from scratch, as mentioned.
-
The objects are moving. The "large set" gets smaller with time, the small set stays relative constant, getting larger only briefly, but that's when I see the heavy lag and it's that that I'm trying to get rid of. The sets are relatively small and I've reduced the number of hitTest() calls as far as I can (by checking to make sure that the object is even on the screen to matter, etc, etc., but most of the lag at this point I think is just the sheer size of the arrays).
I've been pretty abstract about it, but it's a vertical scrolling shooter. Large set is the array of things to shoot at, the small set is the array of bullets flying through the air (it has both friendly and enemy, but friendly travel fast for the most part--I think there are about 6 on screen at any given time, except for when the set peaks due to a special ability which spawns about 25 at once, enemy bullets are only checked against the player, so it's O(m) time).
Since my last post I did realize I was making the game go through an extra loop of the check, it was a quick hack to get the player's bullets to move twice as fast without having them inadvertently "phase through" narrow enemies (simply: move, loop [check], move, loop [check]) and I could really do it as one loop (move, loop [check, move, check]). I've had complaints about lag before I did that though. It hasn't gotten worse, probably do to rendering optimizations I did (objects with 30,000 vector points are not fast--having that many was stupidity on my part as I'd simply scaled the vector art down and didn't simplify it, they're around 600 points now).
-
At a first cut, I'd try just chopping the screen in, say, 9 or 16 or 25 squares, as someone else suggested, and see if that's sufficient for happiness. A square has a list of bullets and a list of objects. When a bullet enters a square, it checks against every object in the square. When an object enters a square, it checks against every bullet in the square. When an object or bullet leaves the square, you remove it from the square's list. You'd get the same lag as before if all the objects ended up in a single square, but c'mon, what are the chances of THAT?*
If it is a problem, you might start to adaptively refine squares up and then coarsen them later, but I doubt it's worth the development work. Even if that is the kind of code I'm writing in the other window right this minute.
*: make sure your game isn't fun enough to get too many people trying it out.
-
At a first cut, I'd try just chopping the screen in, say, 9 or 16 or 25 squares, as someone else suggested, and see if that's sufficient for happiness. A square has a list of bullets and a list of objects. When a bullet enters a square, it checks against every object in the square. When an object enters a square, it checks against every bullet in the square. When an object or bullet leaves the square, you remove it from the square's list. You'd get the same lag as before if all the objects ended up in a single square, but c'mon, what are the chances of THAT?*
this is called a "quad field".
If it is a problem, you might start to adaptively refine squares up and then coarsen them later, but I doubt it's worth the development work. Even if that is the kind of code I'm writing in the other window right this minute.
and that's called a "quad tree"; a similar structure in 3d is called an oct-tree, which is pretty close to quake's BSP trees.
just bragging that I know some stuff ;p also, you can google it by name now.
-
I've worked inside quake and know OF BSP trees, but not how they work.
Anyway, back to the regularly scheduled topic.
-
The objects are moving. The "large set" gets smaller with time, the small set stays relative constant, getting larger only briefly, but that's when I see the heavy lag and it's that that I'm trying to get rid of. The sets are relatively small and I've reduced the number of hitTest() calls as far as I can (by checking to make sure that the object is even on the screen to matter, etc, etc., but most of the lag at this point I think is just the sheer size of the arrays).
I've been pretty abstract about it, but it's a vertical scrolling shooter. Large set is the array of things to shoot at, the small set is the array of bullets flying through the air (it has both friendly and enemy, but friendly travel fast for the most part--I think there are about 6 on screen at any given time, except for when the set peaks due to a special ability which spawns about 25 at once, enemy bullets are only checked against the player, so it's O(m) time).
Since my last post I did realize I was making the game go through an extra loop of the check, it was a quick hack to get the player's bullets to move twice as fast without having them inadvertently "phase through" narrow enemies (simply: move, loop [check], move, loop [check]) and I could really do it as one loop (move, loop [check, move, check]). I've had complaints about lag before I did that though. It hasn't gotten worse, probably do to rendering optimizations I did (objects with 30,000 vector points are not fast--having that many was stupidity on my part as I'd simply scaled the vector art down and didn't simplify it, they're around 600 points now).
Are you using the Flash built in hitTest function? That thing is terrible. Writing your own will be a massive savings.
-
Hobby programmer here - 4-5 years solid experience with C++ (engineering school and a hobby), but also know a smidge of Java, a (deprecated) assembly language, VHDL, MATLAB, PSPICE and several obscure and unimpressive job-related scripting languages.
-
Dabbling programmer here. My Intro to CS teacher taught us the very basics of C++ my first semester. The second semester, a better teacher taught us quite a bit of Ada and is also the reason I finally installed various Linux distros. I'm not pretending to be very good, but I can hold my own in that class.
Slightly off-topic, but I've been in the process of creating a text-based romp through various D&D adventure settings. Being a dabbling programmer, it's not exactly playable. It's entirely in Ada, which some people may think is strange.
-
I have to admit, I wasn't very fair on the 4GLs (Python etc). While C may be a nice, fast, low-level language with assembly import, bitwise shifts and so forth, it has to be compiled on the target operating system in order to work reliably; and, of course, once you start putting in assembly code it becomes completely architecture-specific. The biggest advantage 4GLs have over C is that they don't need binaries compiled for your specific operating system.
To put it in perspective, take DF Companion. As a compiled Python script, so long as you have the required Python libraries installed on your computer, it will work on just about any computer/operating system.
You'd still be insane to write something as intense as a game in anything other than C; hell, even writing in C++ or C# is generally frowned upon.
Also, I forgot to mention before (I got too sidetracked...) but... all your experience makes me feel sad. I really only got started a few weeks ago (alright, I did some simple stuff here and there in a few different languages), and the best I've managed is a compounding interest loan calculator. 'Twas fun to make though; especially since I had to restructure the whole thing twice (once to replace the goto functions with classes, and the second time to make it repeatable).
Also, I mostly work with IDEs. I know, I know, I should be using butterflies, but unfortunately, there's not enough of 'em around here.
One final note: anyone got a link to a decent starter's guide to Perl? I've heard a fair bit about it, and I'm interested in learning it as a second language (hehe).
-
GOTO EternalPitsOfDamnation;
enough said. :P
-
One final note: anyone got a link to a decent starter's guide to Perl? I've heard a fair bit about it, and I'm interested in learning it as a second language (hehe).
http://fchan.us/pbp.rar - Just click through and ignore the disclaimer.
Also, anyone who has aesthetic problems with Perl has either only seen code in it made by idiots ("what's use strict?") or deliberate assholes ("let's golf this!").
Example for nice and readable code. (http://code.google.com/p/dwarvis/source/browse/branches/dev/map_extract/map_extract.pl)
-
I thought about being a progamer once, but I couldn't really practice because I'm too cheap to get games that aren't free.
...
...
Oops...
Sorry about this post, I misread something...
-
I thought about being a progamer once, but I couldn't really practice because I'm too cheap to get games that aren't free.
...
...
Oops...
Sorry about this post, I misread something...
I see what you did there ;).
-
I've worked inside quake and know OF BSP trees, but not how they work.
Anyway, back to the regularly scheduled topic.
When you talking about BSP you are probably closed to a octree then a quadtree, if you don't need to solve stuff in diffrent depth this is probably overkill.
BSP if i remember correctly identifiy what you see and not by using infinite planes and calculate the point where they intresect if i remember correctly and use that to build geomatry. Atleast thats how the pre BSP data is defined in halflife2 (in the map file before being compiled) That and by logicaly identifiying a room, find the portals (open spaces) into that room and thus, if you can't see the portal, you can't see the room there for it's no need to render it. Important notice is that the quad/octree should allways be stationary. Otherwise you have the the problem of resorting the entire quad tree each frame thus spending more time optimizing for rendering then the time it would take to render it.
-
Are you using the Flash built in hitTest function? That thing is terrible. Writing your own will be a massive savings.
Right, because I know how to do that.
-
I started with the worst dialect of basic (http://en.wikipedia.org/wiki/Learn_to_Program_BASIC), but quickly looked for something else that allowed for more than 1000 variables. It's been a few years now, and I am working with C and mostly opengl. And torquescript(a c-like scripting language for the torque game engine).
I have a few ideas for games. I plan to try to make a brick simulator much like blockland, but where blockland imbeds an oct tree in each brick making them immobile once created, my idea is to work with brick groups that have physics and limit the oct trees to the groups.
To solve the flash hit test problem, you might try to check for boundary intersection first and only then use the hit test. Maybe.
-
Also, anyone who has aesthetic problems with Perl has either only seen code in it made by idiots ("what's use strict?") or deliberate assholes ("let's golf this!").
Example for nice and readable code. (http://code.google.com/p/dwarvis/source/browse/branches/dev/map_extract/map_extract.pl)
I recognize that's beautiful code :)
It takes discipline (or being diagnosed with OCD) to code like that in any language.
Well, now that the thread is going farther and farther away into physics land, I have a question about Half-life physics and game physics in general.
What's so hard about simulating a body riding a mobile object? If you have ever played HL or HL2 you'll notice that if you stand above a sliding object (not properly riding a vehicle) the view jitters along the way as the camera body tries to remain static while continually being dragged by the moving object below it. It's too costly to implement moving frames of reference so that the camera body can gain momentum without having to recalculate it's position every second?
If you are not so sure what I mean test the Infinity Combat Prototype (http://www.infinity-universe.com/Infinity/). In that game, when you are on free space you fly inside a global frame of reference. But if you go near a capital ship you automatically enter the capital ship's frame of reference and your ship will move inside of it as if it where a static frame of reference. This makes it a lot easier to dock and move near the capital ship without having to manually compensate for the capital ship movement.
-
You'd still be insane to write something as intense as a game in anything other than C; hell, even writing in C++ or C# is generally frowned upon.
[...]
I really only got started a few weeks ago (alright, I did some simple stuff here and there in a few different languages), and the best I've managed is a compounding interest loan calculator.
You have much to learn, grasshopper :)
There's basically three speeds you can run at:
1. compiled to assembly code. This is usually the fastest. C, C++, SML, Pascal, FORTRAN, etc all fit here.
2. compiled to byte code, then compiled just-in-time. Often reported to be about 20% slower than (1), but I see more slowdown than that in what I write: C#, Java.
3. compiled at run-time. Slow. Perl, Python, Ruby, ...
Finally, there are language features that invite you to write slow code. For example, in Java, it's very tempting to dynamically allocate lots of tiny structures; in C++ it can be tempting to use dynamic dispatch (virtual functions); and in C you can't easily write general functions like qsort without indirect calls (passing function pointers around). Garbage collection is a godsend when it comes to ease of development, but may or may not be OK for runtime, depending on the game: bad for a real-time game that has a lot of new state, fine for a strategy game or a real-time game that has little new state (like Draco18s's, probably).
-
<snip>
You'd still be insane to write something as intense as a game in anything other than C; hell, even writing in C++ or C# is generally frowned upon.
<snip>
Lol wut?
*Insert a huge flame against Makrond over this heresy*
Now when that is done so will i go over to the more relevant parts :P.
Insane? Wtf?
I find it more easier to write stuff in C++ and do the more relevant parts instead of fiddling with Individual characters in a array.
Oh and i can not live without Object Oriented Stuff (OOP) :P. They are too convinient to be without.
(Oh and games are not that complex as you make them look like.)
-
Well, now that the thread is going farther and farther away into physics land, I have a question about Half-life physics and game physics in general.
What's so hard about simulating a body riding a mobile object? If you have ever played HL or HL2 you'll notice that if you stand above a sliding object (not properly riding a vehicle) the view jitters along the way as the camera body tries to remain static while continually being dragged by the moving object below it. It's too costly to implement moving frames of reference so that the camera body can gain momentum without having to recalculate it's position every second?
Only barely related: The Force Unleashed demo just came out for the 360. They have some amusing physics quirks that my OCD side picked up on. For example: if you pick up some boxes and place them on a lift, then ride the lift up, when you reach the top of the lift the boxes go flying off into the air and then glide back down to the lift platform, but you don't.
I'm not 100% sure what is going on in the case that you are asking about, but physics in video games has always been pretty "cheap", and I'm guessing you're just seeing a side-effect of that. As I'm sure you already know, they are just trying to avoid spending too much processing time on physics portion so most of it is coded to be as computationally cheap as possible. Which always leads to fun quirks.
i.e. in Quake 2: You fall faster then your rockets fly, so on levels with long drops it's possible to hit the ground before your rocket does, and even fall through your flying rocket. Technically your rocket should hit you, but since rockets couldn't hit the person who shot them they would pass through you and hit the ground at your feet.
i.e. in a TON of 3D shooters: Going forward and strafing moves you faster then going forward alone. Strafing into a wall while going forward as well would move you wicked fast.
i.e. in Tribes: Skiing was an unintended side effect of the physics model, and also allowed you to move forward at warp speed. (Downward hills had less friction then level ground, so if you rapidly hopped while going down a hill you just kept going faster and faster and faster.)
-
Also, anyone who has aesthetic problems with Perl has either only seen code in it made by idiots ("what's use strict?") or deliberate assholes ("let's golf this!").
Example for nice and readable code. (http://code.google.com/p/dwarvis/source/browse/branches/dev/map_extract/map_extract.pl)
I recognize that's beautiful code :)
It takes discipline (or being diagnosed with OCD) to code like that in any language.
Thanks, but no, not really. All it takes is knowing that one will have to look at it again some time later. In reality, that code there doesn't have enough comments, for example. When i look at it now, i find that i have problems understanding some elements and need to reference to find out what they do.
So really, whenever someone talks about ugly code then the code was either done with the intent to be ugly, or made by someone who is just plain ignorant about that, like a child. OCD or discipline have nothing to do with it. ;)
--
As far as speed goes: I have successfully written a decently performing OpenGL engine in Perl and games like Eve Online are done in Python.
-
Well, now that the thread is going farther and farther away into physics land, I have a question about Half-life physics and game physics in general.
What's so hard about simulating a body riding a mobile object? If you have ever played HL or HL2 you'll notice that if you stand above a sliding object (not properly riding a vehicle) the view jitters along the way as the camera body tries to remain static while continually being dragged by the moving object below it. It's too costly to implement moving frames of reference so that the camera body can gain momentum without having to recalculate it's position every second?
It's hard to simulate two dynamic objects sitting on top of each other, because in a simulation you have to break time up into pieces. For example, say you had a two boxes. Box A is resting on Box B, and Box B is resting on the ground. The game just finished drawing/simulating frame 1 and 0.030 seconds have passed.
Now it's figuring out frame 2. Gravity is acting on both boxes, so they have an acceleration of -9.81ms/s^2. This has been acting on each box for 0.030 seconds, so they each are moving now, so Box A is actually inside of Box B is in the ground. The game recognize now that a collision has occurred, so it moves them back up. This is where the jiggle comes from.
You can get rid of this by recognizing some boxes are static, so you stop accelerating them, but when you have them on a lift/platform you have to simulate them again and make them dynamic. And the jiggle is back.
There are more complicated/expensive ways to do all this which would resolve this problem, but it's not always worth the cost to get rid of some jiggle.
Are you using the Flash built in hitTest function? That thing is terrible. Writing your own will be a massive savings.
Right, because I know how to do that.
Easy thing to do would just do a bounding rectangle intersection test. Just look at the first example here: http://www.gamedev.net/reference/articles/article735.asp
-
So really, whenever someone talks about ugly code then the code was either done with the intent to be ugly, or made by someone who is just plain ignorant about that, like a child. OCD or discipline have nothing to do with it. ;)
Hmm. I have seen plenty of ugly big project code (worked for some big Cs) that neither where made with the intent of being ugly or made by ignorant people. It's just plain laziness which brings forth the worst in every coder. That's why I was talking about discipline. Although it's also truth that if you focus on doing things right long enough it will be soon second nature.
Like in the example Perl code put above, commenting it's something that doesn't come naturally and some people need to force themselves to comment. I myself which I have programmed for a long time now, still need to consciously put an effort into commenting. Otherwise my code is completely devoid of comments.
-
There are more complicated/expensive ways to do all this which would resolve this problem, but it's not always worth the cost to get rid of some jiggle.
Someday I'm going to write a fast physics engine that eliminates jiggling (my OCD demands it). Someday before I die of old age.
-
Hmm. I have seen plenty of ugly big project code (worked for some big Cs) that neither where made with the intent of being ugly or made by ignorant people. It's just plain laziness which brings forth the worst in every coder. That's why I was talking about discipline. Although it's also truth that if you focus on doing things right long enough it will be soon second nature.
Like in the example Perl code put above, commenting it's something that doesn't come naturally and some people need to force themselves to comment. I myself which I have programmed for a long time now, still need to consciously put an effort into commenting. Otherwise my code is completely devoid of comments.
haha I think most people get annoyed into commenting properly, because if you work at any place a decent amount of time you'll be flooded with stupid questions from people using/maintaining your code. At some point you realise, "Damn. I could've just written this once in the source and saved myself a ton of hassle."
At least, that's how I got into the habit. :P
-
<snip>
You'd still be insane to write something as intense as a game in anything other than C; hell, even writing in C++ or C# is generally frowned upon.
<snip>
Lol wut?
*Insert a huge flame against Makrond over this heresy*
Now when that is done so will i go over to the more relevant parts :P .
Insane? Wtf?
I find it more easier to write stuff in C++ and do the more relevant parts instead of fiddling with Individual characters in a array.
Oh and i can not live without Object Oriented Stuff (OOP) :P . They are too convinient to be without.
(Oh and games are not that complex as you make them look like.)
Hey, I have no problems with it, personally; the industry opinion on anything other than C at the moment is just ridiculously biased. I don't even know, personally, what the problem is with C++ as opposed to C, but apparently if you use anything other than C, you're not a good programmer (seriously, I've seen this so many times on programming-related forums when someone asks what language to use). That said, I happen to know Mount&Blade is written in C++, and it works pretty well, so I really can't comment on the effectiveness of C vs. C++.
When I say 'game', I don't mean things like "CLIK DA BUTTON1" (gross oversimplification), but complicated games that are doing many hundreds of thousands of calculations per frame. If you tried to write something like that in Python, it would be monstrously slow. Of course, the solution would be to give the game ridiculously high system requirements.
Actually, I was having a discussion with someone who is in the industry about this; basically he told me that there's more and more things being written in 4GLs because, if they run slow, there'll be a better processor out next week that will make the slowness barely noticeable, or the end user can install more RAM to try and reduce the problem, get a faster hard drive, and so on, and so forth. Basically, the rapid advancement of technology is allowing programmers to use the simpler but slower languages, simply because at some point in the near future, it's not going to matter.
Also:
There's basically three speeds you can run at:
1. compiled to assembly code. This is usually the fastest. C, C++, SML, Pascal, FORTRAN, etc all fit here.
2. compiled to byte code, then compiled just-in-time. Often reported to be about 20% slower than (1), but I see more slowdown than that in what I write: C#, Java.
3. compiled at run-time. Slow. Perl, Python, Ruby, ...
I did actually do some research (emphasis on some) prior to posting my opinions, and this is basically what I was trying to get at (although I didn't know about C# being a just-in-time code).
However, there's always a trade-off. C can't run on any other operating system/architecture except the one it's compiled on (same with Pascal and all the others that are compiled direct to assembly). Python can run on almost any machine once it's been compiled, as can Perl (with minor modifications depending on the OS), etc. Java's a bit of a special case; it's referred to as a 5th generation language, only because it's even more cross-platform than the 4GLs, although strictly speaking it's just a properly-realised 4th gen language.
Finally, I realise my inital position was ridiculously rigid, not to mention indefensible; I'd temporarily turned into the kind of programmer I hate - the 'C IS THE LANGUAGE OF GOD' programmer. I apologise.
-
Probably not the last word. But if you are unsure about the performance of your favorite language you can compare against all the others at the The Computer Language Benchmarks Game (http://shootout.alioth.debian.org/).
For example GNU C++ vs Mono C# (http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=csharp). C++ is roughly 2 times faster and uses 1/5 the memory than C#.
The differences between GNU C and GNU C++ are almost negligible except for the highest performance and lowest memory requirements.
-
<snip>
You'd still be insane to write something as intense as a game in anything other than C; hell, even writing in C++ or C# is generally frowned upon.
<snip>
Lol wut?
*Insert a huge flame against Makrond over this heresy*
Now when that is done so will i go over to the more relevant parts :P .
Insane? Wtf?
I find it more easier to write stuff in C++ and do the more relevant parts instead of fiddling with Individual characters in a array.
Oh and i can not live without Object Oriented Stuff (OOP) :P . They are too convinient to be without.
(Oh and games are not that complex as you make them look like.)
Hey, I have no problems with it, personally; the industry opinion on anything other than C at the moment is just ridiculously biased. I don't even know, personally, what the problem is with C++ as opposed to C, but apparently if you use anything other than C, you're not a good programmer (seriously, I've seen this so many times on programming-related forums when someone asks what language to use). That said, I happen to know Mount&Blade is written in C++, and it works pretty well, so I really can't comment on the effectiveness of C vs. C++.
I'm in the industry and the standard for games, especially console games, is C++. I don't know of any companies who use pure C, although some of EA's sports titles have bits of C code left over from the 90s. :P
-
Probably not the last word. But if you are unsure about the performance of your favorite language you can compare against all the others at the The Computer Language Benchmarks Game (http://shootout.alioth.debian.org/).
Of course you always need to take the benchmarks involving languages and implementations with a grain of salt. While may be true in a very general case. There really is no honest way of comparing one language (implementation) to another language (implementation).
For example, in regards to Mono's Windows implementation, for one particular algorithm test, I believe it took about twice the time it took Microsoft's implementation.
-
Well, apparently now [url http://weblogs.mozillazine.org/roadmap/archives/2008/08/tracemonkey_javascript_lightsp.html]javascript is JIT[/url]. Maybe Duke Nukem Forever will run in my browser...
-
If you tried to write something like that in Python, it would be monstrously slow.
Yes, exactly. That's why Eve Online, a cpu-bound MMORPG, is written in python.
-
Is that sarcasm? At my expense!? OMG *asplode*...
-
Hey, I have no problems with it, personally; the industry opinion on anything other than C at the moment is just ridiculously biased. I don't even know, personally, what the problem is with C++ as opposed to C, but apparently if you use anything other than C, you're not a good programmer (seriously, I've seen this so many times on programming-related forums when someone asks what language to use). That said, I happen to know Mount&Blade is written in C++, and it works pretty well, so I really can't comment on the effectiveness of C vs. C++.
Surely every game that uses DirectX (ie. every pc and xbox game) uses C++? I'm an opengl person myself so I'm not 100% sure on this, but I thought all of the functions in directX work on classes.
-
If you tried to write something like that in Python, it would be monstrously slow.
Yes, exactly. That's why Eve Online, a cpu-bound MMORPG, is written in python.
Wrong.
The engine is written in c++ where many other aspects are scriptbased to allow imidate updates.
Aka the most important parts of the code are fast.
-
You don't seem to have ever played that game nor looked at its client. I have it right here on my harddisk and pretty much the only major parts that are not python are: The graphics engine (which does most of its work on the gpu, not cpu) and the audio engine (which does most of its work on the soundcard, not cpu).
All the game logic, network processing, etc. happens in python.
PS: Check this out too: http://graphcomp.com/pogl.cgi?v=0111s3m3
Reading comprehension is not your strength, huh? In any case, feel free to try reading again what i wrote here, until you've bothered to do that and to actually understand it, i'll not bother to give you anymore answers...
vvvv
-
Like i said everythign that matters are done in c++ the lower priority stuff, logic, some handeling of the network (still belive the core is c++) are probably python.
The reason for this is simple, when the real programmers are done the project is handed over to customer services, QA and some designers that update events and add new stuff trough scripts. Much of this is handled server side and is heavly based on script that doesn't need any recompilation.
Like i said, the small stuff that doesn't need speed doesn't have to be c++.
-
Besides Eve Online is a very light game CPU wise. There's very little interaction between the user/client and between the client/server (the netcode is done to be used as little as possible to reduce bandwidth use as much as possible). It's like a chat game with flashy 3d graphical emotes. There's very little logic involved so no need for complex AI (a cpu intensive task) and there's no physics at all (another cpu intensive task).
Literally the whole of the game is run in the GPU, the Iceland servers, and outside it in the corporation chatboards.
Edit: Also, the game is sloooowwwww (I played it for a month before getting tired of it's uneventfulness).
-
Besides Eve Online is a very light game CPU wise. There's very little interaction between the user/client and between the client/server (the netcode is done to be used as little as possible to reduce bandwidth use as much as possible). It's like a chat game with flashy 3d graphical emotes. There's very little logic involved so no need for complex AI (a cpu intensive task) and there's no physics at all (another cpu intensive task).
AHAHAHAHAHAHA. Good laugh, thanks dude.
Try playing in 0.0 and have some fleet battles. With 200+ pilots, each with drones, space objects, missiles and whatnot flying around, with the client calculating their whole behavior in 3D, including soft-collision physics, Eve will absolutely obliterate your CPU and make your GPU get BORED.
Seriously man, i've played it for 1.5 years. This game is absolutely CPU-bound when you get into the actual game. After a month you've barely started getting into the more involved NPC missions.
P.S.: Try looking at the maths for actual 3D physics sometimes. They are a magnitude heavier than most 2D simplifications employed in other MMOs.
-
Seriously you can't compare EO physics with a real physics engine. And I'm not even talking about other MMOs here, most of them are very simple CPU-wise, simpler than Eve Online I reckon.
There's a noticeable lag in every action in-game but most players don't care because this isn't a action oriented game. So they won't bother if there's a clear 0.5 sec lag between a click and a response. That lag would kill you in a online FPS.
-
I can and i do. The eve client can manage movement, acceleration AND collision of, roughly, 300 objects in FULL 3D simultaneously. THINK about that for a minute. Keep in mind it does so while pumping out images as well.
You said it yourself, they keep the network light. The server only sends out positions and vectors and the client itself has to create and calculate all the animation data from that.
Sure, yes, user input is handled with a marked delay. That however is caused by the need to keep all clients synched as well as having to communicate with the server.
Games with low latency actually are a lot easier on the clients, because the server does most of the work. In Eve most of the physics are offloaded to the client.
--
I'm not sure what counts as a "full physics engine" in your eyes, but keep in mind that even in games like FEAR, there are at most 10-20 moving objects in any scene, only 4-5 of which are actually interacting elements like the player and enemies.
-
I'm not sure what counts as a "full physics engine" in your eyes, but keep in mind that even in games like FEAR, there are at most 10-20 moving objects in any scene, only 4-5 of which are actually interacting elements like the player and enemies.
A game physics engine must take into account more than the object count, their positions and velocities. Collision handling in Eve is very simple. Only the larger objects (like stations and maybe capital ships) have complex hitboxes. Ships can only collide with stations and they just go into a full stop when colliding. Ships getting hit by missiles don't get affected in their speed and orientation by any kind of explosion. There are no actual projectiles other than missiles. Cannons and laser are only graphical effects since targeting is a very simple matter where only the range of weapons and some probabilities are taken into account to see if there was a hit.
Most game objects in other 3d games are composed of several boxes where collision detection is done for each of them. 20 moving objects in a FPS could well translate into more than 200 collision validated moving boxes. Add other stuff like friction, rebounding, ragdoll physics and bullet trajectory calculation (raytracing and hitboxes) and you get a hell of a simulation.
I'm not saying Eve Online coders went cheap with the engine aspects for no particular reason. They needed to simplify everything mostly because it's a MMO and, even if all calculations are done client side they need to be validated server side. Otherwise it would be easy to hack or crash the game. Probably there would have been no difference between making the game in C or Python precisely because the game bottleneck is the network aspect of it, not the CPU usage.
Frankly if it were up to me to make the decision I would have gone too with a 4GL for the game because there's no point in using high performance languages with MMOs.
-
Ok, two things:
1. Missiles don't need collision, but they actually have to follow ships. That means if the ship they're trying to hit changes course, so need they.
2. Everything else DOES collide. Drones, ships, cans, stations, gates, etc. They all do collision checks. And they don't just go into full stop, the game uses the relative mass and speed to bounce the objects off each other. this has even led to an amusing pastime called POS bowling in the past.
As far as hitboxes go: Yes, they get simulated, but they don't have shit to do with physics. They're a one-time line-trace that ONLY serves to determine where you hit. They get completely ignored whenever you aren't shooting something.
And lastly, if you can't see how the complete and continous realtime simulation of velocity, vector and acceleration of 300+ objects in 3 dimensions complete with collision is a massively larger task than what most physics engines get to deal with, then you're a lost case. Let me make it more clear again: This happens continuously, all the time while most of the expensive stuff you mention is one-shot stuff that only needs to be calculated for very short amounts of time.
Anyhow, i could write a lot more and demonstrate some maths, but i'm not willing to waste anymore time on debating a game with you that you barely know.
-
Ok, I had to do some research to back up my comments.
Here's a discussion on the physics engine on the EVE forums:
http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=525550 (http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=525550)
relevant bits:
Does anyone know if they have said anything about the ship-physics in the new engine?
Will they still behave like floating boats?
This is a big immersionbreaker for me. When 2 ships are close and about to collide and they swing around like silly, looks really stupid, especially big ships.
The reason I suspect for the physics, is more to do with server load. Eves physics are very simple, and for a reason. Calculating collisions on a super complicated 3d polygon for 700 ships in real times during a fleet battle a complete computing horror. Calculating it for a bunch of bounding spheres with simplified physics is much easier.
It'd be nice. Damn nice. But I suspect the CCP boys have to first work out how to stop the servers melting every time the players get together for a gang bang. And that, is probably more pressing and vexatious an issue to CCP's finest minds then getting the physics more realistic.
It would be nice if they fixed it so mass actually mattered, and tiny ships would bounce off large ones with no effect on the large one - the small one may end up several AU away though Twisted Evil. They could just say that the shields provide a buffer so the ship isn't damaged, but momentum is conserved.
So I was in the wrong about ships not colliding with each other, but I have a reason for my initial impression. There's a lag for the bounce to kick in, ships can go inside each other for a few seconds before the bouncing logic sends them apart. This is more apparent when ships exit a spaceport and go freely thru each other, and it happened to me several times enough to notice it. If the ships manage to separate before the bouncing logic kicks in they never bounce on each other. They bit I said about ships coming to a full stop when colliding with bases is not completely true. What they really do is they momentarily stop then change direction before they even touch the base.
Here's a video of the infamous POS bowling (http://www.youtube.com/watch?v=SXr9Z5YHr88) and another one (http://www.youtube.com/watch?v=AgY3q6XJ9zQ&feature=related). They show the bouncing effect in all its delayed glory. The ships pretty much act as if they had very little or no mass (the bigger capital ships bounce farther than the smaller ones :o). So I don't see how ship masses are taken into account in the bouncing logic. Also you can see that there's no rotation due to collision. As the comments said, they behave like simple spheres.
And lastly, if you can't see how the complete and continous realtime simulation of velocity, vector and acceleration of 300+ objects in 3 dimensions complete with collision is a massively larger task than what most physics engines get to deal with, then you're a lost case. Let me make it more clear again: This happens continuously, all the time while most of the expensive stuff you mention is one-shot stuff that only needs to be calculated for very short amounts of time.
Calculating 300+ moving points (not objects) in 3D is not as hard as it seems. Specially when the collision detection is not being done "continuously, all the time". In more complete physics engines collision detection must be carried out every cycle even when objects aren't colliding (obviously with some time-saving logic that figures out when objects aren't near to avoid unnecessary calculations).
Anyhow, i could write a lot more and demonstrate some maths, but i'm not willing to waste anymore time on debating a game with you that you barely know.
Is not a waste of time. I'm willing to admit when I'm wrong as I was about the not-so-noticeable soft collision detection between ships.
-
Alright, well written and researched post, i have to concede:
I was wrong about the mass. I was under that impression because high mass ships like the Dominix made bumping other ships a lot easier than doing it for example with a cruiser... Ah yes, i remember now: High mass ships have higher inertia and just plain lose speed slower, no matter what. As such they can continue to "push" and accelerate the other ship longer.
That also explains why capital ships get pushed farther. Their engines, when speed is set to 0, take longer to nullify the push due to higher inertia.
Aside from that, POS bouncing pretty much breaks the physics. You have an object with EXTREMELY high mass, which puts itself inside an immovable object (the POS shield), gets then pushed out and accelerated the whole way to the edge of the shield (farther in = more speed when exiting) pushing away anything in the way, without the pushed object being able to work against it in any way.
However there's something not right with your observation:
After undocking ships have a certain grace period against bouncing. That's done to prevent the docks from being a total clusterfuck. Afterwards however collision checking is in fact in full effect the whole time and also regularly used in combat.
-
So my memories weren't completely off :)
The no-collision time buffer explains most of the weird stuff I saw when playing. And since I never got the chance to participate in 300+ battles where collisions between ships could probably happen I just assumed the code wasn't there.
Right now I'm downloading the client again just to use the extra free 14-days in my account I got when the graphical upgrade was released. I must admit I loved the pretty space graphics and the music and I have yet to see the improved ones. But the lull between the battles and traveling for minutes from one place to the other it's too much for me so I might not stick yet again.
Edit: Thanks for not giving up on the discussion.
-
I am learning C++, I have made basic console based calculators and a few other things.
-
Isn't it feasible nowadays to write the algorithmic parts that need to be fast in, say, C++, and the rest in, say, Python? So it's not really a matter of which language is "better" in that case?
EDIT: OOPS sorry for the minor necro, didn't see this thread was ten days old.
-
Yes, indeed, most big projects do this nowadays.