Advertisement

Constructive (as opposed to destructive) Gameplay Concept

Started by September 02, 2005 11:41 AM
14 comments, last by Trapper Zoid 19 years, 5 months ago
For the past week, I've been mulling some ideas for a game around. At the beginning, the game had one stipulation: no violence allowed. I'm tired of shooting, punching, decapitating, blowing up, running over, and otherwise mutilating my adversaries to progress through a game. I believe there needs to be adversity in a game for fun's sake, but there's more to problem-solving than blowing the **** out of stuff. And yes, I think non-violent games can be quite fun. Here's what I've come up with: - The player is tasked with getting a robot from point A to B - There will be obstacles in place to prevent the robot from making an easy exfiltration - The game will have no destruction; the robot does not have destructive capabilities - The robot will solve problems by being constructive (literally) and clever - The robot will be 'programmed' by the player - The robot will have a small, but orthogonal set of programmable capabilities - The game must be playable and fun to a layman - The robot is upgradable as the game progresses - The robot will be granted new programmable capabilities with better sensor upgrades - The robot will be granted new constructive capabilities with better mechanical upgrades - It will be 2D (top-view and tile-based) When I say 'constructive', I mean that the robot may need to build a simple bridge or a ramp to overcome an obstacle. When I say 'clever', I mean that the robot may need to turn 90 degrees to the left when it comes within X feet of a wall. Here is what I consider the greatest challenge: making scripting for the robot as simple as possible (so it seems like a game) while still being powerful enough to make this game viable. Any ideas?
Quote:
Original post by Kevinator
- The robot will have a small, but orthogonal set of programmable capabilities


You don't literally mean the Orthogonal programming language do you? THAT would be something to see in a game. I've often mulled doing something similar to what you're talking about, but then I concluded that far more people get addicted to blowing the crap out of things than get addicted to moving robots around. It would appeal to the programmers for awhile, as a neat little way to pass the time, but ordinary people aren't likely to mess with it. They'd go play solitaire or something.

Do not take me as being critical of your idea though. I would certainly be interested in something along these lines. I'm just saying the hardcore gaming populace wouldn't be.
Advertisement
By orthogonal, I mean that the scripting language will have a very small number of constructs, but those constructs can be combined in many ways. This way, I can keep the scripting interface simple enough to make it a GUI, yet powerful enough to make the game viable. I don't expect most gamers to like this game, but I do want to make it simple and fun enough that they would give it a try (and be able to succeed without too much effort).
Well, go ahead and try it. I would really love to see Orthogonal (the language) used in games. That, or brainfuck.
Maybe I'll have a version just for hardcore programmers that requires you to program the robot in Brainf***. [lol]
/me licks his chops
Advertisement
Sounds good to me.

From the sounds of what you've said, the player will need to examine the level, program the robot, and then watch it attempt to solve the level using that programming, is that correct?

- Will the levels need to be completed all in one shot, or can the robot be given new instructions part way through?

- Will the player get to try again if they fail to complete the level first try? Will there be a disadvantage to failing attempts, or simply an advantage to finish on the earliest attempt possible (More cash towards upgrades for finishing first try for example)?

- Will there be more than one way levels can be solved, or will players need to figure out some specific method for each level?

Quote:
- The game must be playable and fun to a layman


How will a layman be able to interact with the scripting of the robot - some kind of graphical programming system, like a drag-n-drop flowchart that controls the script or something?

- Jason Astle-Adams

Those are all excellent questions. [grin] I'm afraid I haven't gotten to that level of detail yet.

Quote:
Will the levels need to be completed all in one shot, or can the robot be given new instructions part way through?


Initially, I was planning to let the player program the robot between levels. Perhaps I could include a hardcore mode where you have to make the robot's programming robust enough to be able to handle any obstacle, and an easy mode where you can repgrogram it between levels. Something to think about, anyway.

Quote:
From the sounds of what you've said, the player will need to examine the level, program the robot, and then watch it attempt to solve the level using that programming, is that correct?


That is correct. I'm worried about the lack of interactivity once the player presses the 'go' button, however.

Quote:
Will there be more than one way levels can be solved, or will players need to figure out some specific method for each level?


You bring up a good point - multiple solutions are a must! I remember playing Sierra's The Incredible Machine and marvelling at the number of ways a problem could be solved. I had some pretty far-out-there solutions to some of the levels. It is my hope that the game will be complex enough to allow the satisfaction of a range of solutions, from convoluted to elegant.

Quote:
How will a layman be able to interact with the scripting of the robot - some kind of graphical programming system, like a drag-n-drop flowchart that controls the script or something?


That was my original thought. I'll certainly allow the user to code if they want, but I would like to provide some kind of GUI for the less-experienced. If it's feasible.

Quote:
Will the player get to try again if they fail to complete the level first try? Will there be a disadvantage to failing attempts, or simply an advantage to finish on the earliest attempt possible (More cash towards upgrades for finishing first try for example)?


I hadn't thought about this but I like your idea about more money for less attempts. I'll be sure to give you credit if I use that idea.
Sounds like a good idea, a little like the game where you have to build pipes from one point to another before the water starts, just more complex.

About the scripting language, if you intend normal (those who think the Internet lies on their computer) computer users to play the game you either need to make the scripting language very simple or provide different ways to program the robot. If you want to make a real good game providing a "visual scripting language" would be a good idea, of course a text based language should be an alternative to the user. What I mean by visual is that your robot might have some predefined senses, lets just say it can check whether there is something is in front it and behind it. These might be represented by:
+--+|/\|  OBSTACLE IN FRONT|  |+--++--+|  ||\/| ONSTACLE BEHIND+--+

Then you'ld also have pictures for various actions, maybe for "Turn 90 degrees left", "Turn 90 degrees right", "Move 1 unit forward" and "Move 1 unit backwards".

Then "Obstacle in front" and "Obstacle behind" would have a list of actions, here you could drag the actions. It should also be possible to create actions by combining other actions.

You'ld off course need much more options to create the actual game, but here is already some of the basics for a visual language.

Hope that helped a little.
Have any of you seen colobot? Its a game where you can operate a bunch of robots to build things on other planets though either first person or a c like script. Very interesting game but I haven't had time to play with it fully yet...
- My $0.02

This topic is closed to new replies.

Advertisement