Print

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

[Minstrel]

Seconding Kyzrati.

[Aqizzar]

Try a smaller project with your newfound tech!

This is the right thing to do.  I've got a much smaller, tightly focused idea in mind for a pilot project, and Lunkheads will be on-and-off hold until I'm tired of it.  I actually do have the long term sort of goal of making a commercial game built on my ideas from Lunkheads, but there's no harm in going to another project to test out an idea before committing to rewriting my existing game.

So uh... I'm making a scrolling shoot'em'up.  Y'know like Gradius, Raptor, 1942, Stargunner, Space Invaders, Steel Empire, et al.  With customizable player craft, and semi-random maps and enemies.  And ASCII graphics.  Which I suppose qualifies this for a 7DRL project, but I can't imagine what I can build to a playable state within seven days, so I'm not really committed to the timeline.


I'm starting with what seems to me both an obvious idea and a radical concept.  Basically, there will be a separate processing thread for the rendering, for taking user input, for keeping the user interface up to date, for the application of "physics" to game objects, and then a unique thread for every currently 'living' object in the game, and all of their graphic effects.  For my scrolling-shooter idea, that means enemies and such spawn when the map loads, and sit in a 'waiting' loop until the player gets close enough to activate them, they perform whatever functions they need to including spawning 'shots' that have their own threads, then dispose of themselves once they go off the screen again.

You want multithreading?  I got your multithreading right here.  I have absolutely no idea if this is the right or wrong way to use threading, but that's what I'm gonna try.

[Kyzrati]

A couple months back I made a little prototype of an ASCII shmup, since I figured it could look pretty cool combined with my particle engine. Didn't work, because I'm pretty bad at programming anything realtime. In any case, I did some research at the time and you'll probably be interested in checking out these links:
Chaos Stream
Vax 11
ALTCODE
Maybe you've heard of some of these before?

I think there is a *lot* of room for exploration in this area, which is why I tried a prototype in the first place. Couldn't get the physics working right, though. Tough to do a shmup on a discrete grid and have all the particles flow properly, at least with the generic approach I tried using my existing particle engine. Not sure how Chaos Stream does such an awesome job (I couldn't find a good way to add things like "static continuous lasers" without hard-coding the behavior).

[RiordanIX]

That sounds pretty wild, ASCII for a scrolling shooter.

Also, I was wondering if you had the falling calculation in Lunkheads as a quadratic function, or just linear?

[Aqizzar]

Also, I was wondering if you had the falling calculation in Lunkheads as a quadratic function, or just linear?

I do it with kinematic functions, which I believe counts as quadratic.  I'm pretty balls with trigonometry, so I just copied equations off the Internet.

Tough to do a shmup on a discrete grid and have all the particles flow properly, at least with the generic approach I tried using my existing particle engine. Not sure how Chaos Stream does such an awesome job (I couldn't find a good way to add things like "static continuous lasers" without hard-coding the behavior).

Never heard of any of those, thanks for the links.  The only real-time shooter like this I was aware of is ASCII Sector, a marvelous little game.  And of course ZZT, which is nothing short of astounding for its age.

I can already see a lot of potential holes, with things like continuous actions and especially continuous user input.  As for the "discrete grid" thing, I plan to store all object locations as decimals instead of integers (double doubles, if you will) and then render them wherever they best fit.  This might produce some stuttering on occasion, but I don't think that's a big problem aside from sanity checking to keep multi-tile objects from being split up.

The other big problem I see is performance.  I made a test program that just sends text strings to a buffering list, while the main program loop constantly prints the buffer clear.  I wanted to test that threads don't step on each other; with a whole bunch of objects constantly updating their position, the buffering thread has to have a clear picture to print, not to mention just making sure an array it's scanning doesn't change halfway through.

I set this up by making some global flags like MasterGameLoop, AllowRendering, AllowChanges, and so forth, so the rendering thread can block map changes while the map changes can block rendering.  Every thread is set to run on a short loop (a few milliseconds), ticking down a "total wait" loop until time to act, but not ticking down the total while the action is supposed to be blocked (this is so if the game is paused for instance, the threads don't keep waiting and then all immediately kick in at once when the game is unpaused).  And under this architecture with just four threads, I've noticed a significant performance difference between 1 millisecond and 10 for the "am I supposed to act yet" loop.  I may not be using the most efficient timer loops.

[Skyrunner]

Proper Coding warning:

 You should totally use semaphores!

End PC warning.

[MaximumZero]

Proper Coding warning:

 You should totally use semaphores!

End PC warning.

I don't see what flag waving has to do with it.

[Skyrunner]

I personally try to avoid semaphores or mutexes. :I Too much work.

Flag waving because I don't personally endorse the proper answer.

[Aqizzar]

That might as far as this one's gonna go.  The threading works amazingly well, it's the foundation that put me in a rut.

The problem I've discovered is that Libtcod, the front-end library I use to put stuff on the screen and read input, sucks balls.  I already knew this of course, I've been banging my head against a wall trying to get this library to cooperate for over two years now, and I've finally found an application I just don't know how to adapt it to.  That being continuous realtime.  The issue (anyone who knows anything about Libtcod feel free to correct me) is that the library instantiates the window that the game is supposed to play though, but the window only responds to functions called through the main program loop, as far as I can tell.  What this means in near-layman terms is that the player's input and the graphical rendering have to take place in the same thread/loop, which highlight's Libtcod's many flaws.

The stupid thing is I know this library is capable of functioning this way, because the demonstration app that comes with the download shows off the graphical options while accepting input on the fly.  Damned if I know how though.  There's some other experiments I can try, and in the case of that screenshot, the shitty-looking effects you see are probably my doing somehow.

However, the real question here is whether I actually want to.  Do I continue to ride this wobbly, painful, virtually-undocumented crutch as far as it can take me?  Or do I knuckle under and teach myself XAML or WPF or some shit like I keep threatening to and just do the graphical frontend myself?  Or do I admit defeat for the time being and go back to boilerplate backend code until I grow tired again of making a roguelike?

I'm really posting this because I'm kinda stumped.  Windows Forms and whatnot confuse the Hell out of me, and I literally know of no other way to render graphics in a window.  Anyone who knows anything about making shit appear on the screen, feel free to mention any presentation tutorials that you got some use out of.  Meanwhile I'm gonna dive into the unknown again and see if these C# books are bought are worth the trees they're printed on.

[Kyzrati]

The issue doesn't have anything to do with libtcod. There are plenty of real-time games that use it, including many open source ones (some by the dev himself) that you can explore to see how it's done. As an example see "Pyromancer!", a fast-paced real-time game with dynamic lighting (download comes with src).

I think you just haven't quite grasped the standard game loop yet, since it doesn't take multi-threading to do a real-time game. If it did how did we have real-time games before multi-threading even existed? The point is, switching to another library won't solve the fundamental problem.

I'm not a great authority on the subject because I only develop turn-based games, but you just check for input each cycle and then render object as/where they appear. You can skip each step as necessary. For example: No input? Just don't make any changes. Overloading the CPU? Only render frames every X seconds or up to a certain FPS. I highly suggest taking a look at the existing libtcod games that do this (I'm sure more open source games can be found in the games section of the site, some probably simpler than Pyromancer).

[kaijyuu]

In my experience, programming is accomplished by slamming your face against the keyboard until it works the way you want it to.


Anyway, if you're considering other "beginner's" methods of making games, you might want to check out pygame or game maker. Doubt you know the programming languages they use, but they're not hard to learn, especially if you understand a programming language already.

[Skyrunner]

Libtcod definitely can make realtime games.

However, I recommend taking a look at TCODEngine.h/cpp and Engine_tcod.h/cpp here. I gotthe original code from Gatleos, but it exhibits a standard game loop using SDL for key input instead of libtcod's nonstandard input. Basically the Update function is fired every z seconds, depending on the set framerate. The KeyDown/Mouse etc functions are called each time a key even happens, I think. As long as the physics engine doesn't take too long to complete, it should run in real time. In that example I didn't make it real time, but it shouldn't be too hard.

Like Kyu said, you need to store a representation of the (n-1) step, run the physics engine, and handle input before doing the nth step and writing that to the buffer.

[Aqizzar]

I think you just haven't quite grasped the standard game loop yet, since it doesn't take multi-threading to do a real-time game. If it did how did we have real-time games before multi-threading even existed?

How should I know, do I look like I know what I'm doing?

I'm not a great authority on the subject because I only develop turn-based games, but you just check for input each cycle and then render object as/where they appear. You can skip each step as necessary. For example: No input? Just don't make any changes.

That's the real trouble I'm having, accepting input without A) locking up the program to wait for it, or B) accepting one keypress without registering a thousand a cycle.  That's the whole reason I started looking at threading, because I figured the only way to accomplish that was by having the input and the rest of the program on separate processing channels.  If there's another way to do that, especially with a console, I've never heard of or seen it, even though it clearly exists.

I guess part of the problem is that I've been doing this long enough that I've reached that grognardy stage where I feel like anything that does a job for me is an insult to my intelligence, when I clearly need the help.  Another part of the problem is that real-time input-output programming isn't really found in many applications except videogames, and as anyone who's tried to teach themselves game programming knows, that has a profound impact on the number and quality of tutorials/examples readily available.

Well, back to the drawing board.

[Skyrunner]

What about my post? D:

[Kyzrati]

You really need to read this. It's an incredibly popular article that many many game devs read at some point in their career. I know I read it! There's nothing fundamentally different between a console/grid-based game than with any other type of non-discreet positioning system. (The "console" nature just affects where you render things, i.e. at the closest position that can be displayed.)