Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Aqizzar]

One of my peeves is that everything has to be arranged downward in the file, so that stuff is specifically declared before it's used.  That doesn't help me, I need to be able to reference stuff wherever I think of it later.

Well, not need.  That's why it's just annoying.

Any half-decent IDE will let you have your header file and your .c/.cpp file opened in different tabs, so you can add a declaration anywhere in your header and then use it anywhere in your code...

<--- Lazy Newb

[Sowelu]

C# doesn't have those restrictions, it kind of eliminates the concept of the header file and lets you declare functions in any order you want.

[qwertyuiopas]

Funny thing is, header files are just stuck into the file, replacing the #include, at compile time.

You can easily add function prototypes directly, not just to headers.

[Rhodan]

My pet peeve is when the compiler tries to do all kinds of 'helpful' stuff for you when you begin a new project.
I just want to type stuff on an empty page and compile it.

[qwertyuiopas]

Notepad.
Notepad and MinGW.

[Sowelu]

Funny thing is, header files are just stuck into the file, replacing the #include, at compile time.

You can easily add function prototypes directly, not just to headers.

It's frequently important to include class prototypes, too.  Like if class A contains a pointer to class B, and class B contains a pointer to class A, they can whine if you #include the headers in each others header file...  But just saying 'class A;' and 'class B;' at the top of each others header will often get the job done.

[Fenrir]

I have a rudimentary inventory system working.


POWERGOAL:
The fight didn't go well: you lost your weapon and your clothes are in tatters. Caked in filth, you pass by two elves who begin to jeer at you. You quickly grasp one by the legs. Both victim and weapon scream as you slam one into the other.

[Aqizzar]

I have a rudimentary inventory system working.
[pic]Fenrir_of_Ironwood/liveammo[/pic]

POWERGOAL:
The fight didn't go well: you lost your weapon and your clothes are in tatters. Caked in filth, you pass by two elves who begin to jeer at you. You quickly grasp one by the legs. Both victim and weapon scream as you slam one into the other.

DF SUGGESTIONS NOW

[Fenrir]

I'll need to look through the development pages; Toady may have already thought of that.

[EchoP]

Python + Pygame = Life!
Got collision, drawing and event handling going. Good times 

[Fenrir]

Show off.



I kid, I kid. Keep up the good work!

[CapnMikey]

Yay

Random opinions (mostly in the "if you're new to programming" category):

• If C++ has struck your fancy, do consider C#!  It has alot of nice language feature that ease the learning curve, make it easier to write object-oriented code, and handles data in a way that's very helpful for rogue-likes.  It's also quite similar to C++ if you want to pick that up later.
• If you're using C++/C# and don't despise M$, check out Visual C#/C++ Express.  Visual Studio is a very slick development environment, with lots of helpful features.  Caveat: you need a pretty fast CPU and lots of memory to run it comfortably.
• Scripting languages (Python and Lua are very popular) are probably an even better choice for a rogue-like, again for the way they handle data.  If the main reason you skipped these are speed/efficiency reasons, I implore you to reconsider!
• ***Good coding practices are a double-edged sword when you're starting out.  They are all true, but misapplied they can do more harm than good.  The most important rule that trumps all coding rules: coding rules are there to make your life easier.  If they seem to be making your life harder, they are not doing their job.  That's probably because you're doing something wrong (which is fine, you're just starting out!), but you'll get more accomplished and save lots of frustration by ditching them for now instead of blindly following them.
• Try not to think about efficiency unless it's causing a problem.  Don't worry about speed optimizations unless something is running problematically (or at very, very least perceivably) slow.  Don't worry about space optimizations unless you're running out of memory or accumulating 100MB save files.

*** Grain of salt, this departs from conventional wisdom, but is something I've found very, very true in my experience.

I may be able to help with general programming, or specific (C++/C#) questions, though I am not familiar with any of libraries mentioned (except .NET).

[Ampersand]

I can't seem to find any good textbooks on ruby or python. If I could get my hands on the source code for Isefad, I could probably learn a lot. It's only available through subversion, though, and I've never used it.

However, as far as python goes.

http://sourceforge.net/projects/pyrogue

The source code is available in a zip file off of sourceforge. It is also apparently abandoned.

[CapnMikey]

Subversion is really neat and easy to use!  It's pretty much like an FTP client made by coders for coders, with lots of cool goodies that only coders would probably care about.  (I can't believe I forgot to mention version control!)

If you download and install TortoiseSVN I can walk you through the rest of the process, which will probably take between 15 and 45 seconds.

[Sowelu]

More advice:

If your algorithm seems WAY too slow, maybe you're doing a very minor thing wrong!

When I first implemented A*, I had a bug in my heuristic...It was still admissible, but my move cost was 10 per space and I used a Manhattan-based heuristic with a multiplier of 5 * distance.  Which makes no sense to people who don't know A* but will make people who do know it cringe   I was really worried because a search from one corner of my map to the other took a second or two.  Well, with that bug, it fanned out to search the whole map...when fixed, it's a negligible number of milliseconds, and when I'm compiling in release instead of debug, it's down to microseconds I think.

Just one number fixed my huge slowdown...That can happen a lot.

So don't be discouraged by slowness, and don't think "I have to optimize".  Instead, think "Am I implementing this algorithm wrong".  Getting your algorithms right is WAY more important than trying to trim a few instructions out of a tight loop!!