View Full Version : GDNET 4E: Thaumatomech
Thaumaturge
20-10-2007, 07:13 AM
I think that I have an interesting gameplay concept for my GameDev.Net Four Elements contest entry.
For those who might not remember, my storyline idea was set in the future of a fantasy world, and has a father seeking to recover his little daughter's favourite toy pony from the clutches of a maniacal villain (who would seem to be more evil than he is ambitious). His means of doing this relies primarily on his battlemech-like "thaumatomech".
I had previously been considering using one of two gameplay types: fast-paced action played against many foes at once, or a more slowly-paced game played against fewer, more powerful opponents, in the vein of a 'MechWarrior game.
Instead of these (I think) fairly obvious gameplay concepts, I now prefer the following:
The game places the player in a fairly small region, generally laid out with walls and obstacles to be avoided, and is given a goal (such as the reaching of a particular point, or the destruction of all opponents). However, instead of directing the thaumatomech directly, the player selects commands to be issued at particular points in time, and then sets the process into motion.
As the level plays out, the thaumatomech responds to each command that has been given it as that command's time arrives, presuming of course that nothing interferes. At any point the player can pause or reset the level and change the list of commands, and then set things once again into motion.
The commands would be presented on a timeline, most probably measured in seconds or pairs of seconds. On the other hand, that may well result in large stretches of unused timeline between important commands - a better interface might simply allow players to specify the appropriate point in time (in seconds) for a command, and have those commands be placed in a list, sorted by point in time.
The current point in time would most probably be displayed fairly prominently in either one corner or along one of the edges.
Examples of potential commands might be:
Set throttle
Fire weapon one for x seconds
Turn by x degrees
Turn to direction x
One element commonly found in levels would be large, unstable crystals, that react violently to high densities of magic, such as those generated by magical weapons.
That is, they explode when shot.
I would also like each enemy type to have its own particular explosion.
The accountants would of course be available to give (cryptic) advice on the current level.
At any one time the thaumatomech would carry four spells that can be fired. Not all would be weapons - some might disable opponents, or gently move crystals (without generating a high enough magical density to cause detonation), or block off passages.
I am not yet sure of whether I want to allow the player to devise custom weapons and utility spells - it's an attractive idea, but might feel a little "tacked-on".
The result is, I hope, an interesting action-puzzle game, aimed at casual play.
So, what comments, suggestions and criticism has the community? ^_^
~
Images of my (untextured) thaumatomech model (or rather, models, as multiple models are used for the purposes of animation):
http://img99.imageshack.us/img99/6349/thaumatumechorthographivg4.th.png (http://img99.imageshack.us/my.php?image=thaumatumechorthographivg4.png)http://img142.imageshack.us/img142/9937/thaumatumechorthographiew6.th.png (http://img142.imageshack.us/my.php?image=thaumatumechorthographiew6.png)
http://img151.imageshack.us/img151/6205/thaumatumechperspectiveih5.th.png (http://img151.imageshack.us/my.php?image=thaumatumechperspectiveih5.png)http://img143.imageshack.us/img143/4043/thaumatumechperspectivefp3.th.png (http://img143.imageshack.us/my.php?image=thaumatumechperspectivefp3.png)
The "cage" visible at the back is intended to carry a large, spinning crystal.
BlackHawk
21-10-2007, 10:44 AM
Interesting idea. The model looks good as well.
My thoughts on the proposed mechanism: I kept thinking of waypoints. Dynamic or otherwise. If you want the player to sus the commands out by trail and error, then you would create a waypoint for each command (or pair/groups of commands that can operate in parallel). Maybe visually show where the mech's position would be after each command and then the player must modify his commands until he is happy with his plan. This sounds a lot like the strategic planning you would do when playing a game like SWAT.
Of course, this waypoint idea is horizontally opposed to your timeline. To incorporate the two, place a limit on the abilities of the mech. It can only move so many units in 1 unit of time, but it won't override the waypoint the player set up.
Are you shooting for turn-based gameplay?
Thaumaturge
22-10-2007, 05:06 AM
Thank you very much for your comments. ^_^
Your waypoint idea is a very interesting one. It may well make for a far more engaging gameplay system to have the player place waypoints on the map, each of which can contain commands (such as the firing of a weapon) that are executed on reaching the waypoint.
So, for example, you might place a set of waypoints like so:
2
O----O3
|
|
O
1
(O = waypoint
/,\,|,-- = path)
With that done, you might specify that at waypoint 2 the 'mech should stop for ten seconds and fire a weapon for twenty seconds. In-play, once the 'mech reached waypoint two, it would duly stop, and begin firing. Once ten seconds had passed, it would begin moving to waypoint 3, still firing, only ceasing fire after another ten seconds had elapsed (or until something else happened to cause it to cease fire, such as an appropriate command at waypoint 3).
A waypoint system sounds like a very good idea - thank you for it. I shall think on it, I believe. ^_^
Are you shooting for turn-based gameplay?
No, I'm currently aiming instead for a playstyle similar to that of The Incredible Machine or Armadillio Run. Instead of composing a set of mechanical parts in space, this game would have the player compose a set of commands in time (or, if I decide to use your waypoint idea, commands composed in space, with an implicit time component).
BlackHawk
22-10-2007, 01:53 PM
No, I'm currently aiming instead for a playstyle similar to that of The Incredible Machine or Armadillo Run.
Aaaah, now I understand much better.
UntouchableOne
22-10-2007, 02:08 PM
Good concept. Nice model. Where's the demo? :P, just kiddin'
dislekcia
22-10-2007, 03:08 PM
I suggest taking a look at using a system similar to the one used in Eets (http://www.eetsgame.com/). The user places objects that change the behavior of the main character at specific locations. That might be a lot easier than having to create a unique programming language, you could then give "orders" to a state-machine using collision events and arguments, much simpler ;)
-D
Gazza_N
22-10-2007, 09:06 PM
Sounds like fun. A bit like Dave! or Lemmings but with a more action-oriented approach. The absurdist storyline helps too. ;)
I'm loving the Thaumatomech design, BTW. Are you planning a full 3D engine, or will you use prerendered 2D graphics?
Thaumaturge
23-10-2007, 03:06 AM
Thank you very much for all of your comments. ^_^
Where's the demo?
I only plan on starting in on the coding once I have the Myriad prototype complete, I'm afraid. (Yes, I am still working on that!) :P
I suggest taking a look at using a system similar to the one used in Eets.
Thank you very much for the link, and the suggestion! That is a very interesting (and rather fun) game. ^_^
Hmm... Essentially, if I understand you correctly, one would place items that correspond to commands such as "move", "fire", etc.
In order to replicate the behaviour in my previous waypoint example, one might do the following:
1) Place a "move" item at the 'mech's current position (Waypoint 1's position in the previous example).
2) At Waypoint 2's previous location:
-a) Place a "turn 90 degrees" item (or a "turn" item with a value set to "90 degrees").
-b) Place a "stop for 10 seconds" item (or a "stop" item with a value set to "10 seconds").
-c) Place a "fire" item (or parameterised equivalent, as in the previous cases).
-d) Place a "move" item.
Am I correct?
Of course, I could take a course between the two: use waypoints and waypoint-associated commands for basic tasks such as movement, turning and firing, and include objects in the world for other tasks, such as some form of jump-pad to allow the 'mech to "hop" over obstacles.
Another interesting idea to factor into my thinking - thank you again. ^_^
The absurdist storyline helps too.
Heheh, of course. I intend to work on incorporating that same humour into the general gameplay as well - hopefully with success.
I'm loving the Thaumatomech design, BTW.
Thank you. ^_^
On reflection, I've realised that the position of the weapons might present a problem, so I've decided to move them to a position beneath the "nose" of the 'mech.
Are you planning a full 3D engine, or will you use prerendered 2D graphics?
Full 3D, although the gameplay is intended to effectively be entirely 2D. As I start in on the coding for this project, I intend to start working on the design work for a larger project, in which I intend to use a third-party graphics library, and I see Thaumatomech as an opportunity to grow accustomed to the chosen library (and perhaps a physics library as well) before starting in on the bigger project.
I'm strongly considering the OGRE library, although I may well post a thread asking for advice on this when I come to the point of decision.
Dave!
I don't know this game, and a quick search didn't turn anything up - can you link me to it, please?
Gazza_N
23-10-2007, 05:37 PM
Dave! was a game that UncleSam did for an early Game.Dev competition. It involved guiding a hapless little man through a level using a selection of different objects, including jump pads, pillows (to break falls instead of bones) and direction signs. If Mr. Sam could provide a link, you can see it first hand. Should I mention that it took podium?
Thaumaturge
24-10-2007, 05:20 AM
That does indeed sound interesting, especially as a potential source of inspiration for this project - thank you. ^_^
If Unc1354m doesn't reply to this thread, I may well PM him in order to inquire...
Unc1354m
24-10-2007, 05:20 PM
http://www.clanexe.com/downloads/dave.zip
There's the link to Dave! :)
Thaumaturge
25-10-2007, 04:44 AM
Aah, excellent, thank you very much, Unc1354m! 'Tis appreciated. ^_^
Thaumaturge
04-11-2007, 06:31 AM
Well, I've been thinking more on this concept, and believe that I have made some progress.
At the moment I intend that the main gameplay element be a waypoint system, and the primary means of interaction with the environment be, well, blasting things - accompanied, of course, by many explosions. ;)
Waypoints and commands
The primary use for waypoints, of course, is for directing the 'mech - the 'mech simply walks from waypoint to waypoint.
Waypoints are also used for issuing other commands to the 'mech, although I now intend on having only two commands:
Fire weapon
Stop (for x seconds)
These would be accessible via an interface that appears when the player clicks (or perhaps double- or right-clicks; the controls are not yet set in stone) on the waypoint. If a command is set at a given waypoint, I intend that small icons appear above the waypoint to indicate what commands are given there.
When the "fire" command is selected, the player is asked to indicate a target. When the 'mech receives a "fire" command, it fires on that target until the target is destroyed (or, in some cases, changes to an inactive state), or it receives an order to fire on another target.
(Perhaps a "cease fire" command should be available as well?)
Weapons
Note that the 'mech is now intended to carry only one weapon (although weapon upgrades and replacements might be available for a given level via objects either found or placed in the level).
As to that weapon, I am currently undecided between a beam weapon and a pulse weapon. Both can look cool, but the beam weapon has the disadvantage of being (I think) a little more time-consuming to code, while the pulse weapon has the disadvantage of introducing leading and travelling time for each "bolt".
I'm currently leaning towards beam weapons for all.
Placeable objects
I am still undecided on the matter of objects that the player may place in the game area. On the one hand, such a system would, I feel, add much to the gameplay. On the other, I don't feel that it fits in very well with the game's premise.
I may yet include it, however - I just find myself unsure...
Enemies
Enemies are planned to be highly deterministic - this is, after all, a puzzle game and thus, for a given set of starting conditions, things should always play out in much the same manner (or at least with much the same conclusion).
I would like to have a number of enemy types - I currently have in mind a necromech (constructed primarily of bones), a lesser dragon and a greater dragon. I would like one enemy type to be invincible.
A gameplay idea that I encountered recently and rather liked was that of "herding" enemies - I'm not yet sure of how I might include it in this game (other than that enemies would probably react to certain events and obstacles (such as being shot :P)), but I do think that it might add well to the gameplay.
Explosions
A short while ago I encountered a description of a system that employed cellular automata for such effects as fire, liquids and the like (if I recall correctly). I'm wondering whether a simple version of such a system might be a good idea for the implementation of large explosions in my game, as opposed to simple particle explosions.
I had wanted to allow particles (or at least some particles) to collide with objects, thus hopefully preventing or reducing the effect of particles moving through supposedly solid objects (such as walls), and allowing for tight spaces to funnel explosions (and thus probably make them more deadly).
However, I wonder now whether a cellular system might not be a better idea.
As I imagine it at the moment, the level would have a two-dimensional grid of cells overlaid on it. Where static obstacles exist the cells would either be marked as inactive or would not be created, depending, I suppose, largely on the structure used for the grid.
Each cell would have a set of values corresponding to the "density" of a number of elements in that cell - thermal energy, for example, or magic. On each logic update, each cell would compare itself (or be compared) to its neighbours. If it is found to have a higher "density" in some field than any neighbours, a certain amount of "energy" is transferred from it to them, the amount in each case depending on the time elapsed and the difference in energy between the cell and the neighbour in question. As well as this, energy would be lost over time.
When a cell has energy, it produces particles appropriate to the type of energy - fire particles for thermal energy, for example.
~
So, what do you think?
Tr00jg
04-11-2007, 05:24 PM
Like I always like to say. A prototype will be best! Gimme. :)
Thaumaturge
05-11-2007, 06:15 AM
*chuckles* You and your prototypes. ;P
Very well then, time for me to decide on certain matters, such as graphics and physics engines.
Yes, I know that it's just a prototype, but I want to re-write only minimally when moving to the full version of the game, hopefully building up from prototype to prototype, and eventually to full release, instead of re-coding the full game using different technology.
As to why I'm choosing to use third-party libraries this time, I want to use Thaumatomech as a means of learning the use of said libraries for the adventure game project that I have in mind (which I intend to be in a 3D setting).
So, the question of which library to choose. At the moment I strongly suspect that I'll choose OGRE for graphics - I've gathered a fairly good impression of it thus far.
In terms of physics, I am rather undecided. All that I'm really interested in is collision detection and response in two dimensions. I'm happy to represent my objects as either circles or, better yet, boxes, and walls as either lines or boxes.
I have thus far discovered the ODE (http://www.ode.org/), Newton (http://www.newtondynamics.com/downloads.html), Bullet (http://www.bulletphysics.com/Bullet/), Tokamak (http://www.tokamakphysics.com/index.htm) and OPCODE (http://www.codercorner.com/Opcode.htm) libraries. All but the last seem to me to be overkill for my purposes, but I feel that, even having performed some basic searches on GameDev.net, I don't yet know enough about them. I do intend on looking into this more before making a decision, but if anyone here has any advice to offer, I would like to hear it, I believe. ^_^
Of course, if I thought that I was likely to find a free game engine that would be suitable to both Thaumatomech and my adventure game, then I'd probably use that. (Since I plan on portraying the adventure game from the first person perspective the Wintermute Engine, an adventure game engine that I have used before, is probably not going to work - which is a pity, it seems to me.)
Cyberninja
05-11-2007, 11:39 AM
We are Venom. We needs demo. ;) Seriously.
dislekcia
05-11-2007, 12:54 PM
Go with ODE, I haven't had problems with it.
-D
Thaumaturge
08-11-2007, 02:40 AM
Aah, thank you, Dislekcia - I appreciate the advice. ^_^
(And my apologies for delaying in replying.)
In fact, it seems that there even exists an ODE wrapper for OGRE, which might well be very useful...
The collision resolution method of creating temporary joints (as described in their online user guide) seems a little odd to me, however - is that the standard method used by physics systems?
Powered by vBulletin® Version 4.2.4 Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.