Bay 12 Games Forum

623 is one of the most difficult strings to pull off on a computer for anybody, apparently.

Sigh, I do not appear to be able to connect to hamachi from my university's network. I will see if there are any workarounds, but I guess otherwise this is a tearful goodbye T.T

If you have #include <iostream>, there's really no need to use C functions like printf or puts. Learn how to use streams (such as std::stringstream, which does the job of puts, and std::cout, which does the job of printf). Streams are also the basis of file-reading in C++. There's a tutorial on reading files here: http://www.cplusplus.com/doc/tutorial/files/

Also, don't use char* if you don't know better. Use std::string until you're more familiar with C, it'll save you a lot of unnecessary hassle.

@Angle:
The issue is that most programmers aren't going to trawl through your code out of the kindness of their hearts, and most other people don't know how to compile your engine or otherwise provide any sort of meaningful critique of it. That's why you haven't been getting any feedback on your engine. Either get a working demo up or start asking specific questions if you want more feedback.

http://www.mediafire.com/?if19p41b3rz42 <- The files you will need should all be in this folder. You will at least need jroguex.jar and terminal.png to run the demo; jrogue.zip contains the source code and vecmath.jar is a library that the source code needs to compile. I use Eclipse (jrogue.zip is just an exported project), so you'll need to get it if you want to compile the demo (all of the library functions should still be accessible though). Use WASD to move around the map (don't walk off of it; there's no collision detection, so you'll crash it). Notice the flashing "Hello World" overlay with transparent text and background (the transparency isn't very high, so you might have to look a little hard).

This is a rather simple, if outdated, demonstration of what the engine can do. I haven't touched this code in a few months, so I don't recall exactly where I left off, but a quick glance over my library reminds me that I need to add in additional functionality for moving overlays, work out a graphical glitch or two, and add functionality for printing strings, but other than that the graphics are pretty much done. It's all done "software" side so there should be few, if any, compatibility issues. I've recently learned OpenGL and a few other graphical tricks though, so there is room for improvement if necessary (I don't think it really is necessary, though).

Graphical tiles and unicode tiles work in theory, but I need to expand my tile loading code if I wanted to use those features (currently the tile loader can only handle the nice 16x16 tile format DF has). You should be able to swap out terminal.png for any of the tilesets on the DF wiki with minimal changes (rename the file to "terminal.png", and replace all the magenta with an actual alpha layer using GIMP or photoshop). I don't recall precisely how I colored tiles, so you'll have to figure out how tile color interacts with rendered color (I think I used multiplicative scaling, but I could be wrong. I'm too lazy to check right now).

Java Swing uses a different event-handling paradigm than most novice programmers are used to (i.e. event listeners, rather than event polling), and the design I currently have in mind is inherently multi-threaded (since the rendering is mostly software, I put it in its own thread, and the event-driven nature of Swing lends itself well to multi-threading, but not to single-threading). This increases the initial complexity a bit, but does carry its own benefits (such as enforcing cleaner code). However, the initial Map-Entity design I wrote is a bit clunky and outdated, and I'd need to rewrite it before actually using this library to make a game. Otherwise, the fundamentals should all be there.

Compared to other roguelike libraries out there, my library is a lot higher-level, and is more graphically-oriented (i.e. it doesn't emulate or recreate a console, it just draws a bunch of ASCII tiles like DF). Once I rewrite the Map-Entity system, it should be possible to implement most graphical effects without referencing the console window even once. It can also handle both step-based and real-time action, and even mix the two (this library was originally the foundation on which I was going to build a hybrid step/real-time rougelike), so there's a lot of flexibility in that regard.

EDIT: Oh right, no programming experience. Basically, once I work out how to properly do a map/component system, and build a GUI system (haha, that makes it sound so much easier than it is), it'll be like making a game in GameMaker, except even easier.

EDIT2: Oh, and I also need to write a state machine. I'm not sure I have one written up any more, so I'll have to make it from scratch.

References IIRC just have a stricter set of conditions than pointers, thus allowing you to make more assumptions about them. For example, a reference cannot change what it is pointing to (so it is similar to int * const in that regard), and it cannot be initialized with a NULL or uninitialized value (making it even more dependable than an int * const), so you can make the same assumptions with a reference as you can a normal variable (for the most part).

Perhaps a better system would be having a default template character which you apply perks/penalties to which award/detract various things (awards? achievements? points?) so you'd have interesting self-imposed challenges.

I actually have a little codebase on my (old) computer for a game like that (I wanted to make a roguelike, but I decided otherwise). My idea was for a "massively singleplayer game" (people use that buzzword enough, so I figure I could use it too). There was a game out a few months ago that had only singleplayer gameplay but allowed people to post comments in the form of a ghost message or something that would be viewable to all. A similar gameplay mechanic could be exploited in a large free-form exploration game like that by allowing people to scratch messages into floors or walls (nethack anyone?) that could either communicate a narrative or otherwise enrichen the exploration experience both by adding a shared discovery component (i.e. you can track the progress of others who came before you in a certain dungeon) and by adding a sort of 'first' discovery component (i.e. finding a pristine room or room nobody has written in before can be a very satisfying experience).

There would need to be some sort of dynamic content generation on a large scale in order for this first mechanic to succeed, IMO. This sort of limits the types of narrative you can put into the game, so there is a definite tradeoff. To offset the loss of narrative, I thought adding a high score component to the game would be an interesting way to improve replay value, where adventurers could search ever deeper into dungeons or jungles for more valuable and more powerful randomly generated loot (both functional and not). Although I do admit, my game idea lacked any sort of end or narrative direction (there was backstory, actually similar to your idea, except in a fantasy setting), finding artifacts that point towards what happened to civilization might be a good way to give a sense of completion for finishing the game.

Ah, I was unaware of the technical difference between a pointer and a reference, and I always assumed that passing a pointer by value was just called passing by reference in common practice (which is a rather widespread misconception, apparently).

^{Blame common usage and semantic drift!}