Chaosforge Forum

  • March 29, 2024, 07:31
  • Welcome, Guest
Please login or register.



Login with username, password and session length
Pages: 1 2 [3] 4  All

Author Topic: General Progress Tracking -- Revisited  (Read 20918 times)

STL

  • Private FC
  • *
  • Offline Offline
  • Posts: 18
    • View Profile
General Progress Tracking -- Revisited
« Reply #30 on: September 22, 2006, 04:35 »

Quoting: Kornel Kisielewicz
Paradoxicaly 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 Kisielewicz
believe 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.
Logged

Kornel Kisielewicz

  • God Hand
  • Apostle
  • *
  • *
  • Offline Offline
  • Posts: 4562
    • View Profile
    • http://chaosforge.org/
General Progress Tracking -- Revisited
« Reply #31 on: September 22, 2006, 17:50 »

Quoting: STL
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.

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".
Logged
at your service,
Kornel Kisielewicz

Santiago Zapata

  • Temple Guardian
  • Backer
  • First Lieutenant
  • *
  • *
  • Offline Offline
  • Posts: 236
  • Roguelike Developer
    • View Profile
    • Slashie.net
General Progress Tracking -- Revisited
« Reply #32 on: September 22, 2006, 18:30 »

Quoting: Kornel Kisielewicz
is a real pain for a roguelike design

Unless he is developing a roguelike, it may be hard to understand ;)

Quoting: Kornel Kisielewicz
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".


That's very nice to read ;)
Logged
Slash (Castlevania, Metroid, Drash, ZeldaRL)
Temple of The Roguelike
Slashie.net

STL

  • Private FC
  • *
  • Offline Offline
  • Posts: 18
    • View Profile
General Progress Tracking -- Revisited
« Reply #33 on: September 23, 2006, 08:31 »

Quoting: Kornel Kisielewicz
is 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 Zapata
Unless 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.
Logged

Anticheese

  • Lieutenant Colonel
  • *
  • Offline Offline
  • Posts: 483
    • View Profile
General Progress Tracking -- Revisited
« Reply #34 on: September 23, 2006, 10:57 »

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 Zapata
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".


That's very nice to read ;)


Agreed
Logged

Santiago Zapata

  • Temple Guardian
  • Backer
  • First Lieutenant
  • *
  • *
  • Offline Offline
  • Posts: 236
  • Roguelike Developer
    • View Profile
    • Slashie.net
General Progress Tracking -- Revisited
« Reply #35 on: September 23, 2006, 16:34 »

Quoting: STL
That problem gets real interesting real quick.

That's an area I want to tackle, last real time game I created was about 4 years ago in QBasic, single player.

Quoting: STL
If anyone needs to discuss something about computers, you know where to find me.


Where?
Logged
Slash (Castlevania, Metroid, Drash, ZeldaRL)
Temple of The Roguelike
Slashie.net

STL

  • Private FC
  • *
  • Offline Offline
  • Posts: 18
    • View Profile
General Progress Tracking -- Revisited
« Reply #36 on: September 23, 2006, 23:27 »

Quoting: 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.

Why do you assume there are only 2 paddles? What about 4, on each side of a square, or, 6, cubic version with 3D graphics, or just 2 sides with more than one paddle (of different colors to "parry" different colored balls) each. IMHO, every paddle should have only one controller. The possibilities are endless, although some of them are lacking feasibility. Also I wouldn't say MMOPong, something feasible with pong in Massive Multiplayer Online genre, IMO, would not look like Pong anymore.

Quoting: Santiago Zapata
Where?

I was meaning here. I check this forum at least 5 times a week, any discussions can go on in off-topic forum, so everyone can contribute. I'd say that is the best way.

I'd suggest C#, VB#, J# or Java for any kind of game, especially if it's multiplayer. I'd go with C++, C or Pascal for games that really need to squeeze resources out of the computer.
Logged

Kornel Kisielewicz

  • God Hand
  • Apostle
  • *
  • *
  • Offline Offline
  • Posts: 4562
    • View Profile
    • http://chaosforge.org/
General Progress Tracking -- Revisited
« Reply #37 on: September 24, 2006, 16:56 »

I'd suggest C#, VB# if you want to annoy the hell out of Linux people, and put your 0,02 M$ into the monopoly :)
Logged
at your service,
Kornel Kisielewicz

STL

  • Private FC
  • *
  • Offline Offline
  • Posts: 18
    • View Profile
General Progress Tracking -- Revisited
« Reply #38 on: September 24, 2006, 20:55 »

Quoting: Kornel Kisielewicz
I'd suggest C#, VB# if you want to annoy the hell out of Linux people, and put your 0,02 M$ into the monopoly :)

 1- They are free. See Visual Studio 2005 Express Edition.
 2- Linux is not for gaming :). Also I believe there are some C# and VB# compilers for Linux around, but I might be wrong.

If you want 95% platform independency, go with Java. Java is flexible, almost completely platform independent, and very slow.

If you want to run your game on multiple platforms, IMO, the most efficient way of doing it it using C++ or C. You should split your game into two parts: Game and Platform. Game should only be data structures, algorithms etc for your game. Platform should be the part where you interact with OS (graphics, sound, file system etc.). Why C/C++? Because every platform (Windows, Linux, MacOs, Solaris etc.) has a compiler for them.
Logged

Santiago Zapata

  • Temple Guardian
  • Backer
  • First Lieutenant
  • *
  • *
  • Offline Offline
  • Posts: 236
  • Roguelike Developer
    • View Profile
    • Slashie.net
General Progress Tracking -- Revisited
« Reply #39 on: September 25, 2006, 17:23 »

Quoting: STL
If you want 95% platform independency, go with Java

Yeah, abandon FreePascal and go with Java! ;)

Quoting: STL
2- Linux is not for gaming :).

Woot!?

Quoting: STL
You should split your game into two parts: Game and Platform. Game should only be data structures, algorithms etc for your game. Platform should be the part where you interact with OS (graphics, sound, file system etc.)


I am sure Kornel knows about this ;)

Actually I myself split the game into four parts: Game, Engine, User Interface and System interface. The Game-Engine splitting, as known by anybody who's got into RL development, is the one that make your head hurt and I now think should be avoided. I wrote a small text about it sometime ago, you all can find it at http://peltkore.net/~szdev/ga/eng/docs/layers.htm
Logged
Slash (Castlevania, Metroid, Drash, ZeldaRL)
Temple of The Roguelike
Slashie.net

STL

  • Private FC
  • *
  • Offline Offline
  • Posts: 18
    • View Profile
General Progress Tracking -- Revisited
« Reply #40 on: September 26, 2006, 07:00 »

Quoting: Santiago Zapata
Yeah, abandon FreePascal and go with Java! ;)

I'm hoping you are not suggesting pascal (or *pascal* ) is platform independent.

Your article can be a good start for beginners. But I didn't understand why would you place UI in a seperate bin. It's rather an interesting idea to split Game from UI, why would you change Game or UI independent from each other?

And again, I'm not saying what Kornel knows/doesn't know/can do/cannot do/whatever. Whether anyone realizes or not, there are people in this forum who want to get started on doing something on their own, I'm merely trying to help them.
Logged

Kornel Kisielewicz

  • God Hand
  • Apostle
  • *
  • *
  • Offline Offline
  • Posts: 4562
    • View Profile
    • http://chaosforge.org/
General Progress Tracking -- Revisited
« Reply #41 on: September 26, 2006, 15:04 »

Quoting: STL
I'm hoping you are not suggesting pascal (or *pascal* ) is platform independent.


That's the whole point : you obviously have some proper education in the IT field, but don't now all the nuisances yet. DoomRL is written in FreePascal ( http://www.freepascal.org/ ) and FreePascal IS highly portable. The number of supported platforms is great, and the portability of FreePascal code is a lot greater then C/C++ code.
Logged
at your service,
Kornel Kisielewicz

Santiago Zapata

  • Temple Guardian
  • Backer
  • First Lieutenant
  • *
  • *
  • Offline Offline
  • Posts: 236
  • Roguelike Developer
    • View Profile
    • Slashie.net
General Progress Tracking -- Revisited
« Reply #42 on: September 26, 2006, 15:48 »

Quoting: STL
But I didn't understand why would you place UI in a seperate bin. It's rather an interesting idea to split Game from UI, why would you change Game or UI independent from each other?


Well, more than separate bins, I am talking about separate modules on the same bin, if your implementation language allows that...

The idea of Game and UI being independant is to allow replacement of these modules via definted "interfaces" so that only one Game has to be mantained but several representations can be provided

Quoting: STL
I'm merely trying to help them.


Ok ;)
Logged
Slash (Castlevania, Metroid, Drash, ZeldaRL)
Temple of The Roguelike
Slashie.net

STL

  • Private FC
  • *
  • Offline Offline
  • Posts: 18
    • View Profile
General Progress Tracking -- Revisited
« Reply #43 on: September 28, 2006, 04:37 »

Quoting: Kornel Kisielewicz
FreePascal IS highly portable. The number of supported platforms is great, and the portability of FreePascal code is a lot greater then C/C++ code

Ok, let me explain:
Portable : You implement your program, build and run it on a single platform. You bring your source code to other platform, fix it for platform differences, build and compile it. Repeat for each and every possible platform you need to support.
Platform Independent: You implement your program, and you are done.

So, portability is not platform independency. Since no one, including the developers of these games, expects this games to work on every platform, it's not a big issue. But everyone wants to support main platforms. Just for the sake of argument, if you used a platform independent language such as Java, there would not be a Linux version, there would be only one version that works both on Windows and Linux (and MacOs, and Solaris, and... well you get the idea).

I've checked out the FreePascal site, and in the main page, they say that they are supporting 9 OS and 4 processors. FYI: C/C++ is supported virtualy on every OS and processor.

Quoting: Santiago Zapata
The idea of Game and UI being independant is to allow replacement of these modules via definted "interfaces" so that only one Game has to be mantained but several representations can be provided

Ok, It's just you are considering Game = Logic of the game (internal objects data structures etc), UI = (UI interactions of the user that is based on the logic, which makes the real gameplay experience).
Logged

Kornel Kisielewicz

  • God Hand
  • Apostle
  • *
  • *
  • Offline Offline
  • Posts: 4562
    • View Profile
    • http://chaosforge.org/
General Progress Tracking -- Revisited
« Reply #44 on: September 28, 2006, 04:39 »

Quoting: STL
I've checked out the FreePascal site, and in the main page, they say that they are supporting 9 OS and 4 processors. FYI: C/C++ is supported virtualy on every OS and processor.

Tell me at least one that is not listed there, that I should care about ;].
Logged
at your service,
Kornel Kisielewicz
Pages: 1 2 [3] 4  All