Print

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

[karmatic]

Does anybody know of an easy-to-compile source of the original Rogue? or the clones of it? I don't exactly have the time to start one from scratch but would be inspired to mod Rogue itself to my liking

Someone may correct me if I'm wrong, but I don't think Rogue was ever released as Open Source.  It was included in Berkeley UNIX as a binary, then it was handed to a commercial company afterwards and never released source.

I believe you are right.  I know there are several open-source clones but I have yet to find one that I could compile correctly

[viskaslietuvai]

@ Grishnak: I was completely excited about your friend's tutorial. Then found out it was for C when I'm trying to do my project (learning the language) in C++. Not really a major gripe, more of a "Curse you for raising my hopes and then dashing them upon spikes made of hornblende!"

[Grishnak]

Viska, even though its written in C, you can still take the basic concept and apply it to C++
Also, if you would like, I can attempt to "port" that tutorial to c++


Also, my basic map generator at work:

Spoiler (click to show/hide)

[viskaslietuvai]

Grishnak:
I think that I'll actually be able to largely get it to function properly in C++. One of the problems is I'm not familiar with curses (I'm just a newbie programmer) and from what I've seen, I'd like to use libtcod. I'll see if I can get it to function properly in C++ on my own before imposing upon your generosity.

Also, cool looking map, I can only assume that it was done with libtcod rather than curses, given the colors. Also, not sure if that's the full game name at the top or just the name of that particular dungeon, but I have similar names whenever I first try something, 'cause unexpected stuff does tend to happen. It also could be a reference the Cambodian word for temple. Angkor Wat as an example.

[Grishnak]

Good luck on your project!

Yes, that was done in libtcod, allthough the generator has nothing to do with it. ^^ As for the name, its wat as in "what", and hence the wat da fak (what the fuck) basicly place holder stuff till I got a name, which I might have now, me and my buddy are probably going to call it Lost Horizon.

Also, if you have any questions feel free to pm me with your msn or aim, and I will add you, that way there is less back and forth.

I am definately not the best programmer, but I am pretty decent, and should be able to help you with the questions you have.

[Poltifar]

Hmm, Would making a roguelike in Gamemaker actually be plausible? It's listed in the OP's post, but still. Ofcourse a roguelike *could* be made, using the built-in language and such, but would it run at a decent speed, not use too much memory, etc... If it's possible, I think I'll try to make one. I've got Gamemaker, and I'm already bored making the basic platformer/maze/scrolling-shooter games using only the drag-and-drop, so I'll try using the built-in-language to make a roguelike next. Should be a nice challenge.

Don't get me wrong, I do know a smudge of actual programming languages, including Visual Basic and C++, but I don't feel like building a whole game engine from the ground-up, atleast not for my first try at a complex game. Also, its easier to add sprites in Gamemaker than in a game built from the ground-up.

[qwertyuiopas]

No, actually, it would be easier to add sprites to a game built from the ground up with considerable forethought to the sprite process so it is integrated into the engine itself at a very early stage.

Of course, adding sprites to a significantly advanced project with no prior sprite support would be much easier in Gamemaker.



It all depends on how you set it up. If adding an enemy simply means adding a spritesheet and a few lines to a .txt file specifying the enemy, the stats, the sprite file, and any animations and states, it will be much easier to add a new enemy type to a non-gamemaker project, since the engine is set up to be able to add them easily.

[Poltifar]

Ah, then yes, I guess a non-gamemaker game would be preferable for what I had in mind. Especially since according to what you said, it should be easily possible to make the game modable, if I manage to build an engine that works off simple text files (like Dwarf Fortress). I've always liked the idea of easily modable roguelikes, withought needing to recompile and stuff.

But I think I'll try making my first proof-of-concept roguelike on Gamemaker, because I'm not sure I can handle pure code just yet.

[Willfor]

Especially since according to what you said, it should be easily possible to make the game modable, if I manage to build an engine that works off simple text files (like Dwarf Fortress). I've always liked the idea of easily modable roguelikes, withought needing to recompile and stuff.

I'm actually doing this myself. To the point where people could "cheat" (honestly, if they want to do it, who cares!) very very easily if they understood how I put it together.

I've been getting quite a bit done, but nothing much in the way of an actual graphics display. Which will likely just be a standard windows console output since the times I have tried to get SdlDotNet working for me have turned out as half successes at best. I'm just glad I've learned how to do very modular programming so it won't have to stay that way forever. >_>

[Rhodan]

Perhaps you could code the game so it's easy to have someone else create graphical front-end?
I'm not sure how to make this work, but you probably won't need to bother with SdlDotNet or any other graphics library thingy.

[Willfor]

Yeah, all of my graphics code will be in two files that could be swapped out without doing ... anything really to the rest of the program.

Though, more work would be needed to change the input settings since the ones I'm using are also the windows console controls. Though that would still be less work than if I put the code scattered throughout the project.

[Morlark]

Has anyone tried using libtcod's BSP functions? Cos I'm not exactly too familiar with C++, and all I can say is that it's confusing the hell out of me. I thought I was making some progress until I wound up getting this:

error: cannot allocate an object of type `MyCallback'
error:   because the following virtual functions are abstract:
error:  virtual bool ITCODBspCallback::visitNode(TCODBsp*, void*)

The code I've got so far is here:

Spoiler (click to show/hide)

#include "libtcod.hpp"

class MyCallback : public ITCODBspCallback
   {
      public :
         bool visitNode(TCODBsp *node, void *userData)
         {
            if (node->isLeaf())
            {
               for (int i=((node->x)+1);i<((node->x)+(node->w));i++)
               {
                  for (int j=((node->y)+1);j<((node->y)+(node->h));j++)
                  {
                     myMap->setProperties(i,j,true,true);
                  }
               }
            }
            return true;
         }
   };

void dtest()
{
   TCODBsp *myBSP = new TCODBsp(0,0,50,50);
   myBSP->splitRecursive(NULL,4,5,5,5,5);

   TCODMap *myMap = new TCODMap(50,50);
   myBSP->traversePostOrder(new MyCallback(),NULL);
}

Now, obviously, myMap is not in scope of that visitNode part, so taking a wild stab in the dark I'm guessing that's what userData is for? But when I try to put anything for userData, that's when I get the error above. Does anyone have any idea what I'm doing wrong?

[Sowelu]

You're not getting that error for anything related to scope, you're getting it when your scope stuff is correct.  The problem lies in the way you've implemented that interface (that is, in the way you've defined MyCallback with regard to ITCODBspCallback).  It's not recognizing that you correctly implemented visitNode and I'm not sure why, because my code is a tiny bit rusty where that stuff is concerned.

Read up on abstract methods and make sure you're implementing it correctly.  There might be some weird change you need to make in that function's header.  Or maybe in your class declaration.

[Morlark]

Oh, I see, thanks for the tips. I've worked out what I was doing wrong to get that error, but I'm still not quite sure how to get this thing to do what I want. I'll have a bit of a poke at it again later. Thanks for the help.

[viskaslietuvai]

This is maybe a bit too much revival of a dead thread, but I'd rather raise zombies than create duplicate threads.

I've started learning programming -slow progress being made- and have been thinking of different formulas and concepts to include in my eventual game. I know that the advice is to not leap into making your ideal project, but my idea that I've been toying with is to start with a very basic core game and then add features as I went along until it would approach what I envision it to be which is, as all pipe dreams are, fairly complex.
My question is this: Is this a recipe for certain failure? I understand that sometimes with this method that major code rewrites become necessary for large improvements (see DF's z axis and the current army arc) but I was wondering if having a base idea in mind is enough or do all the interactions of objects and functions need to be pretty carefully coordinated prior to the coding? I know that experience would probably teach me this in time, but I haven't really gotten to the point of anything complex and thought that there's a wealth of folks on that there internet who already know.