Advice on programming language, Not Trolling.
finwelordo...@gmail.com
the past, mostly derived from people not giving specific enough
information about themselves. I am not sure exactly what to say to
make this as painless as possible, I am willing to answer any
questions to make this easier.
Reason I chose this group, I respect the opinions expressed in this
group, mainly your opinions on game design. Crawl is my favorite
roguelike, specific reasons are the ratio of player faulted deaths to
unavoidable deaths, difficulty/experience curve, focus on quality,
magic system.
Why I believe it necessary to come here to ask instead of elsewhere. I
have asked multiple people advice on programming language and they all
say "well, to start off...". That is fine, but it seems like they are
recommending something based on how easy it is to learn, not how
functional (for lack of better word) it is. I do not expect to write
anything of quality for at least a year or two, I am willing to invest
many hours, read as many books as it takes.
What I hope to eventually write. A roguelike similar to Crawl. Simple,
perhaps complex, physics/ragdoll simulations, most likely in 2d.
Particle interaction simulator (falling sand games are the best
examples, Omni 2 mod for Burning Sand 2 is a good example for
something more specific). Perhaps Shmups or 2d platformers. Maybe
something similar to Dwarf Fortress in scope, without the micro.
Almost every game I wish to create is in 2d with exception to a few
possible ragdoll simulations, but those are at the bottom of my list.
I care not for sound or graphics so long as they are able to
accurately represent all the information I wish to portray.
Information I am guessing you will find useful to help me. I am
leaning towards OOP. I read that they are logical, clean, and take
advantage of the intuition. I like things that are logically coherent
and retain consistency. I like things that are expressed in concise
logic. I do not mind highly complicated systems so long as they are
logical and casual. I like to be able to see everything and to make
every choice when making something, I like to be able to have things
clearly expressed to the fullest degree, even at the expense of
initial comprehension. I do not mind having to learn extended
vocabulary or devices so long as they are (sorry I keep saying this)
logical.
I despise Ambiguity. I dislike barriers. I learn things by first
understanding the underlying principles and building up in a logically
casual way.
I guess this also serves as my introduction, I have been frequenting
this group for 3 years now. I apologize for whatever I did wrong and I
hope this acted as a sufficient buffer to prevent a flame war.
Nate879
relatively hard to learn, especially if you don't have any programming
experience. I recommend learning other languages first. Anyway,
everybody likes different programming languages, for different
reasons. That is part of the reason flame wars over this topic are
common. If you want to find a language that you like, you will have to
try many different programming languages. A list of languages is at
http://www.catb.org/~esr/faqs/hacker-howto.html#skills1.
If you want to learn C++, http://www.cplusplus.com/doc/tutorial/ is a
good tutorial.
Derek Ray
> information about themselves. I am not sure exactly what to say to
> make this as painless as possible, I am willing to answer any
> questions to make this easier.
Most important: what platform do you want it to be played on?
(ie. Windows, Leenucks, DS/portable, both)
Possibly related: what platform are you willing to code it on? :)
--
Derek
Game info and change log: http://sporkhack.com
Beta Server: telnet://sporkhack.com
IRC: irc.freenode.net, #sporkhack
Jotaf
the best choice. I usually go with C++ for "serious" game projects
without thinking a lot about the subject, but I guess the main reasons
are pure inertia (been a C++ dev for a long time) and because C++
projects are taken more seriously than any others (others might argue,
but that's my guess). My experience is that the abandon rate for C++
projects is way, way higher than for any other language. This includes
all the games I started coding in C++ right away. Development of games
with other software has been much easier; for example using Adventure
Game Studio or Game Maker (yes, their scripting languages are pretty
powerful). Other, more serious ventures don't suffer from this
problem, for example coding a proof-of-concept for a system in Matlab
and then doing the final version in C++.
My current project is in C++. Development is a bit slow but I won't
restart in another language on a whim. My only complaint is that C++
is extremely strict, and it's difficult to make any change in the
infrastructure of any sizable project. The same could be said of many
other languages though so it's not a killer point. Lua feels nice but
it would take some work to interface libtcod with it (which I
currently use and like very much). I liked VB in the sense that you
could just type away and things just happened. Matlab is the same way.
Unfortunately VB6 was discontinued, VB.net is not quite the same (I
gave it a try but you have to deal with the same bulls**t you get with
C++), and Matlab, well, it's not for games, is it?
This probably didn't help much, I'm just saying what doesn't work
instead of what works :) C++ is great if you are patient and have lots
of free time. I'm still evaluating all the other choices to see if I
find a good enough competitor. I'm leaning more towards functional
languages. Haskell is a bit too hardcore in its pureness and the fact
that its syntax is so light that I get lost looking at Haskell code,
there are almost no real keywords and brackets to cling to. Lisp has
too many brackets; I like syntactic sugar. I haven't given a serious
look at other functional languages though.
Jotaf
Jeff Lait
> Development of games
> with other software has been much easier; for example using Adventure
> Game Studio or Game Maker (yes, their scripting languages are pretty
> powerful).
I have seen some impressive stuff come out of those systems. One key
question is the author's discipline. Time to @ moving on the screen
is critical to keeping interest and keeping working. C++ is not
friendly to this.
> My current project is in C++. Development is a bit slow but I won't
> restart in another language on a whim. My only complaint is that C++
> is extremely strict, and it's difficult to make any change in the
> infrastructure of any sizable project.
That is true of *every* language. It has nothing to do with the
language. It is purely a function of LOC. When you have 10k LOC, you
can change 10% of your program with a mere 1k LOC. If you have 100k
LOC, the same 1k change will only affect 1% of your program.
libtcod is strongly recommended.
This is why the greatest imperative is to make your infrastructure as
small as possible :>
> This probably didn't help much, I'm just saying what doesn't work
> instead of what works :) C++ is great if you are patient and have lots
> of free time. I'm still evaluating all the other choices to see if I
> find a good enough competitor. I'm leaning more towards functional
> languages. Haskell is a bit too hardcore in its pureness and the fact
> that its syntax is so light that I get lost looking at Haskell code,
Haskell's syntax is extremely beautiful when you grok it.
Unfortunately, it is also extremely functional so is very painful to
try and write anything truly interactive in, such as a game. You have
to go off the deep end with Monads and what not to go anywhere, and my
attempt to figure out the curses module failed. Indeed, when I wrote
a raytracer in Haskell, the IO was very much the most difficult
part...
> there are almost no real keywords and brackets to cling to. Lisp has
> too many brackets; I like syntactic sugar. I haven't given a serious
> look at other functional languages though.
Games tend to be very imperative constructs. Sure, functional
advocates will point out read-evaluate-print, but when you try and
build that into a 2d platformer, I, at least, start really getting
confused. One of my intentions is to take a closer look at some of
the functional roguelikes to try and figure out what the correct
approach is.
Preemptive apologies to the functional crowd here.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Jeff Lait
> First off, I do realize that this topic has caused many problems in
> the past, mostly derived from people not giving specific enough
> information about themselves. I am not sure exactly what to say to
> make this as painless as possible, I am willing to answer any
> questions to make this easier.
Thank you for the apologies. The problem isn't that people aren't
specific enough. The problem is it is like walking into a inter-faith
community meeting and asking the attendees which religion you should
follow. Everyone is going to *start* by being properly deferential
and circumspect in their answers...
> Why I believe it necessary to come here to ask instead of elsewhere. I
> have asked multiple people advice on programming language and they all
> say "well, to start off...". That is fine, but it seems like they are
> recommending something based on how easy it is to learn, not how
> functional (for lack of better word) it is. I do not expect to write
> anything of quality for at least a year or two, I am willing to invest
> many hours, read as many books as it takes.
Then you should have no objection to learning more than one language.
You cannot be a computer programmer if you only know one language.
Computer programming is largely an act of *inventing* a new language
to solve your problem. "C" is sort of like a grammar with no
vocabulary - the job of the programmer is to create a new language of
nouns and verbs for every problem domain. (A Lisp advocate will here
point out that Lisp lacks even the grammar :>)
Furthermore, there exist many special problem domains which are only
sensible to approach with highly specific languages.
Learn Python. It is a powerful language with a pleasant, readable,
syntax. It is well supported on all platforms with a large library to
pull existing code from. It is also not just a "training" language -
it is a very powerful "scripting" language that will serve you very
well. Indeed, it likely can save you the pain of bothering to learn a
bash variant properly. The mechanics of programming are best learned
in an interactive environment not provided by compiled languages.
Learn one of C, C++, Java, C#. These are all imperative languages -
"do this, do that" but compiled and scalable. My recommendation would
be with C++ as it likely has the best support and future proofness.
Learn one of Lisp, Scheme, Haskel. There is a 80% chance this will
just hurt your brain, but it in this case you'll at least know the
world is bigger than you live in. There is a 10% chance that you will
discover your one true calling.
> What I hope to eventually write. A roguelike similar to Crawl.
C++. I'd recommend libtcod. I have not used it myself, but have seen
excellent results and a cursory glance at the API makes me want to use
it myself. http://jice.nospam.googlepages.com/thedoryenlibrary
> Simple,
> perhaps complex, physics/ragdoll simulations, most likely in 2d.
Anyone who knows python better than me can point out what matrix
libraries/solvers it has?
> Particle interaction simulator (falling sand games are the best
> examples, Omni 2 mod for Burning Sand 2 is a good example for
> something more specific). Perhaps Shmups or 2d platformers.
I'd want to throw C++ at all these problems. But keep in mind my own
biases.
> Maybe
> something similar to Dwarf Fortress in scope, without the micro.
This doesn't require a programming language. It merely requires the
rest of your life.
> Information I am guessing you will find useful to help me. I am
> leaning towards OOP. I read that they are logical, clean, and take
> advantage of the intuition.
"They" likely don't include C++. There is also no such thing as
"taking advantage of the intuition". Attempting to paraphrase
Einstein: Commonsense is merely the things you learned before the age
of sixteen. Since I learned programming before 16, I guess that
explains my jaundiced view of those who claim OOP is somehow closer to
some ground-truth of human's natural world-view. "is-a" and "has-a"
is a false dichotomy the answer to which depends not on the objects
under study, but the problem to which those objects are to be applied.
> I like things that are logically coherent
> and retain consistency. I like things that are expressed in concise
> logic.
Haskell is the language for you!
> I do not mind highly complicated systems so long as they are
> logical and casual.
Sufficient programming will teach you that highly complicated systems
are never logical or causal.
> I like to be able to see everything and to make
> every choice when making something, I like to be able to have things
> clearly expressed to the fullest degree, even at the expense of
> initial comprehension. I do not mind having to learn extended
> vocabulary or devices so long as they are (sorry I keep saying this)
> logical.
>
> I despise Ambiguity. I dislike barriers. I learn things by first
> understanding the underlying principles and building up in a logically
> casual way.
This seems to paint you as the sort that will end up embracing
functional languages. I would recommend starting with the likes of
Python and C++, however. This way you will better appreciate the
freedom you are provided by those languages and have some empathy for
us poor souls still slogging in the lower-reaches of abstraction.
And, who knows, you may find you aren't so enamored with pure logic
after being burned in its flame :>
pau...@mbnet.fi
> You cannot be a computer programmer if you only know one language.
But you can make games.
Xecutor
But you cannot make complex games without being good computer
programmer :)
pau...@mbnet.fi
> But you cannot make complex games without being good computer
> programmer :)
What is a good programmer? Is anyone here a good programmer?
Let me see the games he made.
Jeff Lait
But most games aren't complex. :>
The original poster, however, did not state merely a desire to merely
make games. Instead the desire to be a computer programmer came
through rather clearly.
There is nothing wrong with programmers being experts in only one
language. However, they have to be at the stage where the concept of
"learning" a new language seems somewhat laughable as they are
confident it is merely a matter of spending a couple days with the
compiler and some tutorials. I'd liken it to artists who may only be
skilled at, say, oil painting, but should not thus have avoided trying
their hand at pastels their entire life.
It is also very important you "discover" alternative types of
programming early so you don't have to laboriously reinvent them later
(or discover them and throw away your hard work desperately embracing
them!)
Gerry Quinn
@n33g2000pri.googlegroups.com>, na...@nate879.org says...
> For roguelike development, I would recommend C++. However, it is
> relatively hard to learn, especially if you don't have any programming
> experience. I recommend learning other languages first.
So do I. C++ is just too complicated as a first language.
Of course you could start with what is nominally C++ but is really more
like C... maybe that's a viable starting point. One advantage is the
fact that so much roguelike code is available in C.
Many beginners start with some version of Basic.
- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
Gerry Quinn
@k9g2000vbl.googlegroups.com>, torespon...@hotmail.com says...
> On Dec 27, 7:20 pm, finwelordofthenol...@gmail.com wrote:
> > Particle interaction simulator (falling sand games are the best
> > examples, Omni 2 mod for Burning Sand 2 is a good example for
> > something more specific). Perhaps Shmups or 2d platformers.
>
> I'd want to throw C++ at all these problems. But keep in mind my own
> biases.
Also, one of the advantages of C++ is that you *can* throw it at just
about any problem. It's a big big toolset. That's also what makes it
unlikely to be a good first language; there are likely to be a lot of
different ways to tackle any problem, whereas simpler languages will
tend to guide you more in a parrticular direction.
Nik Coughlin
news:83447e4f-caaa-4710...@q26g2000prq.googlegroups.com...
> Why I believe it necessary to come here to ask instead of elsewhere. I
> have asked multiple people advice on programming language and they all
> say "well, to start off...". That is fine, but it seems like they are
> recommending something based on how easy it is to learn, not how
> functional (for lack of better word) it is. I do not expect to write
> anything of quality for at least a year or two, I am willing to invest
> many hours, read as many books as it takes.
First, apologies in advance for using Wikipedia for all of my references,
it's just that they generally have very good programming articles.
My advice for selecting your primary language is:
* mulitparadigm [1]
* modern
* garbage collected [2]
* large community
For the reasons above (and because of the .NET framework behind it, which is
extensive) I work almost entirely in C# but it has its issues and
limitations like anything else - I'm not going to advocate that you use it
but you should at least try it
If you're going to invest a year or two on it, I would advise trying many
different languages, go beyond Hello World but not too much beyond, an @
moving around a screen is always a good start. This is something that I
have done in the past in order to get my head around a new syntax or
paradigm and found very effective - a caveat here is don't fall into the
trap of writing for example C code in Perl, try and learn the idioms for the
language you are learning.
Read other people's code! This is a great reason in itself for having at
least passing familiarity with several languages, very handy when the
algorithm you are researching only has implementations in Reverse Polish
Brainfuck or whatever.
Learn about different programming paradigms [3]
Other things that you should know or are useful to at least be aware of,
otherwise you will often end up reinventing the wheel, and much less
effectively than those who have gone before you:
* data structures [4]
* design patterns [5]
* unit testing [6]
* version control [7]
* YAGNI (basically KISS) [8]
* UML [9]
[1] http://en.wikipedia.org/wiki/Multi-paradigm_programming_language
[2] http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
[3] http://en.wikipedia.org/wiki/Programming_paradigm
[4] http://en.wikipedia.org/wiki/Data_structure
http://en.wikipedia.org/wiki/List_of_data_structures
[5] http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
[6] http://en.wikipedia.org/wiki/Unit_testing
[7] http://en.wikipedia.org/wiki/Revision_control
[8] http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
http://en.wikipedia.org/wiki/KISS_principle
[9] http://en.wikipedia.org/wiki/Unified_Modeling_Language
antoine....@gmail.com
> On 28 joulu, 15:33, Xecutor <konstantin.stup...@gmail.com> wrote:
>
> > But you cannot make complex games without being good computer
> > programmer :)
>
> What is a good programmer? Is anyone here a good programmer?
That's a good question. Who on RGRD is an expert programmer?
I'm pretty sure there's some people round here with mad skillz (but
I'm not one of them)
A.
Xecutor
I believe all A rated games are done by good programmers :)
There was an example not related to roguelikes, but related
to 'good programmer'. Project 'War Angels'. In short:
One guy (Hamish IIRC) made several simple yet addictive games
as part of 'Fallen Angels Industries' group.
Company 'Moonpod' noticed him and offered to make a game under
company's supervision. There was good start, nice screenshots
and even gameplay videos. But... At some point he understood,
that he is not good enough programmer to handle more complex stuff.
Games of a complexity beyond some level can be done by 'brute force'.
Just a lot of hard work.
However modifications and bugfixing of games created with such
approach
are very difficult.
I think I'm pretty good programmer, but I'm working on things that are
so far away from gaming, that my first attempt in roguelike
development
isn't as good as it could be...
Lack of time is also paying it's toll.
Xecutor
After thinking for awhile about definition of a 'good programmer'
I came to the following wording:
Good programmer is a programmer who have desire for a constant
evolution.
Of course this desire must be supported by corresponding mindset.
Person who do know some programming language, do know basic design
patters,
do know basic algorithms and think that this is enough is a coder, not
a programmer IMHO :)
Malorzean
I quote Dijkstra: "It is practically impossible to teach good
programming to students that have had a prior exposure to BASIC: as
potential programmers they are mentally mutilated beyond hope of
regeneration. " :-)
Malorzean
Martin Read
>> Many beginners start with some version of Basic. =A0
>
>I quote Dijkstra: "It is practically impossible to teach good
>programming to students that have had a prior exposure to BASIC: as
>potential programmers they are mentally mutilated beyond hope of
>regeneration. " :-)
Which was then, and is now, flagrant bullshit, as evidenced by the many
good programmers who cut their teeth on 8-bit microcomputer BASICs.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
Xecutor
I started learning programming with Basic on ZX Spectrum.
Next thing after basic was Z80 assembler :)
I still remember that ED B0 is LDIR.
pau...@mbnet.fi
> I started learning programming with Basic on ZX Spectrum.
> Next thing after basic was Z80 assembler :)
Those were the two possible languages of 8-bit computers.
I started with Basic as well and all I can say it's a
language that no one should learn today.
Jed Davis
> On 30 joulu, 10:11, Xecutor <konstantin.stup...@gmail.com> wrote:
>> I started learning programming with Basic on ZX Spectrum.
>> Next thing after basic was Z80 assembler :)
>
> Those were the two possible languages of 8-bit computers.
They were reasonably well suited to Forth as well.
--
: callcc r> swap >r ; : p1 s" JdDvs" drop r> begin swap dup c@ emit
1+ swap callcc again ; : p0 s" e ai" p1 begin 2swap ?dup while over
c@ emit 1 -1 d+ 2swap callcc repeat cr drop 2drop ; p0
Jeff Lait
Well, there you go. I started with BASIC. Thus, I cannot be a good
programmer. So I am freed from any pretense of false modesty in
dodging the "are there any good programmer?" question by pointing to
this disqualification.
Jeff Lait
The original, clipped, statement was "computer programmer". Not "good
computer programmer."
Now, I don't mean fluent in multiple languages. I mean able to muddle
through multiple languages, quite possibly with liberal use of
reference material. For example, I'd claim to know Pascal but I can
never figure out its contrary semicolon rules.
Gregory Weston
<b4b0d131-aa2f-43ab...@e24g2000vbe.googlegroups.com>,
Jeff Lait <torespon...@hotmail.com> wrote:
Nothing contrary about the use of semicolons in Pascal. They're
statement separators. End of story. If you think of them as statement
*terminators* that are sometimes optional according to complex rules
you'll get into trouble.
--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
Gerry Quinn
mpr...@chiark.greenend.org.uk says...
> Malorzean <malo...@gmail.com> wrote:
> >> Many beginners start with some version of Basic. =A0
> >
> >I quote Dijkstra: "It is practically impossible to teach good
> >programming to students that have had a prior exposure to BASIC: as
> >potential programmers they are mentally mutilated beyond hope of
> >regeneration. " :-)
>
> Which was then, and is now, flagrant bullshit, as evidenced by the many
> good programmers who cut their teeth on 8-bit microcomputer BASICs.
You said it, so I don;t have to.
Djikstra clearly didn't like students who knew anything and might dare
to have ideas of their own.
- Gerry Quinn
Gerry Quinn
@z28g2000prd.googlegroups.com>, pau...@mbnet.fi says...
There are many Basics.
If you want to write 3D games and know nothing about programming,
Blitz3D is surely one of the better choices! Other Basics have their
benefits too.
Basics have moved on, and most modern ones incorporate a lot of concepts
from C.
finwelordo...@gmail.com
questions.
Would it be helpful read about the "theory" of programming and
programming languages? Or better put, would it help me understand the
underlying principles and mechanisms by which programming languages
work? Any recommendations on specific books, the more comprehensive
and analytical the better.
"> I despise Ambiguity. I dislike barriers. I learn things by first
> understanding the underlying principles and building up in a logically
> casual way.
This seems to paint you as the sort that will end up embracing
functional languages."
This confuses me, so I ask for clarification. I was led to believe, or
misinterpreted, that oop was was about the relationships between
objects and their whatever, that you assigned the conditions and
relational qualities. I apologise for my choice of vocabulary, I've
yet to understand all the terms, I hope I used words that are fairly
unambigious.
Anyways, OOP gave me the sense that things acted internally
consistant, clean and logical. Functional on the other hand seemed...
as if it, well, I couldn't understand any of the principles really, or
atleast they didn't seem to derive or hold much ground in logic.
I guess I feel, or want to believe, OOP is the "hard-science" of
programming languages, like a highly complex system, comparable to
certain linguistical fields.
I was happy to read that learning different languages is not overly
difficult, that puts my mind at ease.
Thank you for all your help, I will probably end up going with c++ if
I predict correctly. I will take advice still if anyone is willing. My
next choice is either jumping right into c++, learning about theory
first, or both at the same.
Martin Read
>Anyways, OOP gave me the sense that things acted internally
>consistant, clean and logical. Functional on the other hand seemed...
>as if it, well, I couldn't understand any of the principles really, or
>atleast they didn't seem to derive or hold much ground in logic.
On the contrary: functional programming is very firmly rooted in
mathematics and formal logic.
pau...@mbnet.fi
> Anyways, OOP gave me the sense that things acted internally
> consistant, clean and logical.
What really matters is how you actually use the language,
but for me C++ (OOP) was a good choice, because it's
preventing some dumb mistakes when you create good
anally pedantic classes. Refactoring is then less
reflected in other parts of the source code when you
change something.
Timofei Shatrov
confuse everyone with this message:
>In article
><b4b0d131-aa2f-43ab...@e24g2000vbe.googlegroups.com>,
> Jeff Lait <torespon...@hotmail.com> wrote:
>
>> On Dec 28, 9:29 am, pau...@mbnet.fi wrote:
>> > On 28 joulu, 15:33, Xecutor <konstantin.stup...@gmail.com> wrote:
>> >
>> > > But you cannot make complex games without being good computer
>> > > programmer :)
>> >
>> > What is a good programmer? Is anyone here a good programmer?
>> > Let me see the games he made.
>>
>> The original, clipped, statement was "computer programmer". Not "good
>> computer programmer."
>>
>> Now, I don't mean fluent in multiple languages. I mean able to muddle
>> through multiple languages, quite possibly with liberal use of
>> reference material. For example, I'd claim to know Pascal but I can
>> never figure out its contrary semicolon rules.
>
>Nothing contrary about the use of semicolons in Pascal. They're
>statement separators. End of story. If you think of them as statement
>*terminators* that are sometimes optional according to complex rules
>you'll get into trouble.
That's exactly how I write my Javascript. Semicolon after every statement,
no exceptions.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Risto Saarelma
> Would it be helpful read about the "theory" of programming and
> programming languages? Or better put, would it help me understand the
> underlying principles and mechanisms by which programming languages
> work? Any recommendations on specific books, the more comprehensive
> and analytical the better.
Unless you speak mathematical logic like a native, probably not. If you
want to make games, it would seem much more important to have deep
knowledge of what games are made of and why they are fun. So if you want
to dive into theory, you might want to look to here for example:
http://en.wikipedia.org/wiki/List_of_books_on_computer_and_video_games#Design_and_theory
Off the cuff, I'd point to _The Art of Computer Game Design_ and _Rules
of Play_ as good starting points.
The problem with programming language theory and games is that computer
games, at the level of roguelikes such as Crawl, are complex and messy
beasts. PL theory doesn't like messes. At least the part of it I'm
familiar with is based on being able to do formal proofs on program
behavior, and compared to regular software engineering, that's very
hard. In practice, hardcore PL theory is used mostly in programming
language design and in things like developing the floating-point
routines of new processors, not in developing regular software or games.
Beyond the problem of games being very complex, there is the more
important problem of the success criteria for games. A programming
language compiler needs to produce correct programs and a floating-point
unit needs to produce correct calculations. These criteria can be
formally specified. A roguelike has the criterion of being fun and
interesting for a human player, which cannot.
The actual programming skills you need to implement the game design are
a lot more practical. You'll need some general sense of what'll be
reasonable to implement and run, what existing solutions and design
patterns there are, how to structure a complex software project so that
it stays manageable and how to balance various implementation tradeoffs.
I don't know of any successful hard theory for these, probably because
they involve some pretty complex human judgment mostly based on
experience.
There doesn't seem to be a good way for getting the feel for programming
other than writing smaller programs and learning from them. This short
article about starting game development describes something similar:
http://www.gamedev.net/reference/articles/article892.asp . If you
haven't programmed a complete game yet, doing a small game like Tetris
where there's nothing interesting to innovate in the design part is
actually very good advice, even though it seems boring and uncreative.
If you start both learning programming and implementing a novel game,
you're fighting a war on two fronts. You need to struggle both with
coming up with a compelling game design and getting the program
structure working. With Tetris and Space Invaders, you can concentrate
on getting the program structure and interface working, and will end up
with a much more robust technical basis to do something innovative on.
There are some books that go into the details of doing software from the
practical side instead of PL theory. These books assume the reader
already knows how to program, and try to collect some of the more subtle
design principles for making robust and manageable software.
Mike McShaffry's _Game Coding Complete_ is a tour of the nuts and bolts
of game programming. The title is a riff of Steve McConnell's _Code
Complete_, which is a similar book for general software engineering.
It's also a good read. Game Coding Complete only covers topics specific
to games, and the general stuff in Code Complete is also useful for game
programming.
_The Pragmatic Programmer_ by Andrew Hunt and David Thomas is another
good book on general considerations in software development.
And if you still want to go for the hardcore programming language
theory, this could be one starting point:
http://en.wikipedia.org/wiki/Denotational_semantics . Also, Benjamin
Pierce's _Types and Programming Languages_ is quite nice and accessible
relative to the rest of the field. I'm going to repeat the disclaimer
that this stuff is going to be a lot of work to understand and is likely
to be of very little use in helping the next Crawl along, but of course
it's always good for general erudition.
noteventime
something someone else already noted.
Regarding the question of Haskell as a language for Rogue-like
development. I don't necessarily believe that IO has to be the hard
part here, you just have to move away from the the idiom of a very
central "main"-loop (whether the loop is a recursive function, a for-
loop or some kind of object oriented construct).
I'm not going to pretend that I'm an expert in this, but what may be
interesting about using Haskell as a language for developing rogue-
like games is the simplicity with which you can implement small DSL-
languages in it. An interesting topic of study could, for example, be
how you can define a declarative language for defining the rules of
roguelikes and evaluate them as a game.
I've seen a discussion of managing interaction and rule driven games
here: http://www.mail-archive.com/haskel...@haskell.org/msg33040.html
. It is rather (since they're an essential part of intermediate
Haskell) Monad heavy, and I'm not going to pretend I understand it
all, but it does seem like an interesting approach.
Jeff Lait
> "> I despise Ambiguity. I dislike barriers. I learn things by first
>
> > understanding the underlying principles and building up in a logically
> > casual way.
>
> This seems to paint you as the sort that will end up embracing
> functional languages."
>
> This confuses me, so I ask for clarification. I was led to believe, or
> misinterpreted, that oop was was about the relationships between
> objects and their whatever, that you assigned the conditions and
> relational qualities. I apologise for my choice of vocabulary, I've
> yet to understand all the terms, I hope I used words that are fairly
> unambigious.
>
> Anyways, OOP gave me the sense that things acted internally
> consistant, clean and logical.
OOP gives you good tools to write things that act internally in a
consistent, clean, and logical, manner. But nothing stops you from
overloading + to format the harddrive.
Further, a language like C++ is not a internally consistent, clean,
nor logical language. It is a hodgepodge of semantics and syntax.
This is largely a good thing and endemic to any multi-paradigm
language.
> Functional on the other hand seemed...
> as if it, well, I couldn't understand any of the principles really, or
> atleast they didn't seem to derive or hold much ground in logic.
This is why it is important to learn a functional language because
they, by far, are the purest and best bound by logic.
> I guess I feel, or want to believe, OOP is the "hard-science" of
> programming languages, like a highly complex system, comparable to
> certain linguistical fields.
OOP is the hard-science of programming languages like nail-guns are
the hard-science of house construction. I fear someone who thinks
they can solve every problem.
> I was happy to read that learning different languages is not overly
> difficult, that puts my mind at ease.
>
> Thank you for all your help, I will probably end up going with c++ if
> I predict correctly. I will take advice still if anyone is willing. My
> next choice is either jumping right into c++, learning about theory
> first, or both at the same.
Good luck! Hopefully you have the persistence to overcome the large
initial learning curve of C++. I'd still recommend starting with
Python.
Gerry Quinn
> There doesn't seem to be a good way for getting the feel for programming
> other than writing smaller programs and learning from them. This short
> article about starting game development describes something similar:
> http://www.gamedev.net/reference/articles/article892.asp . If you
> haven't programmed a complete game yet, doing a small game like Tetris
> where there's nothing interesting to innovate in the design part is
> actually very good advice, even though it seems boring and uncreative.
> If you start both learning programming and implementing a novel game,
> you're fighting a war on two fronts. You need to struggle both with
> coming up with a compelling game design and getting the program
> structure working. With Tetris and Space Invaders, you can concentrate
> on getting the program structure and interface working, and will end up
> with a much more robust technical basis to do something innovative on.
The onlt comment I would make is that while you should probably start
with an arcade game like Tetris you needn't follow on with side-
scrollers etc. as he suggests there. His suggestion of Pacman is good,
though, as it is quite roguelike.
There is an issue here about graphics. In my opinion, you don't know
how to program games until you can make a real-time graphic game; you
will end up using loop and input constructs that are completely unsuited
to games. On the other hand, if you want portability to certain types
of device, you may have to use some stuff like curses which has only a
primitive interface for graphics. That's a choice you have to make, but
in any case you should know the basic structures used by games.
Ebyan "Nolithius" Alvarez-Buylla
news:83447e4f-caaa-4710...@q26g2000prq.googlegroups.com...
> I despise Ambiguity. I dislike barriers. I learn things by first
> understanding the underlying principles and building up in a logically
> casual way.
Hello, Finwe, Lord of the Noldor,
There are two important considerations that so far haven't been addressed:
1) Do you plan to use the knowledge of the language as part of your career?
2) You probably won't really know what you like or dislike until you try it.
For the first point, I would say that if you do [want to use this language
in your career], then you should start off with an OO language with
C-syntax. C++, Java, C#, Objective C are some of the major names, but there
are tons of them. The advantage of this approach is twofold:
a) Your skills will be more marketable. These major languages are always in
high demand, as they are used not only to build just about every single
mainstream game out there, but also the largest percentage of desktop
applications. If you want to lean your career towards professional game
development, this is the way to go.
b) It will be very easy to learn other, similar languages. Most companies
will take it for granted that if you have strong Java skills, and a good
grasp of C++, that learning C# should be trivial, for example. Because
there are so many languages in this "family" of languages, this is a strong
selling point.
For the second point, you are going to find that programming will teach you
a lot about what you really like and really dislike, and often will come as
a surprise. In addition, you will have to make compromises and accept
certain necessary evils, because, for the most part, you can't have it all.
For example, despising ambiguity and disliking barriers will get in the way
of each other: Java is a strongly-typed language, which means that a
variable, once it is used to hold a particular type of data, can't be easily
made to hold other types of data (the way to achieve this is relatively
painless, but is not trivial); this presents an inherent barrier when it
comes to using variables for different purposes. Most languages prevent
ambiguity by creating barriers (though not necessarily unsurmountable).
This might not be the strongest example, but you'll come to know more about
what you really like or are willing to stand: you might appreciate the
clever restrictions Java uses because it will make debugging easier for you
when going through code with explicit conversions, or you might find these
barriers annoying and opt for a more weakly-typed language with more
ambiguous variable types.
Overall, my vote would be for one of the most popular and marketable
languages out there, C++. You might consider first learning Java or C#, and
using this base as a springboard into C++ (the transition is reasonably
painless). C++ places less barriers on you than these managed languages, and
therefore creates a slightly steeper learning curve because there are many
more bizarre mistakes you can make (with great power comes great
responsibility!).
Regards, and welcome to the group,
--Ebyan "Nolithius" Alvarez-Buylla
Ebyan "Nolithius" Alvarez-Buylla
fbk
<Nolith...@gmail.com> wrote:
> Overall, my vote would be for one of the most popular and marketable
> languages out there, C++.
Many years ago I taught myself c++ by writing a roguelike and I got
pretty far, but not far enough to make
it an even remotely appealing game. Today I'd *never* recommend C++ as
a language for people who take
up programming with a specific project in mind, especially not so if
the project in question is a desktop
software for a single user.
C++ makes it very very very easy to get object orientation wrong, and
to block your own way early
on by making impractical design decisions, for example in regard to
how you will save your objects
in a file. There are quite a few books and FAQs out there that give
good advice on how
to handle these issues, but the amount of information is vast, and you
will not be able to understand all
of it before you start your project.
I would recommend the following:
* Start small, with a subset of your project (ascii graphics, a
dungeon, an @, a few monsters)
* Use an interpreted language, like python or ruby
pau...@mbnet.fi
> C++ makes it very very very easy to get object orientation wrong,
> and to block your own way early on by making impractical design
> decisions
C++ doesn't make decisions, you do. But it's true that
C++ is a difficult language in some sense, because you
can go very wrong with it and there is nothing to stop
that. It's still a question of your programming skills
rather than blaming it all on features of the language.
fbk
> C++ doesn't make decisions, you do. But it's true that
> C++ is a difficult language in some sense, because you
> can go very wrong with it and there is nothing to stop
> that. It's still a question of your programming skills
> rather than blaming it all on features of the language.
The original question was about a language choice for a person
without any programming skill. Of course, a seasoned developer
is less likely to make wrong architectural choices.
If he uses C++, he will waste his time struggling with the stl,
serialization, etc, instead of having fun while making an
interesting roguelike. Interpreted languages OTOH make it drop
dead easy to put stuff in containers or saving your object tree
to disk.
If I was to start another roguelike project, I would go with ruby.
pau...@mbnet.fi
> If he uses C++, he will waste his time struggling with the stl,
> serialization, etc, instead of having fun while making an
> interesting roguelike.
Struggling with STL? If you use STL to what it was planned
then it's making things easier, not harder. Serialization
is one of the things that some people tell is hard in C++,
but in simple roguelikes (anything else than large scale
roguelike) it should be quite easy. If there is a language
where everything is easier than in C++ then why aren't
we all using that language?
> If I was to start another roguelike project, I would go
> with ruby.
Show us how much easier it is.
Gerry Quinn
44befc...@g39g2000pri.googlegroups.com>, freder...@gmail.com
says...
> On Jan 1, 10:17 pm, "Ebyan \"Nolithius\" Alvarez-Buylla"
> <Nolith...@gmail.com> wrote:
> > Overall, my vote would be for one of the most popular and marketable
> > languages out there, C++.
>
> Many years ago I taught myself c++ by writing a roguelike and I got
> pretty far, but not far enough to make
> it an even remotely appealing game. Today I'd *never* recommend C++ as
> a language for people who take
> up programming with a specific project in mind, especially not so if
> the project in question is a desktop
> software for a single user.
>
> C++ makes it very very very easy to get object orientation wrong, and
> to block your own way early
> on by making impractical design decisions, for example in regard to
> how you will save your objects
> in a file. There are quite a few books and FAQs out there that give
> good advice on how
> to handle these issues, but the amount of information is vast, and you
> will not be able to understand all
> of it before you start your project.
Agreed, you will have a few doubtful designs before you learn to make
the most of C++. That doesn't mean you won't make them work, of course;
it may just mean that you make non-optimal decisions that are still
workable.
For many people, their first project will have too deep a class
hierarchy. Their second will be a reversion to near-C. Their third...
if all goes well their third will be about right, in this regard anyway!
Gerry Quinn
4af141...@w1g2000prm.googlegroups.com>, pau...@mbnet.fi says...
> On 6 tammi, 12:42, fbk <fredericb...@gmail.com> wrote:
> > If he uses C++, he will waste his time struggling with the stl,
> > serialization, etc, instead of having fun while making an
> > interesting roguelike.
Well, since the poster is talking about beginners, I won;t disagree with
this.
> Struggling with STL? If you use STL to what it was planned
> then it's making things easier, not harder. Serialization
> is one of the things that some people tell is hard in C++,
> but in simple roguelikes (anything else than large scale
> roguelike) it should be quite easy. If there is a language
> where everything is easier than in C++ then why aren't
> we all using that language?
Serialisation is trivial but a bit long-winded in C++. I'm not sure how
much I'd trust a language that claimed to automate it, though...
Gerry Quinn
gra...@grahamcox.co.uk says...
> One of the things that I've considered playing with for serialization of data
> is to use something like sqlite3 as the savegame format, and to have the game
> model live update the database as it goes. This means that there should never
> be a need to actually do a "Save" command to save the current state of the
> game to the file, but that after everything that happens the save file is
> automatically in a known sane state.
C++ serialisation is actually easy if you are disciplined and serialise
as you go; i.e. add serialisation code to new classes, and call it for
new member variables. [Of course care has to be taken when it comes to
references etc., but good design should make it fairly straightforward.]
The only problems come when you skip that for a long time and then face
doing it it one go. It's still not hard, though - just boring.
Ebyan "Nolithius" Alvarez-Buylla
"Gerry Quinn" <ger...@indigo.ie> wrote in message
news:MPG.23cd987...@news.indigo.ie...
> In article <1f3dda33-8d61-4a29-924b-
> 4af141...@w1g2000prm.googlegroups.com>, pau...@mbnet.fi says...
>> On 6 tammi, 12:42, fbk <fredericb...@gmail.com> wrote:
>> > If he uses C++, he will waste his time struggling with the stl,
>> > serialization, etc, instead of having fun while making an
>> > interesting roguelike.
>
> Well, since the poster is talking about beginners, I won;t disagree with
> this.
>
If the OP plans to use the knowledge of this language to build a career,
then it will be worth it to "waste his time struggling" with some of its
more tricky features. Alternatively, as mentioned earlier, he can
springboard into C++ from Java or C#, two very marketable languages that are
more beginner friendly.
--Ebyan "Nolithius" Alvarez-Buylla
fbk
<Nolith...@gmail.com> wrote:
> If the OP plans to use the knowledge of this language to build a career,
> then it will be worth it to "waste his time struggling" with some of its
I'm not really in the mood to argue about the "marketability" of
programming
languages, even less to engage in a flame war. My sole point is that
the OP
wants to write a roguelike, and he wants to do it for fun, not as a
training
method. He should choose a language that is fun and easy to learn.
Real men use C anyway.
Jotaf
I think both of you are right. C++/Java/etc means career-building,
hard-work, taking years to build something stone-solid. Interpreted
languages are fun, define the way your game should play and make it
just happen. It totally depends on his/her goals. He can always play
around a little with an interpreted language and when he thinks he's
in it for the long haul go and learn C++.
Jotaf