Temple of The Roguelike Forums
Development => Programming => Topic started by: CoachWade on March 02, 2009, 05:07:31 AM
-
Greets everyone.
I have been kicking around an idea for a video game for some time, and I've decided that the best way to develop the idea is not to go with the graphics intensive look that permeates modern gaming, and instead stick with traditional ASCII graphics. I've not been a big player of Roguelikes myself because I don't care for things like permadeath. Also, for some bizarre reason, the authors I'd most want to see games for have been largely left out (David Eddings, Terry Pratchett-- although there is a Discworld version of Angband, Christopher Bunch, etc.) in favor of authors I don't really care for. (No one beat me, please, but I seriously can't STAND J.R.R. Tolkien, Anne McCaffery, or Roger Zelazny. It's like there's a conspiracy to make roguelike games ONLY in worlds I personally don't like!)
Having said that, I'm astonished of two things: 1) There are no game engines out there for development of your own roguelike. I'm not sure why, but every RL I read about has been programmed from scratch using source code. Since I'm not a programmer, this leaves me with a creek and a canoe but no paddle.
And 2), why has no one developed a roguelike for the granddaddy of them all? I'm speaking of AD&D 1st edition.
We have at our fingertips a complete gaming world that needs only to be programmed into a roguelike gaming system. We have monsters, courtesy of the Monster Manual I and II. We have a campaign setting, courtesy of the DMG, and we have three classes with five races to draw from in the PHB.
This is my plan. I'd like to develop a roguelike game (preferably a cross-platform one) that would be based in the AD&D worlds (Likely some setting similar to Forgotten Realms). It would have an overarching storyline (I've actually written three or four of them already.) but would feature the traditional roguelike random dungeons and monster placement.
If anyone can point me in the direction of a rogue game engine or a developer looking for his next project, I'd like to see this thing moving forward. I think there's enormous potential for a great game series there.
Thanks!
~D.
-
There have been a lot of attempts at engines but its a thing that spirals out of control very quickly. feature creep and lack of proper design document etc. roguelikes are an order of magnitude more difficult, unlike IF, there is no well developed world model type design.
why 1sted over 2nded or 3.5ed or boring d20? why not any of the other million classic rulesets?
one of the problems is that every RL programmer has their own ideas and rec.games.roguelike.development is littered with engines and ideas and things that never go anywhere once people realise the size of the scope.
-
Having said that, I'm astonished of two things: 1) There are no game engines out there for development of your own roguelike.
Yes there are, several even. One of them is called T-Engine and can be found here: http://t-o-m-e.net/
I haven't used it myself (I like programming my own) so I can't tell you how easy or hard to use it is, but there's a wiki and forums on that site, as well as examples (maybe even a tutorial, I don't remember exactly).
You can also go the angband variant route, which is very well traveled and is basically a de facto roguelike engine. How tos/tutorials are available, use your google-fu to find them :)
-Ido.
-
There's no roguelike engine that really makes it easy, mostly because for any roguelike the core system still has to be freshly designed. All roguelikes have different combat systems, magic systems, item types, etc. The best an engine could hope to do without strangling the potential of any title would be to simply provide easy display abilities and some code for common functions like dungeon generation and FOV. And that's exactly what libtcod (http://thedoryenlibrary.appspot.com/) does. A library of common roguelike functions that makes some of the basics easier to start out (and makes everything look pretty).
As for D&D based roguelikes, check out Rogue itself, or Hack, ADOM, Incursion and several others. Most roguelikes have heavy D&D influence on some level of detail, especially when it comes to monsters and items. Only really the *bands are dominated by Tolkien (and even that can be seen as just a flavour thing).
-
as you confess you are neither a roguelike afficionado nor a programmer.
Let me therefore tell you that the retro look of the roguelike is decieving!
Graphics are easy: in a roguelike its print x, in a graphical game its put x. thats the only difference in the code there.
Random levels are not: It basically means that you need to program something that can compete wit a human level designer. And there are people out there who can make a living out of designing levels.
frankly there is *a lot* under hood in your average roguelike, and except for the basic stuff (there are librarys for that) it doesnt lend itself well to generalization.
2nd straight AD&D.
Dont get me wrong, i love 2nd ed and wouldnt touch 3rd ed with an 11 foot pole. But there are 2 reasons why it doesnt lend itself well for a computer game in general, and a roguelike in particular.
1) Exceptions, exceptions, exceptions to each and every rule.
2) its party oriented. single L1 wizard going adventuring? In a roguelike? (Go to dungeon, cast magic missile, run away, get out, rest 24 hours, repeat) ;)
If you are mainly interested in AD & D check out this site and forgotten realms unlimited adventures:
http://frua.rosedragon.org/modulelist/classic.php
-
why 1sted over 2nded or 3.5ed or boring d20? why not any of the other million classic rulesets?
Hi Stu;
I think you answered your own question there, actually. While I have played every published edition of AD&D I absolutely detest the direction the games have moved since 1998. Wizards, especially, has taken the focus less from role playing and more towards roll playing. Where 1stE thieves had to disarm a trap by using their wits (I take a tent spike from my pack and use it to jam the pressure plate.) now it's simply, "I roll to open the lock. There, done! What treasure did I get?"
I don't want to spark off a firestorm here. D20 is someone's favorite system after all, but I don't care for it. (And I'm not interested in an argument about it, either. I don't like lima beans and I'd rather no one else tried to convince me that they are better than snow peas, which is an argument that makes about as much sense as trying to convince someone else what version of AD&D is the best.)
1stE is simple enough (Four character classes, no kits, no weapon proficiencies, basic skills, if used. Simple character leveling) and well documented enough (Full random monster tables, expansive treasure system, effective weapon lists.) that it could be used with minimal trouble-- provided that some clown with more talent for coaching football than programming doesn't cock up the works.
I also feel that 1stE and 4E (or any step in between) are pretty much different games with different mechanics and systems. Really, there isn't a whole lot that is the same between 4E and 1E-- you could just as easily compare GURPS and 4E or Earthdawn and 1E. All of them are fantasy RPGs with different rolling systems.
So that's my rationale. Next on the horizon: a Star Wars roguelike.
Maybe I should finish this one first, eh?
~D.
-
Ido;
Thanks for that link. I ran several searches and didn't see anything reasonable come up. I'll give it a look see and let you know what I think.
Thanks!
~D.
-
You're welcome - look at the modules page for a few examples, i am sure you can find a sufficiently small/simple one to start from.
-Ido.
-
as you confess you are neither a roguelike afficionado nor a programmer.
Let me therefore tell you that the retro look of the roguelike is decieving!
Actually, I didn't select rogues based on a perception of simplicity, but on a perception of complexity. There are about two dozen 3D game engines out there that could be used to develop an RPG with a AD&D flavor, but I wanted something that met the following five criteria:
1) Minimal processor and graphics use. I want this to be playable on my Asus EEEPC 901 as well as on a top of the line gaming system.
2) Complexity in character. AD&D uses six traditional statistics that all have affects on gameplay: Strength, Dexterity, Constitution, Intelligence, Wisdom, and Charisma. The best engine I found other than a rogue was a 3D engine requiring some preposterous graphics card-- and that only allowed four player stats that actually had a noticeable affect on the game.
3) Unlimited scope of weapons, treasure items, and monsters. AD&D 1E has four key books FULL of detail that can be added: DMG, PHB, and both MMs. Rogues allow for this more easily than drawing 3D graphics. (Even a tile set would take forever.)
4) Story over graphics. Tying into #3, I would rather spend time writing a decent storyline than drawing pictures. For one thing, I have much more talent as a writer than as an artist, and for another, pretty pictures look nice during the first ten minutes of gameplay, and then they are forgotten in favor of the story-- if the story is well done. The local gamestop has shelves of games with pretty graphics and atrocious story and gameplay.
5) Flexibility and inflexibility where needed. AD&D has a lot of interpretation for the rules. (Who, for example, EVER uses level limits for non-human PCs?) Rogues seem to offer unlimited flexibility in delivery of content, and yet can also be set to be rigid where necessary to keep players focused on a goal.
Random levels are not: It basically means that you need to program something that can compete wit a human level designer. And there are people out there who can make a living out of designing levels.
I'm not certain what you mean by this. Every roguelike ever programmed has an engine capable of developing levels at random that can compete with a human level designer (apparently). I mean, we're all still playing them for one reason or another, right? (Although I just started, of course.) About the only necessary change would be to assign specific sections to each level and randomize the rest.
Take Diablo. The levels are random, but "somewhere" on level four will be the Butcher's den. and "somewhere" on level five will be the poisoned well. Everything else, including monsters, is random.
2nd straight AD&D.
Dont get me wrong, i love 2nd ed and wouldnt touch 3rd ed with an 11 foot pole. But there are 2 reasons why it doesnt lend itself well for a computer game in general, and a roguelike in particular.
I think you misunderstood me. I want to do this in AD&D FIRST edition. Second edition, as you mentioned, has too much flexibility to work well without a human referee. First edition is a different game than anything d20 based.
1) Exceptions, exceptions, exceptions to each and every rule.
Not really. Everyone plays by house rules, thus the game would have its own rules assigned by the DM-- in this case the game designers. It's the same philosophy that brought us "Pool of Radiance" and "Baldur's Gate."
2) its party oriented. single L1 wizard going adventuring? In a roguelike? (Go to dungeon, cast magic missile, run away, get out, rest 24 hours, repeat) ;)
I had actually considered this and come up with two potential scenarios.
a) A multiple-character party. This would be more like real tabletop gaming and more fun, but harder to program and likely necessitate the development of an engine just for this game. If this were to be the final solution decided on by the development team, I would envision a four-character party similar to Ultima III: Exodus. (Especially when considering that there are four character classes available: fighter, mage, cleric, and thief.) Players could double up (two fighters, one thief, one cleric) or go nuts (four thieves) just as they did with the eminently playable UIII. (Still one of my favorite games, thank you Leon of Lairware!)
and b) Playing mages is damn tough. If you pick a mage you're at a disadvantage. Consider the original Diablo. About 1/3 of the monsters were magic resistant, including Diablo, who was resistant to ALL forms of magic (except Holy Bolt, I think-- like you're going to use a weapon that does 3-6 points of damage against a creature with 1400 hit points!) Playing a mage meant you got dead most of the time.
Really, I don't see it as all THAT much different from Castle of the Winds, where magic is key to survival, and resting means that you generally get bum-rushed by every creature within a 600-square radius. If a mage needs to rest to regain spells, fine. He does so at his own risk-- after all, no one bent your arm and demanded that you play a mage.
If you are mainly interested in AD & D check out this site and forgotten realms unlimited adventures:
http://frua.rosedragon.org/modulelist/classic.php
I will, thanks!
Please don't misinterpret my responses. You are both a programmer AND a roguelike afficianado, so I value your input. I'm not arguing with you, merely stating the things I have thought through as I have considered this project. Your responses made me do some further thinking, and I appreciate that.
I still think this is a doable project, but I need someone with some programming expertise involved. I'm not sure that even a preprogrammed engine will be able to cut the mustard on this bad boy.
-
I still think this is a doable project, but I need someone with some programming expertise involved. I'm not sure that even a preprogrammed engine will be able to cut the mustard on this bad boy.
I'm afraid you have a rather low chance of finding someone to program your design for you (unless you offer to pay for it of course). You'd probably be better off learning how to program, it's not so difficult and you will gain a remarkably marketable skill in the process.
-Ido.
-
I'm afraid you have a rather low chance of finding someone to program your design for you (unless you offer to pay for it of course). You'd probably be better off learning how to program, it's not so difficult and you will gain a remarkably marketable skill in the process.
You're probably correct. However, learning to program with an end goal in mind is a bit different than having programming experience and moving on to an extensive project.
By that I mean that learning to program from scratch is one thing. Learning to program from scratch on a multi-thousand line programmed game is something else. At my current "Hello World" level of programming expertise, simply understanding the dungeon creation algorithms and how they are used is asking quite a bit.
Realistically, I think most people, and I am no exception, would hit the wall of frustration early, put the program away, and never complete it. I'd rather work with a programmer who can help me along as I gain expertise, but generally prevent me from stepping on my weenie.
It's not so much a desire for someone else to program my opus as it is a desire to actually complete the darn thing once it's started. I know where my skills and talents really lie, and programming ain't it, so I'd like to play to my strengths and shore them up with the talents of others.
IF, of course, that's possible, and it may not be.
~D.
-
What i meant is that random map generation is one of the bigger hurdles in developing a roguelike.
I must confess that i never spent much time looking at the differences between 1st and 2nd (and never allowed that fancy skills and kits stuff anyway) ;) but ...
One example: the 6 attributes. we obviously need 6 variables, from 3 to 18 to store them, right? no. there is strength 18/01 to 18/00. The other 5 dont have that, so we need 5 variables +1. Ok, next boni and mali. Each stat has its own table, so we need 6 tables again to store them. Lets move on to spells: Sleep. IIRC it puts 2d8 creatures to sleep, max 4+1 and starts with lowest. So we need to code a routine that sets aside the monsters that can be affected. The only other spell that works similiar off the top of my head would be death. yet it works only similiar, not the same. so we need a new routine for that one. And one for the power words. with fairie fire again an almost but not quite the same method is used to determine targets. Dragon Breath works different than any other firebreath, or a potion of firebreath. Thieves can hide in shadows, halflings can hide in shadows, but each works differently etc.etc.
At the table its nothing to write home about, but in a CRPG each method would need its own routine, for an almost indistinguishable effect.
Actually if you look at the AD&D CRPGs they in fact often improvised a little with the spell effects.
As rule system for a CRPG or roguelike its just not an ideal choice because there are too many rules and too little system. Its not impossible or stupid to try, its just .. a bit on the tedious side to implement faithfully.
-
Double post, sorry
-
I'd rather work with a programmer who can help me along as I gain expertise, but generally prevent me from stepping on my weenie.
The thing is, the programming (at least at the beginning, which can last quite a long while) is the hard part. If someone is putting in the effort to code a game, they will want to do the fun parts themselves too (i.e. design the game and have creative control).
You will have better luck trying to get into someones existing project and trying to work with them to improve it. For example- maybe you can take a small game and add a bunch of interesting items, monsters & skills to it? I'm sure a lot of people wouldn't mind getting help that way.
Maybe rewrite&expand the story? make the quests more interesting? Talk to the programmer and figure out how to make existing stuff better, and so on.
-Ido.
-
I think you answered your own question there, actually. While I have played every published edition of AD&D I absolutely detest the direction the games have moved since 1998. Wizards, especially, has taken the focus less from role playing and more towards roll playing. Where 1stE thieves had to disarm a trap by using their wits (I take a tent spike from my pack and use it to jam the pressure plate.) now it's simply, "I roll to open the lock. There, done! What treasure did I get?"
Thats ok, I'm a Fuzion guy.. if ever there was a less loved system :)
-
You're probably correct. However, learning to program with an end goal in mind is a bit different than having programming experience and moving on to an extensive project.
By that I mean that learning to program from scratch is one thing. Learning to program from scratch on a multi-thousand line programmed game is something else. At my current "Hello World" level of programming expertise, simply understanding the dungeon creation algorithms and how they are used is asking quite a bit.
It's not so hard. I picked programming up from scratch last September, and got a basic game out in January, in spite of having very little time to learn or do work on it. And I started from absolute scratch, inventing my own line-drawing algorithms and so on (because I was too dumb to read other peoples code). Free Pascal helped a lot - it's very easy to learn if you have no coding history. If you want to code purely for gaming then you really don't need to know much programming - just some basic display and math libraries and how to handle conditions and loops. If you want a well-coded game you can learn pointers and OOP, but it's actually not necessary. Another important thing to remember is to start out small - your ideas are big, and won't get anywhere unless you start out with an extremely stunted version of them.
For help on learning some basics it can do a lot of good to read some article on RogueBasin. An excellent starting point is this one:
http://roguebasin.roguelikedevelopment.org/index.php?title=How_to_Write_a_Roguelike_in_15_Steps
-
Actually if you look at the AD&D CRPGs they in fact often improvised a little with the spell effects.
As rule system for a CRPG or roguelike its just not an ideal choice because there are too many rules and too little system. Its not impossible or stupid to try, its just .. a bit on the tedious side to implement faithfully.
Magellan, this is EXACTLY the sort of feedback I was looking for on my ideas! Thank you!
I've been thinking about exactly how I might implement various of these. I think your idea of adding a seventh statistical variable (to cover the variance from strength 18/01 to 18/00) is a solid one.
As for the spells, I think that it would start with selected spells at first, especially direct damage and direct defense. (Magic Missile and Shield, for example.) These would have immediate and easily developed affects, I would think (Everything is easy when you haven't got a clue how the hell it's done!)
I was also considering how spells would recharge, and I think that "sleep and study" might not be as effective as the standard gaming tradition of "spell points" that gradually recharge (I was thinking of about one point per round.)
This is great stuff, guys. Thanks everyone for the feedback and ideas! I don't know if this will ever happen, but if it does it'll be as a result of all your input!
~D.
-
Maybe right the story? make the quests more interesting? Talk to the programmer and figure out how to make existing stuff better, and so on.
I have definitely considered that and I think it would be great. If nothing else it would help me cut my teeth.
Actually, I really like that idea. Right now I'm a student teacher, which means that I'm working in a classroom under the watchful eye of a host teacher with 23 years of teaching experience.
The most ideal way to gain experience in this sort of project, in my (inexpert) opinion, would be to work on someone else's project, have them give short assignments ("Code this dungeon." "Insert these new weapons into the game.") and keep them out of trouble.
This is the way teachers are trained, coaches are trained (usually a coach spends years as an assistant before taking a position as a head coach), and even military and civilian jobs train their people. It's almost like "shadowing."
I really think it's a GREAT idea.
So, who needs a complete and utter liability... er... I mean who needs a writer with no coding experience to help them develop their roguelike?
-
It's not so hard. I picked programming up from scratch last September, and got a basic game out in January, in spite of having very little time to learn or do work on it. And I started from absolute scratch, inventing my own line-drawing algorithms and so on (because I was too dumb to read other peoples code).
Yeah, but you're smarter than I am, Darren. :)
Free Pascal helped a lot - it's very easy to learn if you have no coding history. If you want to code purely for gaming then you really don't need to know much programming - just some basic display and math libraries and how to handle conditions and loops. If you want a well-coded game you can learn pointers and OOP, but it's actually not necessary. Another important thing to remember is to start out small - your ideas are big, and won't get anywhere unless you start out with an extremely stunted version of them.
For help on learning some basics it can do a lot of good to read some article on RogueBasin. An excellent starting point is this one:
http://roguebasin.roguelikedevelopment.org/index.php?title=How_to_Write_a_Roguelike_in_15_Steps
This is more great stuff. I was looking at Free Pascal earlier today and there seemed to be a lot of resources out there to support new learners. I noted there was something that Christian Knudsen of AsciiSector used called "SDL" that apparently makes the games easier to code as well. (But I haven't got a clue what that is.)
I would like to proffer the game cross platform. Does Free Pascal require anything special to compile software for multiple operating systems?
In speaking of starting small, I think the easiest way to start out would be to code a single character class (fighter comes to mind) a single monster type (kobold or orcs or something) and a basic randomized dungeon with a single type of treasure. Once this is stable other aspects can be added on a piecemeal basis.
Maybe I should solicit for previous experience: how did everyone here code their first-ever game?
If there's one thing I've learned from coaching football, it's that reinventing the wheel is a waste of time. I'm sure someone else here came up with something way more cooler than I'm likely to come up with to start.
-
It's not so hard. I picked programming up from scratch last September, and got a basic game out in January, in spite of having very little time to learn or do work on it. And I started from absolute scratch, inventing my own line-drawing algorithms and so on (because I was too dumb to read other peoples code).
Yeah, but you're smarter than I am, Darren. :)
I find that hard to believe ;) Honestly, I think if I can make a game then almost anyone can. Takes a bit of work and patience, but approaching it with the thought of "I could never do something that hard" will get you nowhere.
This is more great stuff. I was looking at Free Pascal earlier today and there seemed to be a lot of resources out there to support new learners. I noted there was something that Christian Knudsen of AsciiSector used called "SDL" that apparently makes the games easier to code as well. (But I haven't got a clue what that is.)
I would like to proffer the game cross platform. Does Free Pascal require anything special to compile software for multiple operating systems?
Free Pascal is pretty much 100% portable. There are certain libraries that only work on certain platforms, but they're generally clearly marked and are usually not the best ones to use in my experience. The Free Pascal Compiler is available on all systems and will compile any FP code on any system. I was actually shocked when my first release of Gruesome, developed only on a Windows platform, turned out to compile without any problems on Linux and Mac.
SDL just seems to be an interface library. Seems a little over the top for a roguelike project - ncurses works great for ASCII, and Pascal has its own extremely easy to use crt interface library (a bit slower than ncurses, but it's so incredibly simple to learn). If after you get used to these you want to expand into graphics or music then you can use SDL or the Valkyrie Library (created by the guy who wrote DoomRL and a few other awesome Pascal roguelikes).
In speaking of starting small, I think the easiest way to start out would be to code a single character class (fighter comes to mind) a single monster type (kobold or orcs or something) and a basic randomized dungeon with a single type of treasure. Once this is stable other aspects can be added on a piecemeal basis.
A most excellent thought. In general after you have a simple fighter wandering around killing simple monsters you'll have new ideas about where you want to go with your whole project, and it may lead to a complete redesign. Most developers build up in layers, adding further complexity and options as they go on, whilst also changing and improving what's already there. You learn a lot from each step, and each step after tends to become easier. It also helps to have simple playable versions as you go on so you can show them to others and get feedback - even the most basic of releases can teach you a lot.
-
Hi there! Haven't said anything yet, as I've been a bit too busy ;)
I'm a Computer Science student, so feel free to ask any programming related questions in the Development forum and I'll try to answer them. I did program in Pascal 3 or 4 years ago, but have completely forgotten the syntax. However, you'll find that most programming languages will have the same capabilities / control structures (functions, ifs, loops). If you pose the questions at that level of abstraction, we could go from there :)
Regarding SDL, it's simply a graphical library. This means that with it you can call functions that will, for example, open up a window, load images from disk, and draw them on screen. You will find libraries for all kinds of things, like (specialized) math functions, game development, network communication, and all sorts of stuff. Libraries are a way to abstract and modularize code, much like the engine idea you mentioned :)
Ncurses/crt might be a better choice. Instead of drawing images, it simply gives you the ability to write characters to a matrix (just like mathematical matrices) on-screen. So if you want the player to be at position (2,4), you can tell it to put character '@' at that position :) That's it, plus a few other things. I recommend this, since graphic libraries have a tendency to involve a lot of error handling, which is bothersome and ugly.
Although some will argue that object-orientation is bad for learning programming, I now believe otherwise. It is a great abstraction! You can think of everything you do in terms of real-life objects! I think it might be easier to get into programming that way. Want a player? Program a Player class that contains everything that a player has, and offer functions for everything that a player can do! Want an object? Program an Object class... want some objects to be wieldable (and inflict damage), but retain stuff that is still valid from Object (such as weight, shape, etc?), then say that class Wieldable is the same as Object, but "specialized", by adding damage, type of damage, etc. That's basically inheritance for you.
If you have some time on your hands and are enthusiastic about it, I would recommend learning programming. It can be a wonderful thing to finally get something working. You will feel great about elegant solutions to problems, and perfect your logical reasoning ability. Plus, like it's been said, it's a marketable skill, and useful too.
Like others have said, keep it small for starters. I've never done roguelikes, but will happily give suggestions and follow your progress on this forum. Not that I have a lot of time on my hands, but there you go. I'm sure others will be willing to help too :)
Have a good stay!
-- edit --
Oops, a little big here. Sorry if I overextended myself, but let me just say that you will be very hard pressed indeed to find a programmer willing to "work for you". Most have projects of their own, or are too busy, and, like pointed out, while it can be satisfying, it is hard work. You'll find most programmers want to derive some fun from the other parts, or maybe it is the conjunction of both work and design coming to life that makes them 'tick'. That's my case ;) I enjoy programming, but not enough to do it "just because", and I don't particularly enjoy simply designing things. I need to think them up, and do them myself, see them growing piece by piece :)
-
CoachWade: I have a suggestion you might like, check your email :)
-Ido.
-
Hi folks!
I haven't had a lot of time to respond. I'm preparing for a coaching presentation I'm giving this weekend in Texas, but I appreciate the advice and responses to my ideas.
Ido, I got your email and I like your idea. I'll get back to you more, later on. (I'd do it now, but my school has Hotmail locked out for all staff members as well as all students. Grrr!)
Thanks everyone. Have a great weekend and I'll be back to pester you with more questions on Monday.
~D.
-
Seeing as the 7drl challenge starts in 2 days, let's do it after it's over, ok?
-
Seeing as the 7drl challenge starts in 2 days, let's do it after it's over, ok?
Roger that. Have fun and good luck!
~D.
-
Oh, come on, you guys are gonna keep that a secret from us? Scallywaggery, is what I say! :D
You should try some other email providers and maybe change gradually. Are there any that aren't forbidden?
-
There are no secrets between the roguelike cultists! :P
-
I would be happy to help with answering questions or even writing some small parts of code if you have some specific troubles. But I could not spend time to write whole thing as I already have a project and, am also chasing a problem in my 7DRL release. :) Unfortunately I am not familiar with Pascal, but a few other languages.
I think another person already has mentioned that "libtcod" is very good portable library for drawing on screen and handling map. I am using it in my own project.
-
I'm writing my own Roguelike in Delphi (which is basically Object Pascal), and I've coded professionally in Pascal for nigh-on a decade, so I'd be happy to help out with any Pascal queries you've got.
-
I'm writing my own Roguelike in Delphi (which is basically Object Pascal), and I've coded professionally in Pascal for nigh-on a decade, so I'd be happy to help out with any Pascal queries you've got.
Tad to the side, but, since you mention Delphi....
Might ye be interested in reviving a Roguelike that also went down this path?
-
I can certainly help out, but Kharne is my main project. What did you have in mind?
-
Oh, I just meant in general since it would share the rare Delphi slant.
Let me dig around in my bag of tricks here....
http://www.graveyard.roguelikedevelopment.org/index.php?w1=1&w2=1&gra=5&dzial=zombies&dzial=zombies&gra=5&
Here we go, StarRogue.
-
Alright, I've downloaded it, will take a looksie later at it. I'm in the middle of writing an energy/speed subsystem atm for Kharne and its not pretty...
-
I'd like to have multiple stories in my RL. Yes, uncommon. I was inspired by the heavy story-telling of Legerdemain, and wanted to a story-centric RL for a long time. So if you'd like to see one of your stories come alive in a RL, give me a call :)
My RL on Roguebasin: http://roguebasin.roguelikedevelopment.org/index.php?title=Torchlit