Messages

1

Design / Re: Info line idea

« on: June 10, 2016, 10:09:53 PM »

When I first started dropping in around here, a couple of Krice's posts caught me off guard, and I couldn't help but wonder why he wasn't banned...Since then, I've been in far more close-minded and toxic places in the real world and on the internet, and I've very much decided the world is far better place without behaviour police at all.  Getting your feelings hurt, especially by some random stranger on the internet, is a rather huge character liability IMHO, and one that we should stop encouraging people to have.

Krice, I like the info line, but does it really have to be up there?  Why not give it a little border and keep it with the other text?  I find it a bit tedious to snap back and forth across the screen.

2

Programming / Re: [Python] Looking For Some Good Examples

« on: February 17, 2016, 08:27:24 PM »

Maybe you are too young and inexperienced to remember what they said about Java when it first was released. Those kind of people believe that there is a "perfect" language in which they then believe and also it's important to point out flaws in other languages. What they all fail to understand is that the programming language is much less important than the programmer. It's of course hard to admit to yourself that you might be wrong or bad at programming.

This just cracked me up!  You see, it seems like you are trying to make some kind of jab at me for using Python, or for being a new coder, which is inherently pointless since neither of those things anyone would be sensitive about.  Of course I'm bad at programming, it is sort of assumed when someone is new .   But then you slip up big time and imply that people like Guido van Rossum and other language creators are bad programmers.  I guess one day they were trying to code something and it was too hard, so they just set about creating a whole language.  If we extend on this logical path, you'll end up making the argument that we just write everything in Fortran, or why not assembly, or hell, hard wire things with primitive logic gates like REAL programmers.  Since no one in this thread was supporting the idea that any language had any inherent advantages over any other, I really just can't see what put you on that train of thought.

Aside from all of that, "[the] programming language is much less important than the programmer."  Sounds good to me.  Therefor, I'll stick with Python since I've already started learning it and there is no reason to switch to another language.

Perhaps you don't want to be a programmer at all. If you have a lot of ideas and like to write them down, you may want to become a game designer. Try to organize your notes into a real design document. If you manage to get your ideas presented in a nice, readable form, you'll probably find someone who will gladly help you with the programming side of the project. That would be probably much better than struggling to do something you don't really want to do. I think that some of the most famous roguelike authors are actually not so great at programming, but I doubt that any one of them is a weak designer. Designing skills are kind of more important than programming (this actually applies to all game genres, not only to roguelikes), so let them develop before you grow too old . Some Python knowledge won't hurt, sure, just don't spend too much time on that until you are absolutely sure that you are hopeless as a designer.

I'm not really sure what you are suggesting here.  You make it sound like programming and design are mutually exclusive.  So I have to program other people's games if I want to program, or just design games if I want to do that?  I'm sure your intended message isn't as polemic as that, so I'll assume there is a subtlety that is lost on me.  I really do want to be a programmer, because as frustrating as it can be at times, I actually enjoy it.  I have no idea if I'll ever be "great" at programming, but I labour under the delusion that I'll be at least competent one day.  My "game" ideas have been very few and far between, thus giving very little material to try to program.  This current project is the first time I've really had a vision of what I wanted to do, and I've resolved to see it to a playable state regardless of how long it takes.  Perhaps at some point my vision will exceed my programming potential and I'll relegate myself to relying on a team, but I don't foresee it.

The only thing you really need for writing a game is stubborness anyway. Everything else is secondary and can be substituted with some more stubborness and will to stick with it. And remember to have fun too while you write your game.

I'm known for being stubborn, I'm sure it will come in handy. 

3

Programming / Re: [Python] Looking For Some Good Examples

« on: February 16, 2016, 10:30:46 PM »

My years of on-and-off again lurking have well prepared me to properly digest posts by Krice.      Seriously man, you [Krice] drop the odd bit of intelligible commentary here and there, but mostly it's just hugely negative word vomit that just isn't accurate.  Python bad at OOP, OK, opinion filed, thank you.

@Avagart  --  I read your reply some time ago, but didn't get around to acknowledging it.  Your video link opened a door to a whole section of the Python world I was until then unaware of.  I've been watching a lot of Raymond Hettinger's talks and I spent a lot of time reading more code, including Pyro.  I'm learning and therefor my idea of what "good" code looks like is evolving, at least within Python.

@Omnivore  --  Thanks, since I first made my post, I can't help but feel the anti-OOP crowd has some excellent points about following the laws of OOP for the mere sake of it, rather than to make the code better.  If something doesn't make the code better, then why are you doing it?  I looked at my meager code only a week after I wrote it and already had some issues understanding why I had done certain things certain ways.  I took that moment to decide to go through it and fully comment every class, method and function save for the painfully obvious ones.  As for not coding things until you need them, I also ripped out a bunch of    def this_menu() ---> pass    nonsense I had scattered around, since I don't have any menus yet.  Being new, I went for the low-hanging fruit instead of tackling the next step and added those useless and empty things because, hey, I'll need them later right?  People like you keep writing things that make me realize that kind of thing is just stupid.  I'll figure out my menu classes/functions when I need to implement a menu from now on.

I don't have a design document per se, but I do have a half-dozen sheets of paper scrawled full of pretty unorganized notes.  I have this nebulous mass of ideas drifting around my brain that are revolving around a common theme that I could hammer out into an actual game concept, I've just been putting it off  .   Actually, several years ago I first learned a little bit of Python, and even felt the urge to make a roguelike.  I see a post of mine from 3 years ago here asking a pretty stupid question as I was jumping in too deep trying to use Pygame and not use the libtcod tutorial.   I made it to some Cellular Automata caves I could never figure out how to ensure were joined up before I quit.  I bring this up because at that time, I had this generic desire to make a game, but I had no game in mind to actually make.  It seems an obvious flaw now, but somehow it didn't deter me at the time and I feel a lot of the roguelike and gamedev newbies that show up and then disappear again fall into this same trap.  If you don't have an actual game you want to make, how can you expect to actually make it?

You're advice about a "requirements" doc is well heeded, and hopefully you keep giving it to other newbies.  In fact, now that you've forced me to organize my thoughts on the subject, I'm going to put off fiddling with BSPs and drunken walks and actually write that design doc.

4

Programming / Re: Any programs/tool to convert images into pixel art?

« on: February 13, 2016, 02:16:27 PM »

Holy necropost batman!

Seriously man, not only was the question rather thoroughly answered already, the last post was from friggen 2013. 

5

Programming / [Python] Looking For Some Good Examples

« on: February 05, 2016, 07:34:57 PM »

I'm yet another new Programmer+Pythoner+roguedev that has been lurking around these forums for the last week or so after finishing the (in)famous python + libtcod tutorial.  I've been giving some thought about where to go next, and there is some temptation to just keep adding onto that existing code.  However, a fairly large part of me feels that in order to really know how to code, I have to code, not just follow along a tutorial or merely extend some existing logic.  When I combine this thought with the fact I really don't like the way the tutorial code is written (all one file, globals all over the place, etc.) I decided the next stage for me is to essentially start from scratch with my own code, purposefully implementing things differently to both make certain I understand the logic as well as become more comfortable with Python.

I set out to attempt to follow a lot of these "best practices" I keep reading about and try a strict OOP style.  So far I've recreated the basic "@" walking around the "." tech demo while borrowing as little from the tutorial as possible (there is some common code due to libtcod, but I tried to build all of mine from the docs rather than the tut).  I'm getting ready to move to the next steps, but this also means I'll be adding more classes and possibly files and I'm purposely committing the grave sin of trying to factor before I code.  I mean, I know I can code the next features, but I'm wanting to learn better ways to be coding them.  Inheritance with relatively dumb base classes? Composition on top of relatively smart base classes?  How big should my core "Engine" class be allowed to get? I have a lot of questions that I'm sure don't have really concrete answers, but I'm sure that there *are* answers.

I keep reading the advice here and elsewhere to "look at *good* code" and follow examples of how to structure things, and how to pass information between the classes, but there is a hitch.  I am a new programmer, so despite the fact I can find 100s of python games on Github, I have no idea if I'm looking at *good* code to learn by example.  A lot of the projects I have looked at, especially 7DRLs look like they have some terrible practices in use.  I found some with circular imports and others with dozens of global variables (not counting CONSTANTS), and this just doesn't help me learn to be able to manage a large project.

What I'm hoping for is this:  Will any of you be so kind as to point me to a (couple of) roguelike project(s) that are written in Python, use OOP and are written in what would reasonably be considered *good* code?  Obviously there are many styles of coding, but there must be a few projects that most reasonably agree on are well written.

6

Programming / Python FOV Help

« on: May 22, 2012, 10:02:27 PM »

Hi folks!  I've been dabbling at learning to program and have set my sights on a roguelike.
I've been half-following the  "Complete Roguelike Tutorial using Python and libtcod", except I'm not using libtcod.  I'm using Python 3.2.3, Pygcurse and Pygame.
Call me crazy, but I figure converting a tutorial to a new library is a better learning experience than just copying code and hoping I understand it.

Its working so well I am stumped!  I am not experienced enough to write my own FOV algo and obviously I can't used the ones included with libtcod.  So...

I found a Python permissive FOV implementation on RogueBasin @
http://roguebasin.com/index.php/Permissive_Field_of_View_in_Python

Well I can't make it work!  Specifically it does something I am not familiar with.  You call to calculate FOV with a fuction call that takes 7 arguments, 5 or which are variables and 2 are "user functions".  The variables make sense but I have no idea how you pass a function as an argument to a function.  I've tired Google and some Python documentation without any luck.

If someone can be kind enough to enlighten me, I can finish up the basic 'engine'.

Thanks in advance!

P.S. I'm not really stubborn about what type of FOV I use at this point in my Roguelike career.  Any helpful adivce on another implementation would also be helpful.