Quantcast
Channel: Planet Object Pascal
Viewing all articles
Browse latest Browse all 1725

Castle Game Engine news: Reshared post from Michalis Kamburelis:

$
0
0
New game done using our engine :)

Original Post from Michalis Kamburelis:

I'm presenting a small game called "Hotel 'Nuclear'" that I did during last weekend (two days, one game, zero sleep) TSG compo (gamejam).  Of course using my Castle Game Engine :) You're welcome to download it from http://sourceforge.net/projects/castle-engine/files/hotel_nuclear/ , developers are also welcome to checkout source code (to you also need "Castle Game Engine" from SVN, see http://castle-engine.sourceforge.net/engine.php ).
 
Short post-mortem (I actually have some useful conclusions at the end :) follows. I decided to write it down, while it's still fresh in my mind :)

GENERAL FEELING:

This is not my perfect creation --- although I am proud of what I achieved, there was simply not enough time to really do what I imagined. I finally picked a project that cannot be finished by 1 person in 2 days :) Which is Ok for me, since I still achieved a lot.

Actually I feel that this is my largest compo game (a lot of programming stuff, a lot of graphic stuff...). To be honest, after every compo, I think "this was the largest work I managed to do during 2 days". Which is very cool. Even if part of this impression is just me being dead-tired, I'm also pretty sure that I'm getting awesome-and-more-awesome with every compo :) The engine (as most of you know, "Castle Game Engine" is my own beloved open-source game engine) also grows because of compo games. Even though I explicitly want to work on a specific game, not on the engine, during the compo. But often some good engine-wide work happens by the way (and, while game-specific code is sometimes quick & hacky, the engine code remains clean & perfect :). And my crazy Blender/GIMP skills also get nicely refreshed every time :)

WHAT WORKED:

- The "core" mechanics work (ghost captures human/alien, changes into them, opens doors, dies in incorrect room, gets keys, opens locked doors, there are hints on doors about keys, somewhat resembling logical puzzles). I think I had a good work plan for programming-related tasks.

- The core graphics are in place. Corridor, room, animations. But look bad, more about this later.

- The game is playable. But it was playable too late, when the Sunday was ending, and there was no time to tweak it.

- Technically were Ok: game works fast, on standalone and Android. "Castle Game Engine" rules! :)

- We have random hotel floors, which was my core "technical" goal. Success :)

- As usual, the built-in "WalkAttack" AI available in Castle Game Engine was a great time-saver. Even when not perfect, it gives you an extremely quick (nearly 0 code) working creature AI in a free 3D worl.

WHAT IS A "TECHNICAL" GOAL MENTIONED ABOVE?

With compo games, I usually have

1. some "gameplay/graphics/feeling" goal (roguelike forest - "Orcs and Volcanoes", fear in 3D - "Darkest Before the Dawn", beautiful - "Little Things", dangerous world - "Mountains Of Fire") and

2. some "technical" goal (level editor and 2D mixed with 3D - "Orcs and Volcanoes", Android - "Darkest Before the Dawn", go crazy with shaders and screen effects - "Little Things", split screen and controls - "Mountains Of Fire").

I found that this works for me. I have to visualize that "this particular game will be great (mostly gameplay/graphics/feeling goal)", but I also have to visualize "this work will make the engine better (mostly technical goal)".

This time the "gameplay/graphics/feeling" goal was "weird hotel in space with logical puzzles". I was thinking about many things, including "Doctor Who" "God Complex" episode.

The technical goal was "random generation of 3D stuff".

THINGS THAT ARE NOT FAILURES, BUT DO NOT MAKE A SUCCESS EITHER:

- Graphically, a lot of stuff is very unfinished (1. lighting is bad --- bleak on corridor, nonsense spheres in rooms, while the purpose was to showcase small local point lights in somewhat dark setting, 2. animations are just tests --- knight and archer from opengameart.org representing human and martian..., 3. room interior lacks textures... although, AD3, it was a good decision to leave it as is).

I feel that I could do these things, but there was no time.

- Gameplay: while it works, it needs more stuff to make it really interesting. E.g. special ability of human/aliens. Better AI (they cannot leave the room now! Bad, I planned to use our waypoints/sectors for it). Maybe sometimes you can be killed (e.g. martians hunt humans?), maybe sometimes you can shoot (again, martians shoot humans? :), maybe sometimes keycards are in different places... I had lots of ideas to experiment and make the gameplay more varying. No time to implement and test them.

- More hints on the doors were planned, to make it more a logical puzzle, interesting and playable with really large floors. I managed to implement most important ones ("the key xxx is here", "the hint on the room to the left IS A LIE" etc.). More were planned.

FUTURE AND THOUGHTS (aka: "notes to future self") :

1. Make the graphics crude, but focus on showcasing the main thing first.

For example, with "Mountains Of Fire", the "focus" (core idea) of graphic was "black vs red colors". With "Little Things", it was shaders and painting-like look. For this game, I should have said to myself "the core look depends on bright lamps in a long, dark corridor". Good: I did make the corridor perspective (all those views on a long corridor work :), bad: I did not set up nice lighting.

Instead of playing around with texturing etc, I should have focused on lighting, as the lighting was my core graphical vision here.

CONCLUSION 1: decide what is the main feature of your graphical look, and make it happen soon, this rules over everything else.

Do not tweak textures. Do not tweak 3D meshes. Do not make any animations, there is really no time for it (for me at least) during the compo. Spend more time on choosing (and brutally adjusting) downloaded stuff from http://opengameart.org/ and http://www.blendswap.com/ .

2. Gameplay must be playable much sooner. With previous compo games, I spent Sunday evenings designing specific levels, and gameplay mechanics was somewhat ready (or at least "during testing"). This time, there was no level design. There was a lot more coding and graphical stuff instead. And the gameplay was finished very late (near the end of Sunday), which prevented from tweaking/rethinking it.

I think that the idea "Sunday noon is the deadline for working gameplay" is a good idea.

But how could I have applied it here? If I would just force myself on Sunday noon, I could have resigned from random hotel generation, and instead make 2-4 pre-staged hotel floors in Blender. Looking back, it would be the right choice.

Or I could invent a different gameplay, playing around only with room interiors. Which means "change your whole idea". Problem: this happens on Sunday morning, when you're already getting sleepy, and thinking is difficult :) Looking back, having a backup plan, with only half of stuff ready, would be nice... But that's not really doable for me, to have a backup 50% plan and still commit 100% to the original plan... So, solution: at Sunday 12:00 drink lots of cofee, and invent new gameplay if necessary!

CONCLUSION 2: gameplay must be ready on Sunday noon. If not: cut down on technical stuff, make smart workarounds in graphics. "Short and playable" is your goal on compo, not "long and boring". Also, drink coffee at Sunday noon and if necessary, just change your whole gameplay idea.

-----

As (almost) always, the graphics in this game use various assets from http://opengameart.org/ and http://www.blendswap.com/ . Thanks go to many contributors on these sites. Details are in AUTHORS.txt files in sources.


Viewing all articles
Browse latest Browse all 1725

Trending Articles