I've been working on a game setting for a couple of years.
I don't know how to program in C++, but I am fairly bright and willing to
learn. When I was a kid I had a QBasic rogueClone that I worked on.
I like Moria, it was my favourite. Love the design. I want a base town,
where all adventures start from, and a randomly generated overworld. I want
each adventure to be random, and I want different environments(IE not always
tunnels). I want randomness- different quests based on the abilities of the
character. I want it to be an offline mmorpg. I want resource harvesting,
crafting, the ability to produce offspring... think Animal Crossing meets
Everquest meets Moria.
I want to do all this, but I have little to no experience. I'd like to get
started on just generating the ascii map and getting the character to move
around/interact.
Any suggestions?
Start small:)
Well, first thing is learning C++. It's relatively easy actually.
Then I suggest you take a look at some of the source codes
of existing games. Preferably newer ones with more OOP
design. OOP is really the way you want to go.
Planning is always good, but you can only do it to a certain
degree before trying out how things work.
I'd advise against looking at source code right now; most RLs are
written in C, which is different enough from C++ to be a pain to look
at...also, a good deal of open-source RLs are either poorly commented,
poorly structured, or both. Right now, work on the basics, such as
display and keyboard input. Here is a fairly good timeline:
http://roguebasin.t-o-m-e.net/index.php/How_to_Write_a_Roguelike_Game_in_15_Steps
I hope this helps.
My motto is "Plan first, implement later." (see my ideas at
http://www.geocities.com/reptoran/ideas.htm) You definitely want to
figure out what you want to add, and what makes your game different and
more interesting than the rest. Have a notebook and write your
thoughts extensively. It is *very* likely you'll forget ideas you
don't write down.
As Krice has said, start small. You should probably have a decent
understanding of your programming language of choice before you dive
into actually working on the game itself. Realize that you don't have
to use C/C++ to develop your roguelike, but it is a popular one. You
may want to look around a bit, and determine if its the one you'll
actually want to use. I'm not sure I hold the same opinion as Krice
about C++. While it is powerful, you have to handle a lot of lower
level stuff that you may not be interested in working with, and it can
often take longer to develop something with it than some other
languages. (such as a RAD language or scripting language).
Once you do select your language, I think some of the main things you
should focus on first are:
- basic input and output
- data structures
- file reading and writing
Here is an article with some ideas on how to proceed with development
(although by no means the only way):
http://roguebasin.t-o-m-e.net/index.php/How_to_Write_a_Roguelike_Game_in_15_Steps
By the way, what do you mean by an 'offline mmorpg'? By definition, an
mmorpg is on-line, since on-line is part of the acronym (Massively
Multi-player Online Role-Playing Game).
Lots of people are sure to suggest C++ from force of habit, but
personally I recommend avoiding it. To me, it's like trying to build
an automobile, given nothing but some metal, a lathe, wrench and
screwdriver.
Other things you can take a look at:
These I have tried personally:
Python + Pygame
Flash
Freebasic
Freepascal
These I have not tried, but they're touted as being easy:
http://www.leopardprogramming.com/about.php
http://www.rapideuphoria.com/
http://www.libertybasic.com/
Alan
I am a huge fan of Freepascal - it has the works if your willing to learn
the language. Its OO works really well, and unlike C++ it is fairly easily
readable. The code is fairly easy to work with too and it is X-Compatible. I
didn't find it difficult to go from BASIC to Pascal, and from what I've
heard, its a good stepping stone for C(++)
Lochok
Oh, and I have to add Java, a little bit like C++ but easier to learn.
Still more complex than Python, Flash and Basic, but definately worth a
look.
> These I have not tried, but they're touted as being easy:
> http://www.leopardprogramming.com/about.php
> http://www.rapideuphoria.com/
> http://www.libertybasic.com/
>
> Alan
BR,
Björn
Can't believe nobody's mentioned Lua. It's opensource, crossplatform,
incredibly simple to learn, flexible, and binds *really* painlessly with
C/C++, allowing a variety of C/C++ libraries to use.
>
> Oh, and I have to add Java, a little bit like C++ but easier to learn.
> Still more complex than Python, Flash and Basic, but definately worth a
> look.
>
I'd advice against it bjorn. Java is so phreaking slow for any
beginner. Not to mention that it is harder to learn than C++ in my
opinion.
Go for Java only if you like portability.
We are talking about a RL here, not Quake IV. Java's executionspeed is
enough for an RL. BTW, the company that I work with have developed a 3D
game in Java, Hockey Challenge, and although it might not be NHL 2006
it can be played as an applet in your browser on almost any
computer.... Java, slow? I think not.
> Not to mention that it is harder to learn than C++ in my
> opinion.
I do not agree, but I'm not discussing it further. I prefer Java, you
prefer C++. :-)
Looking at it from a commercial or workplace perspective it is
extremely valuable for a developer to know C++ though...
> Go for Java only if you like portability.
Who doesn't like portability? :-)
BR,
Björn
If you don't mind using another engine, tome 3 is entirely in lua now, and
should let you do whatever you want.
>
> We are talking about a RL here, not Quake IV. Java's executionspeed is
> enough for an RL. BTW, the company that I work with have developed a 3D
> game in Java, Hockey Challenge, and although it might not be NHL 2006
> it can be played as an applet in your browser on almost any
> computer.... Java, slow? I think not.
>
I've once made a game called PacmanRL written entirely in Java. Call me
amateur or whatever, but if I press too fast (like 3-4 times per sec)
the game wont be able to keep up. It runs smooth, but would skips
frames.
> I do not agree, but I'm not discussing it further. I prefer Java, you
> prefer C++. :-)
> Who doesn't like portability? :-)
The truth is, 100% RL of mine are in Java. C++ are for official tasks
^^ But c'mon, at least we have more tutorials/library for RL in C++, or
so I know. However, I do acknowledge and agree with your sayng that it
is more like a matter of preference. Like, say, Timothy is gonna do
something in QBasic just because he feels like so.
> Lots of people are sure to suggest C++ from force of habit, but
> personally I recommend avoiding it. To me, it's like trying to build
> an automobile, given nothing but some metal, a lathe, wrench and
> screwdriver.
>
> Other things you can take a look at:
> These I have tried personally:
> Python + Pygame
> Flash
> Freebasic
> Freepascal
I'm currently writing a roguelike in the D programming language
(http://www.digitalmars.com/d). As a language, it's pretty good, combining
the compiles-to-native-code advantage of C/C++ with the garbage collection
and strong typing of Java and other interpretted/JIT languages. There
isn't a decent curses port for D yet which might be a problem, though I
managed ot hack together a passable console windowing system for Windows
in a few hours (and that includes the time taken to learn the Windows
console API -- it's really easy!).
Right now I'm working on game entity serialization and instantiation,
which is a little frustrating since I'm used to C++ where you can have the
preprocessor do most of the nasty work for you. D has templates and
mixins, which are easier to read and track errors in than preprocessor
macros, but which don't reduce the amount of repetitive typing you have to
do by nearly as much (mainly because you can't pass them arbitrary token
parameters, only existing symbols). D's built-in lightweight dynamic
arrays, associative arrays and garbage-collected objects should provide
the biggest advantage over C++ for a roguelike, I think, without the
sizable speed sacrifice you make by switching to Java or .NET.
Your choice of language should really depend on what you want to do in
your roguelike. Console rendering speed is for the most part fixed by the
OS or windowing system you're running on, so the actual langue you use
won't have much effect on that. If you think you're going to end up with
super-complex maps and masses of AI running each frame then maybe you'll
want to pick a "fast" language like C, C++ or D, but in most cases that
isn't necessary. The faster your roguelike runs, the richer its simulation
can be (imagine, say, the ability to simulate every single dungeon level
at once so that the player notices the perfect passage of time when
returning to one of them). On the other hand, the more low-level the
language you choose, the harder it will be to develop and the more time
you will waste implementing things like memory management and abstraction.
Swings and roundabouts :)
Pguild will do this - stuff will happen on all levels of the dungeon,
not just the ones your characters are on.
(On the other hand, the dungeon won't be that huge.)
A.
Lua can stand alone just as well as Java, Python, Perl, Pascal, or any
other interpreted language. Lua doesn't have to be used as an embedded
scripting language, it's just good at doing so.
Well, I like the way Animal Crossing uses the system time of the Cube to
advance the environment once the game is loaded again- it analyzes the
current date/time vs. when you last played, and calculates the changes that
would have occured since, and so the world continues even though you're not
playing... or so it seems :)
As far as 'offline MMORPG' I guess you're right, what I mean is I'd like to
see the above applied to single-player(or Multi-user, like AC) games to use
MMORPG themes- resource harvesting/distribution, factions and attitudes,
entropy/decay, and others- building houses/towns, persistant(though
randomized initially) maps/zones...
And a lot of other theoretical things... multiple characters, recurring
NPCs, character marriage and the seeding of offspring, which would be
perfect in an open-ended game... free-roaming, I like the ability to go
anywhere(provided of course, you can defend yourself/support yourself in the
environment)...
It all seems a little big :) But I'll start with what I've been pointed to,
and go from there.
HA - Always Lurking
Yes start with Java, not C++, you'd learn proper encapsulation and
reasonable object/file splitting. That is a must for a RPG. With
C++ you'd just lose 2 years.
Polymorfic worlds are my favorite topic, especially with a Strong
AI. You could work a really long on that. ^_^
Best idea for start would be decide on amount of memory wasted by
your design... ~_^
Advice. Make something that works, then add a little, then add a
more, then redesign from scratch... Then make it work...
However what you wrote is somewhat simillar to questions of some
small boys on gamedev forums, with exception they wanted to create
a big MMORPG. It's a load of work, and success is not guaranted.
You can learn that also with C++.
> That is a must for a RPG.
Not really. Some major roguelikes don't use object oriented style.
> With C++ you'd just lose 2 years.
In RL programming you are going to lose years anyway:)
> Raghar wrote:
>> Yes start with Java, not C++, you'd learn proper encapsulation
>> and reasonable object/file splitting.
>
> You can learn that also with C++.
>
C++ will not force you into encapsulation. Its source files looks
like part of one big file, that are supposed to be merged together
just before compilation. Not to mention fast compile times with
Java, and easy unit testing.
>> That is a must for a RPG.
>
> Not really. Some major roguelikes don't use object oriented
> style.
While I didn't mean rigid OO style, I think that SOME roguelikes
shouldn't be examples of a clean coding style, or easy modificable
code.
>> With C++ you'd just lose 2 years.
>
> In RL programming you are going to lose years anyway:)
>
But he would have more time for that polymorfic design and other
funny stuff he looks like he is thinking about. ~_^
C++ works just as well as Java (if not better) for encapsulation and
object/file splitting. Also, I took a class in Java and taught myself
C++, and I prefer C++. Just because you had a bad experience with C++
does not mean that other developers will.
Ignore all the religious wars on programming language and OOP. Learning
a particular language isn't going to write your roguelike for you,
neither is using object-oriented techniques. Just pick a language that
appeals to you and that you have resources to help you learn. Other than
a few languages that aren't really meant to be used, you will be able to
write a roguelike in anything; although you'll meet different
difficulties depending on the language used, only with experience could
you hope to make an intelligent choice between those difficulties.
You might consider using a roguelike "engine" rather than building from
scratch. People keep making engines and only T-Engine for ToME is seeing
any use at all (and even that's trivial compared to the general Angband
variant family tree). H-World is another choice for an engine. I'm
pretty sure that are one or two others ready to use that I'm not
recalling. Well, there is Rogue's Quest, I think it's called, a rather
old engine that isn't very good and I wouldn't recommend at all.
--
R. Dan Henry = danh...@inreach.com
One class of programming in Java? Taugh yourself C++? Have you
played "Where in the 150000 lines of code is that freaky global
that I don't know its name?" game? (Wait it's not that bad, there
are tools that helps, and you could guess fairly accurately...) The
game "What does mean that strange template error message?", is
somewhat worse.
They don't teach Java programming as a in real world programming
course, they are often (and rightly) using Java to explain
elementary data structures, and some algorithms without going into
gory detalis of the reading memory from wrong address problem, and
the we crashed the school computer yet again problem.
I don't have ??? expereince with C/C++. I consider it outdated, and
without strictly defined data types. I use macro assembly 32/64 if
I need something optimalized for specific processor, Java and other
more recent languages otherwise.
Never played that game even I used to have lots of globals.
You don't have to use global variables in C++ if you don't want to.
> I don't have ??? expereince with C/C++. I consider it outdated
No, it's just another language. I believe java is based on C++,
so it must be outdated, too:)
> I use macro assembly 32/64 if
> I need something optimalized for specific processor
Assembly is outdated, though. Compilers today produce very
optimized code. If there is something slowing down it's not
the compiler, it's something you are doing wrong in the
high level source code.
> One class of programming in Java? Taugh yourself C++?
The Java class was a year-long course and I've been doing an
independent study on it since. I've been programming C++ for 3 years
now. Either way, C++ and Java are the same basic language, except Java
has less basic functionality and more libraries.
> They don't teach Java programming as a in real world programming
> course, they are often (and rightly) using Java to explain
> elementary data structures, and some algorithms without going into
> gory detalis of the reading memory from wrong address problem, and
> the we crashed the school computer yet again problem.
Believe it or not, my class taught Java as a real-world language. The
case studies for the AP test involved a program required for a biology
simulation. And, as far as I know, Java doesn't allow memory reading
for security purposes. If you try to access an invalid index in an
array, an exception is thrown. If anything, Java is a beginner's
language designed to introduce people to programming. C++ is the
language of choice for most developers, including Microsoft. It is
hardly outdated.
> > I don't have ??? expereince with C/C++. I consider it outdated
> Assembly is outdated, though. Compilers today produce very
> optimized code. If there is something slowing down it's not
> the compiler, it's something you are doing wrong in the
> high level source code.
Oh my.. I tried holding my tongue, I really did. It's just that
high-level-or-nothing programmers are so cute.
Try learning assembly. It will make you a better programmer in any
language. When you do, you'll see how "optimized" compilers really are.
In fact, the XBox is the only console ever releasd that has doesn't
have it's games programmed in pure assembly, both for more speed (and
the ability to cram more and better stuff into your games) and less
space (thank you N64).
And to poor HArold who has to wade through this debacle (with me being
at fault for my mini-rant above), my advice is to start small and add
features as you go along. Yes, it's important to have grandoise dreams
and ideas (for if you cannot make something big, bold and fun, than all
you have is an academic exercise), but you will quickly find that your
worst enemy is your lack of experience.
This isn't just restricted to newbie or intermediate programmers - I've
been coding for almost twelve years now and I'm struggling with the
scope of a massive project like writing a roguelike.
You will find yourself regretting the design and architecture of your
game more everyday - it's an inevitable part of the process. Do not be
afraid to redesign, redo or start from scratch as the need arises. Such
things often take less time than you think they do and will open the
door for bigger and better things. I've redesigned one segment of my RL
seven times! My big temptation is to "overdesign" the project, going so
nuts on the OOP or structural architecture so much that implementing
anything new requires eight lines of method/function calls.
In my excursions into the digital realm, I've found that there's a
certain boundary at around 3000 lines of code (well maybe 2000, I
comment excessively) where if your program has been overdesigned or
underdesigned it will become almost impossible to add more. This isn't
restricted to one language, I've observed this in BASIC, C++ and Java.
When I've hit this state, I've had to step back and rethink how the
program gets things done. And it always took less effort than I feared
it would. The old maxim holds true: Keep It Simple!
And do not worry that simplifying your game isn't going to accomplish
what you have been dreaming about. In my mind, the best games I have
played have combined many simple concepts into a surprizingly
complicated, but easy to grasp, structure. And I'm certain you can do
the same with your design.
Good luck and if you do need help with anything, post something or send
an email. I know for myself, I had to teach myself how to code and make
these monsters we call roguelikes, and would've killed to have somebody
to bounce questions off of.
- Chris Martens
cmartens '@t' gmail d0t com
> > I don't have ??? expereince with C/C++. I consider it outdated
> Assembly is outdated, though. Compilers today produce very
> optimized code. If there is something slowing down it's not
> the compiler, it's something you are doing wrong in the
> high level source code.
Oh my.. I tried holding my tongue, I really did. It's just that
> Try learning assembly. It will make you a better programmer in any
> language. When you do, you'll see how "optimized" compilers really are.
> In fact, the XBox is the only console ever releasd that has doesn't
> have it's games programmed in pure assembly, both for more speed (and
> the ability to cram more and better stuff into your games) and less
> space (thank you N64).
Very, very few console games are programmed in pure assembly. Most are
programmed in C or C++ (or Java for the mobile phones) and while parts of
the middleware or engine may be in assembly, it's very unlikely that the
entire game is. Do you think it would be easy to port games to three or
four different platforms if _all_ the code was in assembly?
Now maybe someone like Cave could write DoDonPachi in pure assembly, but
for games like Final Fantasy X, MGS, etc. it simply isn't viable. The
speed increases from using assembly for all the game logic would be
basically unnoticable and the development time of the project would be
astonomical,
Using assembly for a roguelike is probably the worst language decision
it's possible to make. Roguelikes are 5% engine programming and 95%
gameplay programming, with a high degree of abstraction being useful and
most code not being speed critical. As well as that, the biggest speed
bottlenecks are in the Windows or X console rendering code themselves.
Ah, hmm.. perhaps I didn't make myself clear... I agree wholeheartedly
with what you're saying and I agree that assembly isn't the
be-all-end-all language for coding. I just have issue when people think
that it's outdated, redundant and obsolete.
> Using assembly for a roguelike is probably the worst language decision
> it's possible to make.
Good god, yes. *Never* make a roguelike in assembly!
Wrong. Yes, some games for mobile phones are written in Java (J2ME to
be specific), but you forget all the Symbian applications (ie. Nokia
Series 60/N-Gage) written in C/C++, the, in the states all dominating,
Qualcomm Brew platform (C/C++), and the previously so popular Mophun
platform (C/C++), just to name a few mobile platforms not based on
Java. Gaming for mobile devices is very fragmented, it's not as simple
as write a game in J2ME and you have the world as your market...
> [snip more C/C++ vs assembly]
BR,
Björn
> *cough* bullsh!t *cough*
hmm yes.. reading it again with a cooler head and editing tools... the
proper terminology is used, Mr. Adventure... using the words "In fact,
the XBox is the only console ever releasd that has doesn't
have it's games programmed in pure assembly" is a big mistake. Wow...
embarrassed... erm...
http://ps2dev.org/ - Here's where the *bullsh!t* is deserved... most
PS2 code is a mix of C/C++ and assembly. Download some of the demos and
check the source.
My bad tho...sorry all... just get a little hot-headed sometimes...
brain stops working... :P
- Chris Martens
> Wrong. Yes, some games for mobile phones are written in Java (J2ME to
> be specific), but you forget all the Symbian applications (ie. Nokia
> Series 60/N-Gage) written in C/C++, the, in the states all dominating,
> Qualcomm Brew platform (C/C++),
Sorry, I meant to imply that in commercial game development, Java is only
really used on mobile phones, not that mobile phones only use Java. Web
applets aside, I don't know of any commercial PC games written entirely in
Java, and the few full Java apps I use (eclipse and Azureus) are massive
resource hogs.
On Thu, 29 Dec 2005 05:14:30 -0000, Chris Martens <cmar...@gmail.com>
wrote:
> Ah, hmm.. perhaps I didn't make myself clear... I agree wholeheartedly
> with what you're saying and I agree that assembly isn't the
> be-all-end-all language for coding. I just have issue when people think
> that it's outdated, redundant and obsolete.
Yup, assembly is still very useful in some places. Even on the PC it's
useful in developing GPU shaders and optimising code to use SSE (although
C and C++ compilers are starting to do that automatically now). I believe
Chris Sawyer actually developed the first two RollerCoaster Tycoon games
entirely in assembler, which may be the latest commercial PC games fully
developed in assembler -- I'm not sure if Locomotion was or not.
Happens to all of us. Especially me. That's what makes it fun to call
*bullsh!t* on others now and then... ;)
Hmmm.... Mr. Adventure... I like that.
> 150,000 lines of code?? Either you have one heck of a
There are sometimes situation when you could play with code of
someone other, and a slightly bigger project on top. My point was
C++ is bad language for anything that big.
>> One class of programming in Java? Taugh yourself C++?
>
> The Java class was a year-long course and I've been doing an
> independent study on it since. I've been programming C++ for 3
> years now. Either way, C++ and Java are the same basic
> language, except Java has less basic functionality and more
> libraries.
>
I preffer to say, it has better, more consistent, and more clearly
defined functionality. And of course better memory model, and
multithreading integrated into the language in a nicelly
abstracted way.
>> They don't teach Java programming as a in real world
>> programming course, they are often (and rightly) using Java to
>> explain elementary data structures, and some algorithms without
>> going into gory detalis of the reading memory from wrong
>> address problem, and the we crashed the school computer yet
>> again problem.
> And, as far as I know, Java
> doesn't allow memory reading for security purposes. If you try
> to access an invalid index in an array, an exception is thrown.
Yes that was my point.
> If anything, Java is a beginner's language designed to introduce
> people to programming. C++ is the language of choice for most
> developers, including Microsoft. It is hardly outdated.
Actually it's a general purpose language, designed to be clear,
remove some C++ quirks, and alow easy code transfer between
platforms.
Mickerosoft is moving to C#, and isn't example of company that
would use something effective, they are rather using things
developed by them.
> On Thu, 29 Dec 2005 06:45:52 -0000,
> bjorn.b...@roguelikedevelopment.org
> <bjorn.b...@jadestone.se> wrote:
>
>> Wrong. Yes, some games for mobile phones are written in Java
>> (J2ME to be specific), but you forget all the Symbian
>> applications (ie. Nokia Series 60/N-Gage) written in C/C++,
>> the, in the states all dominating, Qualcomm Brew platform
>> (C/C++),
>
> Sorry, I meant to imply that in commercial game development,
> Java is only really used on mobile phones, not that mobile
> phones only use Java. Web applets aside, I don't know of any
> commercial PC games written entirely in Java, and the few full
> Java apps I use (eclipse and Azureus) are massive resource
> hogs.
>
I used Eclipse on 300 MHz with 200+ MB of memory. + few apps on top
of that. What do you mean resource hog?
From what I listened about Azureus, the likely problem is bad
programming, or SWT.
Well in my spare time, I'm doing mainly research games, and high
complexity applications in Java, like arithmetic encoders that are
updating model after each encoded byte, or video codec.
But if you'd like to know at least one commertial game... Alien
flux.
> On Thu, 29 Dec 2005 05:14:30 -0000, Chris Martens
> <cmar...@gmail.com> wrote:
>
>> Ah, hmm.. perhaps I didn't make myself clear... I agree
>> wholeheartedly with what you're saying and I agree that
>> assembly isn't the be-all-end-all language for coding. I just
>> have issue when people think that it's outdated, redundant and
>> obsolete.
>
> Yup, assembly is still very useful in some places. Even on the
> PC it's useful in developing GPU shaders and optimising code to
> use SSE (although C and C++ compilers are starting to do that
> automatically now).
The difference between assembly programmer and compiler is ability
to don't use SSE2 when general purpose registers would be faster.
(Latency, throughput...) Ability to don't polute cache, preload
variables, advanced caching by MMX registers, and making use of
continuity of data in registers are reasons why assembly code could
run circles around non assembly like code. Also assembly programmer
could decide if he would like to use a crappy aproximate division,
or a fully compilant to the standard 80 cycles slow division. Of
course if someone would use a language with ability to work with
multiple types of division, and able to specify more common result
of "if" command... It would be probably called the advanced
macroassembly language.
All that is useless to RL programmer anyway. At least C++ compilers
are generating fast enough code for most of program types.
I thought asm optimizing was a thing from the past..
> Yup, assembly is still very useful in some places. Even on the PC it's
> useful in developing GPU shaders and optimising code to use SSE
> (although C and C++ compilers are starting to do that automatically
> now). I believe Chris Sawyer actually developed the first two
> RollerCoaster Tycoon games entirely in assembler, which may be the
> latest commercial PC games fully developed in assembler -- I'm not sure
> if Locomotion was or not.
AFAIK he writes all his games in assembler. He also ported Elite 2 to
the PC, which was written for Amiga in assembler. Under Windows he uses
just a little C for calls to DirectX, I think. And he didn't do
RollerCoaster Tycoon 3.
I bet you can find some more information on his website.