DRL > Requests For Features
General Progress Tracking -- Revisited
STL:
Quoting: Kornel KisielewiczParadoxicaly this *IS* the best approach
Not really. In fact, the truth of the sentence depends on the meaning of "best". In true OOP fashion, The terrain should be an object, with every feature (I mean square, character, or whatever you call them) being an object inside that. I'm not saying the array would not be there, but it will not be exposed. This approach allows terrain to "behave" pretty easily, i.e. traps. This approach allows you to centralize the terrain related logic, so that tomorrow you can have non-squared terrain with minimum change in your code (not that you should, but you could). Always leave room for expansion.
Quoting: Kornel Kisielewiczbelieve me, I know what I'm doing
I didn't want to imply that you do not know what you are doing, I'm just trying to make what you are doing better, so that you can be better, so that you can really achieve something great(er) in the future. I like the fact that all by yourself you are achieving something that is loved by many people. Which makes me believe you have a great potential.
Kornel Kisielewicz:
Quoting: STLIn true OOP fashion, The terrain should be an object, with every feature (I mean square, character, or whatever you call them) being an object inside that.
And that despite being correct OOP wise, is a real pain for a roguelike design :/. Not to mention memory consumption and processing speed.
I use a more complex system for GenRogue and Carceri (more OOP definitively). But DoomRL is intended to have it's limits. After I release the graphical 1.0.0, maybe make an extended 1.1 version, and maybe add a campaign editor and ladder, DoomRL will be considered "finished".
Santiago Zapata:
Quoting: Kornel Kisielewiczis a real pain for a roguelike design
Unless he is developing a roguelike, it may be hard to understand ;)
Quoting: Kornel KisielewiczAfter I release the graphical 1.0.0, maybe make an extended 1.1 version, and maybe add a campaign editor and ladder, DoomRL will be considered "finished".
That's very nice to read ;)
STL:
Quoting: Kornel Kisielewiczis a real pain for a roguelike design :/.
That, I don't argue, definitely it will require time spent on it. But "best" is not often same as easy. That was my point. Also, something that looks as easy, can easily turn out to be taking more of your time in the end. That's why, I always prefer flexibility & robustness over easy. But yet, every artist has their own brush.
And just for the note: since the topic is on roguelike, it's very very hard to make something (sensible) that has problems with memory consumption or processing speed. Given any time, you can have at most 1600 items to work with. 1 kb each, and rest of your code etc, you have 2 MB memory consumption. Processing is not a big deal, since it's turn based.
Quoting: Santiago ZapataUnless he is developing a roguelike, it may be hard to understand ;)
I am. Sort of. If you like pain, try a simple (pong?) realtime (as opposed to turn based) multiplayer game with more than two players playing at the same time. That problem gets real interesting real quick.
Anyway, If anyone needs to discuss something about computers, you know where to find me. I'll silently wait for next DoomRL version.
Anticheese:
The problem with MMOPong is that you have conflicts of commands coming in on both sides and without any communication between teams you are just going to be stuck without a moving paddle, The best solution would be to have a visible queue of people and give each person 10 seconds.
Quoting: Santiago ZapataAfter I release the graphical 1.0.0, maybe make an extended 1.1 version, and maybe add a campaign editor and ladder, DoomRL will be considered "finished".
That's very nice to read ;)
Agreed
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version