Doom RPG-like game and questions about it

Hi there,

I’m trying to make this kind of game, and I have a lot of questions.

  1. At first I thought of moving like this (yeah, I know that Q and E buttons not work the way they are supposed to)

    but I realized that I would have to match the step size to the scale of the map.

So here is test map


I think, that it is necessary to make a “grid” so that both the player and the enemies (and objects) move exactly at the given coordinates. But how to do it?

  1. I make a sprite sheet through the editor, loading 256x256 sprites into it. And in the scene this object looks like a very big one

    based on what this size is taken?

Hello there!

I must say I’m not 100% sure about the first statement. If you’re making Doom-like RPG (that is rather TES: Arena / Daggerfall :D) then you don’t need grid-based movement and let the player roam freely. You can just use TCastleWalkNavigation and it will do everything for you. Just use 3D FPS game template from Castle Editor and it’ll get you started.

If you want something more like Anvil of Dawn / Eye of the Beholder, with grid based movement, then you’ll need to control the input by yourself. Imho it’s much more convenient to do so through a custom navigation class that will take care of the movement between grid tiles. Maybe not the best example of the code, this is a very old project, but a working example can be found here EugeneLoza / Duungeeon · GitLab

1 Like

No, Doom RPG-like exactly, not Doom-like RPG, because Doom RPG - Wikipedia
But yes, you’re right with Eye of the Beholder, I know about it, but I never play this.

wow, excellent and suits me perfectly, but project does not compile, so I brought back Scene.Spatial := [ssRendering, ssDynamicCollisions] in WorldUnit instead Scene.PreciseCollisions := true.

Thanks very much for the tip, and I’ll be thinking about shooting and objects

1 Like

Ah, it could make sense to update Castle Game Engine for you, because PreciseCollisions was one of the few fixes I’ve had to make it to work with latest version - and it’s how it’ll be working in the future.

And yes, I didn’t know about Doom RPG. Makes perfect sense!

offtop: why you licensed under the GNU GPL? I think, MIT or BSD suits better

No specific reason. In complex projects I keep the idea of “viral license” that requires derivatives to be opensource too. CGE also uses LGPL license (with linking exception).

Duungeeon was planned to be a full and complete game, not just a small abandoned demo :slight_smile: But in its current state indeed a more permissive license would work better. Should I alter it? I don’t have anything against MIT if you may find reusing chunks of code useful :slight_smile: However, I’d rather encourage you to write those better - that code does what it is supposed to, but it’s not good. If I’ll return to the idea of making this kind of game (maybe next week? Unlikely but still) I’ll be rewriting a lot of stuff from the scratch, just copying ideas, not actual code.

@sthox

  1. Although @eugeneloza already provided an exhaustive answer and complete example, I also wanted to take a stab at this, as I love “Eye of the Beholder” :slight_smile:

    So I added a cool new example to Castle Game Engine: examples/eye_of_beholder ( castle-engine/examples/eye_of_beholder at master · castle-engine/castle-engine · GitHub ).

    It shows how to do “Eye of the Beholder” navigation using the simplest code.

    Can you guess which one is the original “Eye of the Beholder” game? :slight_smile:


  1. If you don’t have PreciseCollisions defined, then indeed the first thing you should do is update – take latest CGE from Download | Castle Game Engine .

  2. As for camera movement: to be clear (as I don’t know Doom RPG), you want camera like in “Eye of Beholder” or @eugeneloza 's Dungeeon? So

    • view from first person
    • movement by 1 grid tile back / forward
    • rotation by 90 degrees

    To do such movement in an “instant” way, your code is along the lines I would do. Just change MainViewport.Camera.Translation or MainViewport.Camera.Rotation in response to key.

    If you want to move/rotate smoothly (not instantly), using TCastleCamera.AnimateTo is the simplest option. My example examples/eye_of_beholder shows this.

  3. As for the sprite sheet size: the size just follows the sprite sheet frame size in pixels. It makes sense in 2D games, it is indeed unnaturally large for typical 3D games – simply scale it down, i.e. set Scale to something like 0.01 0.01 0.01 (scale 100x smaller in all 3 dimensions).

2 Likes

I attach the “Eye of the Beholder” CGE demo as a separate zip download here, to get it easily. But in a few hours it should also be available in snapshot on Download | Castle Game Engine .

eye_of_beholder-0.1-src.zip (10.9 MB)

2 Likes

Two questions more - how I can make a weapon sprite in the viewport?


And I created a crosshair, how to make it illuminate in a different color when pointing at something, and that enemies die when you press the left button and if the sight is pointed at them?

Attach a TCastleScene with a sprite sheet of your weapon as a child of the camera. See pointers from Camera | Manual | Castle Game Engine . So place a weapon just as we do in examples/fps_game, however in your case the weapon will be just a sprite sheet, properly scaled and rotated.

There are other ways of doing this (e.g. additional TCastleViewport with Transparent = true, only to display the weapon), but for start I would recommend the simplest approach above.

See “3D FPS game” template for an example how to shoot at enemies.

To change the crosshair color when your cursor is over an enemy, you would implement in Update method of your view (see Designing user interface and handling events (press, update) within the view | Manual | Castle Game Engine about views and their methods) a check “does the current MainViewport.TransformUnderMouse indicate an enemy” and based on this, you can change crosshair color.