Thornwind

[Sirridan]

Well after years of off and on work in various languages (Mostly QBASIC), I'm finally starting on a roguelike engine I call Thornwind.

Current plans are to get a basic game engine with no story to work, and then to build something I have planned (more of a reversal, you start at the bottom and work up to town... being evil and all .

I'm quickly learning C, many of the bugs I had initially were due to code positioning and the way includes are set up. That was fun, but hey I have something built and running, a little '@' moves around on a window (although it's trail doesn't erase yet...)

A lot of thanks go to the Angband maintainers and writers because that code has helped me a lot in both setting up windows, and with the 'term' idea to make an abstraction between the system dependent and independent code.

Also having taken some software engineering courses for my degree will help I think.

In any case, I'm making this post as an announcement, and as a way to encourage myself, so I don't just give up. If I do start to give up or slack, I'll know people will get ticked at me and I'll keep going.

Also, if I use part of Angband's code, or just base some of mine off of it, how would I make note of that, and how would licenses work? I don't want to rip code off and not credit properly...

Thanks!

EDIT: If you couldn't tell, the project name is currently Thornwind, heh. Surname from one of my D&D characters.

[Pete Mack]

Angband is not the best model for starting from the ground up -- the Term level abstraction is barely good enough to get by. (If you want to do things like tiles at one scale and text at another, it's a lousy model indeed--you need to start with the "canvas" and "panel" model, then build things like the term (text or tile panel) on top of that.)

If you want to base your game on Angband-like modeling, you should probably borrow the code from angband. (Some folks have already been doing C++ porting, which is better than C for non-realtime games; java or C# is better still.)

[PaulBlay]

(Some folks have already been doing C++ porting, which is better than C for non-realtime games; java or C# is better still.)

Yeah, but don't use JBand because I suck.

Zaiband is the only *band variant I know of that is in C++. I would be interested to know if there are others.

[Sirridan]

Well I may re-start in C# since it really is so much easier, and OOP can really do some nice things. My only problem is its pretty much windows only... although I suppose if someone really wanted to play it on linux there is Wine, and bootcamp for OSX.

[takkaria]

Well I may re-start in C# since it really is so much easier, and OOP can really do some nice things. My only problem is its pretty much windows only... although I suppose if someone really wanted to play it on linux there is Wine, and bootcamp for OSX.

It's not Windows-only, there's a pretty fully functional C# compiler called Mono which works on Linux...

[Sirridan]

It's not Windows-only, there's a pretty fully functional C# compiler called Mono which works on Linux...

Shows how much I pay attention... looks like its settled then, C# it is! I use it at work too so yay, this should work well!

Thanks for the replies, wish me luck!

[CloneDeath]

C# is great on some levels, but it is my least favorite language due to some design decisions Microsoft made. I will save my rants for another day.

Anyhow, for the trailing, when I made my first roguelike game, I did what he refered to as layering. First I drew the map, then I drew the character, and made sure not to place the @ into the array/string.

I would recomend C++, if nothing more than for the use of Vectors (array wrapper), Strings (another array wrapper), and Namespaces(more elegant aproaches than putting prefixed on all your functions, avoids function name clashes :P) (iostream is a NO. Again, that rant is for another day~).


Right now I am designing a rougelikelike (as I like to call it) for the Wii, and me and the room mate decided to go with C++ (using classes) and we are just streamlining through development and doing better than if we had picked C.

Just, I would strongly advise AGAINST C#.

[Sirridan]

Well I'm taking a quick break from work (writing a windows service in c# for a UDP port listener) and I really do like C#. Originally I was going to use c++, then moved to c. Unless there is a really good reason not to use it, I think I'll continue with it.

Then again, c++ is really portable.. *sigh* decisions decisions.

[Pete Mack]

Well I'm taking a quick break from work (writing a windows service in c# for a UDP port listener) and I really do like C#. Originally I was going to use c++, then moved to c. Unless there is a really good reason not to use it, I think I'll continue with it.

Then again, c++ is really portable.. *sigh* decisions decisions.

If you are doing UI, java is more portable than any of the above. The gfx library is (nearly) uniform across all platforms.

[Sirridan]

If you are doing UI, java is more portable than any of the above. The gfx library is (nearly) uniform across all platforms.

True, and I'm quite experienced with java, but I'm not too fond of it.

[Pete Mack]

I like java well enough, except for the strange reluctance to support operator overloading. (C# is much better in this regard.)

On further thought, C++ is probably the way to go.
It has:
- A portable model for the canvas (OpenGL)
- A portable model for text rendering (GLTT)
- An adequate object model

What is missing from this lst is a nice portable lightweight UI (paneling) system, and a portable I/O model. Yes, there's gtk and Qt, but I did say lightweight. (The thing is 80MB to install on OSX; Qt is even bigger! I didn't bother.)

I did find
- a Fast Light Toolkit, which looks very promising. (I downloaded it; it's extremely lean.)

via some linker sites:

http://www.ohloh.net/tags/toolkit/ui

http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

[PaulBlay]

I did find
- a Fast Light Toolkit, which looks very promising. (I downloaded it; it's extremely lean.)

FLTK was the most promising of the libraries I played with (from my point of view). I liked the FLUID tool.

I did a quick RogueBasin page for it and review.

(I suspect the minor problems I had with compiling in VC++ have now been resolved).

[Pete Mack]

I wrote exactly one UI widget for Angband--the menu, implemented as the only subclass of Panel. (I also wrote a simple UI event system.) After that I realized that it was a losing battle--I'd do better not to reinvent any more wheels. But it was an useful learning experience, and I did a pretty good job for ~1000 lines of code.

If nothing else, it gave me an idea of what to look for in a toolkit. (The answer is definitely not SDL, GTK or Qt.)

[Sirridan]

I'm still really looking at C#. Sure, C++ has the libraries and such, but I'm sure they could be written for C# or be ported over.

In any case, I'm writing this to keep the display/input seperate from the core game processing. If all goes to plan, you should be able to use any display engine you want and not have to change a bit of code for the main game.

I believe I will continue with C#, and if the project begins to look promising, and if there is enough interest, on completion I'll port to C++ which will make for a good learning experience.

EDIT: Thanks for all your replies and inputs guys, I think it's time I started working, the paladin I was working on got obliterated as I was making my way to a greater vault to nab the junk inside (I was just going to port away as much as possible, then _*DEST* everything else. But I teleported myself, and got breathed on by a greater basilisk. Qué sera', sera'.