Project: Roguelike Renaissance

[getter77]

I did spot many more errors besides the ones you listed, but you did do good work (just don't be surprised to discover I made some changes to your rewordings ). But the moral of the story is: for the love of god, don't list corrections in a text file, but just fix errors in files directly, and then create a patch - there was a lot of work wasted there. I'm glad to hear that you're investing time in learning to use SVN - you won't regret it! (Of course, you can create a patch against a file that is not checked into version control, but the patch files generated by SVN have the huge benefit of saying which version of the file they were created against, which makes them much smoother to apply)

Likewise: Notepad?! If you are going to do a lot of text editing, you should get a decent text editor, or at the very least, use a utility which lets you search multiple files for a regexp. I found many typos in ToME4 by searching for "minimun", etc. Learn about using regexps. If you don't like commandline utilities (like grep), try Notepad++.

Hi!

No worries on further revisions, as I mention I'm certainly no English Major or the like.  It is necessary grunt work that I somehow don't mind doing and am able to wrangle at a decent pace for some mysterious reason---likely via still being helpless at any other helpful endeavors outside of beta testing and general game input.

Oddly enough, I got used to using Notepad and the like for this because, prior to ToME4 and Summoning Wars, pretty much everything that came my way was either in Notepad centric .txt files themselves or a situation where I had no code/file access and was going purely by ingame note-taking.  I currently know nothing of patching and the like---closest has been some situations where I just e-mail back the .txt with corrections made and the filename changed to have an 'x' at the end of it.  I would be nice if SmartSVN Foundation has some handy stuff to automate this as you outline---tis a foreign world to me.

While I don't know of/understand the meaning of 'regexps' and 'grep', (guessing the former is something registry related?) I did finally get around to installing Notepad++ the other day upon reckoning it might start to come in handy with the PLOS doings.

Speaking of PLOS doings, this week has mainly just been me .txt filing up my thoughts and experiences of revisions/crashes/etc---ingame and documentation otherwise.  Currently very stuck on map making doings....but there's probably just one or more obvious things that aren't clicking yet----next week will hopefully see more organization/completing the set-up for VS2010 Express and the SVN client above/concrete doings.

[joe]

"Regex" is short for "regular expression," which is a way to match text with a search string. For example, "[red|gold|yellow] dragon" would match "red dragon," "gold dragon" and "yellow dragon." Similarly, ".* dragon" will match any word followed by "dragon" and so will match all of the above as well as "black dragon" or whatever. There's plenty of documentation online.

Grep is a a command-line utility that prints all lines in a file or files that match a given regex.

If you end up doing a lot of coding, you'll find that using one of the major keyboard-based editors like vim or emacs and having a terminal window open is a lot more efficient and less painful than using most of the IDEs and "notepad replacements" that are out there. Being able to use revision control systems is also an absolute must - eventually, you will make a change that you want to revert.

[5v3nd0ttg]

eventually, you will make a change that you want to revert.

I almost laughed at how much I agreed with that.

[getter77]

"Regex" is short for "regular expression," which is a way to match text with a search string. For example, "[red|gold|yellow] dragon" would match "red dragon," "gold dragon" and "yellow dragon." Similarly, ".* dragon" will match any word followed by "dragon" and so will match all of the above as well as "black dragon" or whatever. There's plenty of documentation online.

Grep is a a command-line utility that prints all lines in a file or files that match a given regex.

If you end up doing a lot of coding, you'll find that using one of the major keyboard-based editors like vim or emacs and having a terminal window open is a lot more efficient and less painful than using most of the IDEs and "notepad replacements" that are out there. Being able to use revision control systems is also an absolute must - eventually, you will make a change that you want to revert.

Going to have to remember all this, as while much of it still sounds foreign to me, it also somehow seems like a sensible/logical set of notions.  Being able to do things efficiently, and quickly within reason, is surely something I'm going to ultimately be after once I get grounded on things given my concerns with "time" outright.  Quite a lot of stuff out there afterall!

[TeeEmCee]

I suggested Notepad++ as a text editor because it has a "find in files" feature and supports regexs, and probably has everything else you will need in a text editor for a while. It doesn't sound like you need a code editor. But I'm not actually very familiar with notepad++; I'm an emacs user myself. But emacs is a rather big step up from notepad.

[mariodonick]

All these suggesionts are fine, but really depend on Brian's long-term goals.

Tools depend on what exactly Brian wants to achieve and what people Brian is helping -- he doesn't need revision control if he's working for a single developer who decided not to use such a system. Brian would invest too much effort in that case. On the other hand, if he's helping a team who already use SVN, he of course should use SVN, too.

He also doesn't need Vi(m) or emacs if he wants to learn to program, say (as example), only GUI based Windows software. In these cases, VS 2010 can _really_ be a good and easy-to-understand solution -- for a start. If he wants to go cross-platform, or ignore Windows, but develop for Linux or BSD, VS 2010 is of course not a good solution.

And finally, does he want to be a professional developer one day, or is it just for experience and fun? In the case of exp./fun, he should take all advices by professionals with a grain of salt.

[getter77]

All these suggesionts are fine, but really depend on Brian's long-term goals.

Tools depend on what exactly Brian wants to achieve and what people Brian is helping -- he doesn't need revision control if he's working for a single developer who decided not to use such a system. Brian would invest too much effort in that case. On the other hand, if he's helping a team who already use SVN, he of course should use SVN, too.

He also doesn't need Vi(m) or emacs if he wants to learn to program, say (as example), only GUI based Windows software. In these cases, VS 2010 can _really_ be a good and easy-to-understand solution -- for a start. If he wants to go cross-platform, or ignore Windows, but develop for Linux or BSD, VS 2010 is of course not a good solution.

And finally, does he want to be a professional developer one day, or is it just for experience and fun? In the case of exp./fun, he should take all advices by professionals with a grain of salt.

Long term, there are many tough questions that I don't yet have an answer to.  The ultimate goal is to either function as a team member in a professional game development environ, Indie most likely, or to sell my own games and such as a one-man business entity---or a bit of both as some have managed here and there.  I do lean towards essentially multiplatform entities for future personal things to sell, as I'd surely be doing myself no favors by cutting off a potential income bearing audience like Mac/Linux folk.  Being that there are several such things in that camp, that is still a ways out there in the future.

Utter ignorance as to my aptitudes has me favoring seeking out a large variety of things to understand and sample moreso than doggedly focusing on a narrow spectrum of colors that I might not ultimately even be able to "see".  I harbor no delusions of being one of the world's top people among any one area of expertise, unless I got backed into a corner by some future project to help out with that actually needed such.  Rather, "just good enough" to be solid work/demonstrate understanding within each thing in turn is the goal for me.   But yes, what each project deals with in terms of languages, engines, and other quirks is what I'll have to seek to learn about and adapt to---as I surely wouldn't last long in a team setting being unable to understand the code and all else of others.

I hope to take in as many useful bits from professionals and otherwise as I reckon things could come in handy in unexpected ways---whatever works for me is fine by me.  By investigating this and that in the times between specific focuses that  occupy my attentions, it should lend some clues as to my Strengths and Weaknesses thus far, as well as inch me forward to what "my" languages/engines/tools/etc of choice would be for personal projects either of the free nature for my portfolio's sake and general enjoyment by all----or that which I hope to sell in order to not starve to death and whatnot while allowing for more possibilities in the future what with money being handy for software/hardware.

[getter77]

Ah, the good feeling of technicality progress, OP updated.   

[Etinarg]

Sometimes I think, the information on the internet is much too unstructured to be of use for you, getter77.

I'd think it could help to learn by slices ...

Like

- Goal: Make a simple "hello world" program in C

1) Get the tools needed to develop C
2) Learn as much about C to create a hello world program


After this, you have an impression if you liked the process, if the tools worked; maybe also where the tools that you chose were lacking. Also, if you are comfortable with the language or want another one rather.


I've been used to learn from books. Nowadays I use the internet for searching information, but this is easier with the background knowledge from the books. There are bad books, admitted, but good books really help a lot to get into something, like programming. Or to learn the basics of painting. Or photography ... many topics I think.

I'd say, try to books to learn the fundamentals of topics, then try the internet and looks for the  information that the books did not contain.

[getter77]

I've got a smattering of books within my bookmarks pointing towards Amazon relative to various entities within the lot of this, just a matter seeing how it goes versus online sources human and otherwise.

As to the hello world idea, I'd thought of something similar on the personal projects end once I get some general understandings from this stint with PLOS.  Rather than hello world though, my notion would be to recreate the backbone of one game type or another from language to language...engine to engine---displaying something, sound functioning, movement, triggers, etc relative to whatever.   My reasoning is that the classic hello world example might not give an accurate impression of how a given thing handles the variety of responsibilities it would have to live up to in realistic terms of game development.  That said, this site will probably give me an idea of the look of various tings.     http://99-bottles-of-beer.net/

OP updated as well!

[Etinarg]

my notion would be to recreate the backbone of one game type or another from language to language...engine to engine---displaying something, sound functioning, movement, triggers, etc relative to whatever.   My reasoning is that the classic hello world example might not give an accurate impression of how a given thing handles the variety of responsibilities it would have to live up to in realistic terms of game development.

I agree up to a point. Such a backbone is quite a huge task for a beginner, because it requires knowledge in many fields.

- Language syntax
- Methodology (procedural, functional, object oriented ...)
- General handling of data
- General handling of events
- Domain specific knowledge: Sound, Graphics
- Representation of game objects in the chosen language and methodology

I may have blown up this list a bit more than necessary. But I hope to show that such a backbone needs a lot of knowledge in a lot of fields, and I think it is too big for a training project, unless you already know about at least 30% of the issues.

Besides the points above I'd like to add:

- User interface design

or, more general, human-machine-interaction. It is not a key to success, but if you do it wrong, people will not like your products. So it is important to know about it, for the later projects of yours.

For the huge list of books, I'm not sure if this is good. My first book to learn C was bad. The second one was good, and got me going. You don't need more than one book for this, if you get the right one at the beginning. try to shrink the list to the essentials, and get one book - to get into programming, I'd either suggest a language specific book, or a methodology specific book. The more practical people will like the first, the more theory inclined the latter.

I'd save on books about game design, graphics and such until you have a firm idea of how programming languages work, what sets the one apart from the other, and which methodology suits your way to think the best - for example, some people like to think in objects, others find object oriented programming very counter-intuitive. You must find out what suits you, or train yourself to "think" in the way that fits to your tools. If it means something, it took me 3 years to get used to object oriented design after some years of procedural design work, and I never really got a good grasp on functional programming, although that is a very mighty concept too.

[getter77]

Surely it is complex, but then again, it is plain to all that I've got a lot of work cut out for myself.   I still have to check for the obvious though outside of it being made clear by others...IE:  I probably need not concern myself with D: anytime soon as I don't think it is quite "there" in terms of the range of game dev features versus the likes of C# or some such---that helps!  Most of the books I've bookmarked are of the general sort moreso than language specific, though there are surely some of them as well.  Really, I've quite a lot of bookmarks despite being regularly amazed at regular gaps I discover in tit. The notion in the back of my head is to investigate more personally, for the most part, each "thing" in turn after being introduced to it withing a given project I'm helping out on and coming to work with it from there.  For some other things, well, I may have to roll the dice ahead of time for monetary concerns:  For example, depending on how things time out, the next major release of the Unity3D Engine carries with it a rather not minor pre-order discount...and the writing on the wall seems to be it will be a significant player in the times ahead up against the like of UDK far moreso than the likes of Torque and such.

I'd like to think I'll walk away from the work on PLOS this Fall/year with a far better understanding of all the various parts and interworkings in game design, along with my first slate of technical/artistic skills.   As time passes up to that point, any number of chances to the side to work on and learn other things can avail themselves----I hope.

The biggest thing is minimizing disruptions in everything regarding working/learning and successfully managing rather robust marathons on one thing or another just as soon as I can get a grip on it---like art or populating an item list and the like.

[Etinarg]

IE:  I probably need not concern myself with D: anytime soon as I don't think it is quite "there" in terms of the range of game dev features versus the likes of C# or some such---that helps!

Why not stick to the traditional languages for the start? Most roguelikes are written in C, so there is a lot of previous experience. Example code, and people whom you can ask for help, because they already wrote a roguelike in C.

Also, once you know one language of a kind (I'd classify C as a procedural language here), it is fairly easy to move to another one of the same kind later.

Unity3D, UDK (Unreal development kit?) and Torque seem very much overpowered, and even unsuitable to make a roguelike. or do you have other plans? These tools are more geared towards 3D games, if I'm not mistaken, and that again opens a new domain to learn, at least if you stay a lone wolf developer - modeling, rigging, skinning and all these questions that are unique to 3D graphics. 2D allows you to paint a lot of things, and you can start with less knowledge and skills ...

For monetary concerns, I'd say stick to free tools and resources. For training projects, or first games, these are good enough. The open source community is huge, and has created a lot of free and good tools and libraries.

[getter77]

IE:  I probably need not concern myself with D: anytime soon as I don't think it is quite "there" in terms of the range of game dev features versus the likes of C# or some such---that helps!

Why not stick to the traditional languages for the start? Most roguelikes are written in C, so there is a lot of previous experience. Example code, and people whom you can ask for help, because they already wrote a roguelike in C.

Also, once you know one language of a kind (I'd classify C as a procedural language here), it is fairly easy to move to another one of the same kind later.

Unity3D, UDK (Unreal development kit?) and Torque seem very much overpowered, and even unsuitable to make a roguelike. or do you have other plans? These tools are more geared towards 3D games, if I'm not mistaken, and that again opens a new domain to learn, at least if you stay a lone wolf developer - modeling, rigging, skinning and all these questions that are unique to 3D graphics. 2D allows you to paint a lot of things, and you can start with less knowledge and skills ...

For monetary concerns, I'd say stick to free tools and resources. For training projects, or first games, these are good enough. The open source community is huge, and has created a lot of free and good tools and libraries.

It may be that traditional languages are the start---actually I suppose it would be now as PLOS will have me using Visual Basic 2010 Express for the first time ever and, IIRC, Visual Basic has been around awhile in some form or another.  If I get to help out in a projec that uses something else like Java and the like, well, time to learn on Java as well.     I'm still not near the stage of the Grand Roguelike Hunt with some targets listed in the OP...at least not the programming centric ones. Otherwise, I find myself somehow intrigued by "newer" languages, perhaps out of some vague thought of "If these are going to gain ground and possibly replace some of the older ones in the developing future, might I be well served to get in on the ground floor while everybody else is also at a roughly comparable starting line?"  Same thing for Engines and the like, as it would strike me as a colossal waste of time to try and come up with my own Engine outside of some rather novel situation where a suite of ideas in my head simply can't be done properly in a modern one available to me(It is a crazy thing Journeyman is managing with the Incursion rewrite...check his last news post or so!)----to writ, it then becomes a given to be familiar with the strengths and weakness of at least the biggest/actively developed modern engines.

I hope it is easy for me to go from one language to another once I understand programming in general---I've seen anecdotes on both sides of the fence and can't help but be a bit nervous as to which one I'll end up on and potentially having to slog the rest of the way onward.   

My plans both include and go beyond Roguelikes in terms of game development ideas and aspirations----though mainly it involves an infusion of Roguelike sensibilities such that I think would enhance other genres.  I am more of a 2D versus 3D person, but then again, especially with the cusp of the "other" kind of 3D seemingly having arrived for real this time---who's to say where my fancy and, more importantly, knacks may lie?  Just to discredit myself further, I DO have ideas even more/at least about as radical and unorthodox versus the craziest of the Talkies buried in the annals of the Newsgroup and Basin---though I elect to keep those under my hat until I can actually get things physically done to sidestep that "Talkie" designation and having Krice think I need more mental health procedures and treatments than he already does   

Unity3D, name aside, can function pretty decently in detailed and active 2D doings as Arcen Games elected to use in in their 2D puzzler Tidalis(Quite nice actually, I've not gotten into a puzzle game outside of Tetris in a long time) and will also be porting their well received AI War franchise to it in the near future.  Also....it just seems very nifty(especially the features for Version 3 coming sometime this summer) and the license terms for free use are quite appealing in general----could well be that I'd ultimately have no use of the Pro version  features and I think I can cry myself to sleep just fine for a $1500 upgrade should I make more than $100K selling a game made by myself.

Free tools, so long as they don't preclude me from trying to earn a living via selling what I make with it aiding, are surely in the cards.  I will, though, freely admit to having a bias towards something I can learn from scratch on and use up through releasing for sale, as opposed to learning on one thing that is mandated free then having to migrate to something else entirely  to release likewise. That said, again for hopeful employment aspirations, working or demonstrable knowledge of various 'not-free', but clearly useful/popular, software certainly couldn't hurt me.   It also shouldn't be outside the realm of possibility that some paid software serves me better than a free alternative in terms of the learning curve, ease of use/UI, and so on----as a money/time  time/money threshold isn't exactly unlikely in my future.   : (

[Etinarg]

If you want to got professional, it is a good idea to investigate the non-free tools, since some of those are really a notch up from free tools. Tools like Poser, or maybe Maya for 3D content.

On the "new vs old" programming languages: I just recently saw a chart that claimed that C is the most commonly used language again after some year of other languages being in the lead. C was invented in 1972, and now 38 years later is still very common, or even the most common language if the chart was right. I agree that newer languages might have features which the old ones didn't have - but being in use for 38 years, and ranging among the top still, seems to say to me that it has proven it's suitability for a real lot of applications.

I don't want to say everything new is bad. I just think for the first steps it is good to use something well known and proven. From such foundation you can start to explore the more experimental grounds.

Best of luck with your plans