8 replies to this topic

[Alessandro]

As many unskilled wannabe game designer I would like to give my try to define the mechanics for some videogame: just thinking "ehy, maybe this will be fun".
What I am looking for is... opinions if this is the right way to suggest a game desing, and maybe if someone think this could really turn in a real project (or what it lacks to become so).
So, here's my first game design (I had other two games in mind!)

###############################
#######Dungeon descent###########
###############################

The main setting of this game is fantasy... all about dungeons really. This dungeon looks more like a reversed underground tower (a well or a valut, you name it). I designed this concept for smartphone or tablet: it does use accelerometer (tilting left/right to move sideways) while swipe and touch (thumbs only, so swipe controls need to take in account the limited motions) will be used for other operation (cast magic, attacks or whatever) or using two simple virtual button.
image http://i41.tinypic.com/2iwas5s.png
The "core" idea for this concept is similar to this and many other clone but it's also extended to a richer gameplay thanks to swipe and/or touch features; the game is pretty much about 2D but since actions are quite limited (walk left/right, fall, attack... and optionally jump, cast magic)
image: http://i41.tinypic.com/2n747bs.png
This scheme is how you should see it on your smartphone/tablet; a spiked ceiling on the top lower constantly trying to squash our hero. Below there's space for two virtual buttons (just touch) if code swipe function is a bit of a issue... but definitely these button should't be used for the main function (walk left/right) otherwise the gaming experience will resemble something coming from the 'ol good '80 handheld gaming
image: http://www.playnow.i...eID=279&thumb=1

Landscape mode
there are three main reason I've opted for this mode rather picture mode one, these are:
1. bigger sprites: on picture mode you can't make the sprite too big otherwise you need larger holes for a small floor
2. gameplay is focus more during the walks and the floor is longer: you need to make quick decision if fall below on the next floor or fight enemies to catch powerups.
3. it's easier to tilt your (supposedly widescreen) smartphone/tablet in landscape mode

[fireside]

I guess it's a pretty good idea. Point is, you won't realize it until you know some programming unless you can find a programmer. It is basically all right to use an existing game to develop from if it's not too obviously the same. The game with the ball was pretty fun.
I guess I would suggest looking at Gamemaker since it sounds like you aren't a programmer. You would need the professional version to output to IOS or Android, but that's relatively cheap in the whole scheme of things, and you could design the game on the free version. Myself, I get a basic idea like that one you have and then start a working prototype and go on from there because having intricate plans are mostly a waste of paper once you get the game working.

[Alessandro]

Thanks for the feedback: I see GameMaker is a quite popular choice since I got the same exact suggestion on another forum. "See it for real how it works" is definitely the way to go... but still I want to see if I can manage to learn how do design doable idea directly from scratch (even if I had to waste 90% of them) and redesign constantly in order to make it possible rather having to fix on something that probably is too twisted to be accomplished.

If a programmer is interested in this idea, and want me to join to develop it, here what I can possibly do for the project (taken directly from another thread of mine): what I can do is some (humble) art and story background: here are all the webcomics I've made. I don't think I am good with animation, but maybe there's a possible solution: find a free 3d knight model and apply these free animations (these bvh are free to use for personal and commercial use)?
Also, I am not good to draw "modular" background, but can give it a try. Definitely I can draw character portrait on screen if needed. Anyway, here's some more details with the game.


Notice: I don't know how much hard can be these things done, so I have introduced the basic/advanced paradigm. What's basic it's the "plain idea", what's advanced add more fun to the gameplay... but it's not essential and thus can be avoided if too much issue to program it)
-=Controls=-

Movement:

Accelerometer set the speed in which character runs or walk: the difference between both modes (walk mode and run mode) isn't just about speed but also comes with pros and cons, animations need to be different to make more intuitive these animation (ie: when the character walk the shield is lifted and ready to block == easier to realize the knight is more protected).
How it should work: let's suppose accelerometer has a value between +100 and -100. Value "0" is for "even" or "flat", +100 is the max tilt at left, -100 is max tilt right.
When tilt is between +100 and +80: knight "runs" left at max speed with "run" animation (run mode)
tilt between +79 and +40: knight "walks" left fast with "walk" animation (walk mode)
tilt between +39 and +10: knight "walks" left normal with "walk" animation (walk mode)
tilt between +9 and 0 AND -9: knight stand still waiting (between +9, +1: face left // between -1 and -9 face right)
tilts between "-100 -80", "-79 -40", "-39 -10" are the same exact of the previous one.. but with at right instead left.
[movement advanced option: I though a trick to avoid abuse of the "run" mode: sometime there are puddle on the ground... you can past "safety" them only if you walk... whenever the knight try to run onto it... he fall over on the ground <additional animations for fall and rise up required]

Hit or be hit enemies during "walk" and "run" modes )

Simply touch the screen (or see the "hit advanced option") make our hero swing is sword. There are two type of sword swing possible: aggressive (when knight runs) or passive (when knight walks or stand still). The attack value and the "effectiveness" of each swing also depend on the type. here's a detailed view on how things work.
Aggressive (running): when the knight is running his attack value is increased by 30%~40%, but the animation has more frame so take longer time before take effect (remember the original Street Fighter 2: quick and weak punch/kick has only 1~2 frames, strong punch/kick have more "charging" frames). If the enemy is too close to your knight you may run into him (getting hit) before the sword was even withdrew... and you will suffer heavy damage too! The trade off is that a successful it also make your enemy pushed back.
Passive (walk or stand still): Knight cast sword more fast and repeatedly: you aren't able to harm and push back your enemies that much, but the trade of is that you can swing faster and repeatedly. If you're hit by an enemy facing you, take little damage but you're pushed back. If you're hit by an enemy at your back (most unlikely, but it can happen) you take stronger damage and pushed forward. In this The knight can swing is

[hit advanced option:

optionally the "fire button" can be substituted by the swipe: you can swipe left or right... in which result the knight to swing his sword in both direction regardless the direction he's facing]

[Alessandro]

Ok, recently I've worked a bit up on this idea... I've also made a forum to help categorise things up (here: http://forto.altervista.org ). If someone like this idea and feels like to join up with me as dev team I am more than gladly to!

Anyway, here's what done about Dungeon Fall so far now.

Intro
Rosame wasn't the kind of adventurer, nor she would have ever though one day she would pick other people's properties without asking them first: but you know, it's said that when famine hits the whole kingdom, most heals from starving are unlawful.
Rosame wasn't never ever confident with her own inner or outer beauty: that's why she'd become a thief; but she also got her own way to make things clean.
In lands ravaged by famine what possible rich being she could pickpocket? Her first though were about the dead ones: descend into the depths of the catacombs it seemed a smart choice for her.

The poor Rosame.


Rationale
We control Rosame at her descent on what she think is a catacomb; as soon she enter the dungeon the ceiling fall down... but she manage to survive jumping down in a hole. Once she get on the lower room the ground above her crumble under the weight of the ceiling. Another hole in the ground is her new exist... and so go on until she doesn't reach a special hall (end level) where's she safe from the collapse... but still trapped in the dungeon. So, her only way to escape is yet again to descent to the next underground level... which mean she will run again and again for each Hall until she's able to find a definitive way out of the dungeon.
The game is a 2D sidescroller (descending from top to below). It's all about falling down since Rosame can't climb up... nor can stand still too much time on a single platform (the ceilings are falling like dominoes).
Gameplay and mechanics
video

Core structure
The camera view descent slowly but constantly; if our heroine Rosame is caught between the ceiling (which is the top of the camera view) and the floor she dies instantly; in order to survive she need to fall through hole to hole on the collapsing grounds, and so go on until she don't reach a safe place (a special room coated in stone/metal) which is the end of the current level (see "development plan" for level-world structure).

Rosame's stats
There are three attributes that will take effect during the gameplay: Speed (SPD), Attack (ATK), Defence (DEF) and Health/HitPoints (HP).
HP: there's nothing special about this, HP works the usual way: [enemy inflict damage to Rosame == HP down], [Rosame collect/use potion (see powerup item section) == HP up]
SPD: the speed in which Rosame moves trigger three different modes ([Idle],[Walks],[Run]: see "Controls section" for more detail ) and four speeds: [idle] = stand still, [walks] == move slow OR normal (same animation, different speeds), [run] == move fast. Ultimately [walk] and [run] modes ATK and DEF (the [walk] and [idle] modes act same but one stand still while other actually moves).

animation
Stats alteration when [idle]/[walk]: this is the defensive mode, ATK is lower but DEF is increased. Also attacks with quick stabs.

animation
Stats alteration when [run]: bersek mode, ATK is increased but DEF is nearly non-existent. Since running, attacks take up much more space and so need a good timing or else you'll crash on enemy (vulnerable area)
Controls
video
Player movement are done though smartphone/tablet screen rotation, currently screen inclination control the mode in which Rosame runs, walks or stand still (you're not supposed to stand still that longer). When Rosame reach an hole, she fall down below: no action is required by the player.

If we assume that the player is holding the handheld laying it on the conjunction between finger and wrists (metacarpals) while index finger is holding up (ref) then player may have both thumbs free (try yourself, you'll see it's not that hard keep this position).
With both thumbs free player can still assume extra control: from the simple tap, to swipe and even pinch to zoom effect (thumbs may have limited movement from the border anyway). Since tilting the handheld it's already a bit of challenge we go for the most easy way: player can use it's thumbs on two simple virtual buttons on the bottom


Controls through device tilting
In order to control both walking directions the player uses screen tilting, also we take advantage of the analog feature for improve gameplay experience: the more the screen is tilted, the more Rosame will run fast.
In the given example, let's assume that the tilting value is +100 and 0 (where 0 is "flat device") for tilting left and between -1 ~ -100 is for tilting right.

Where:
+100 and +80: Heroine runs left at her max speed possible, animation is "running" and so [run] her walking mode.
+79 and +40: Heroine walks left steady and (moderately) fast, her animation is "walks" and so [walk] her mode.
+39 and +10: heroine walks slowly left, animation is still "walking" and so her mode [walk]
+9 and 0 (also 0 and -9): heroine stand still, animation is "standing" but you can force her to face left direction (for hit in that direction). The same apply for -1 and -9 value... so player can switch which direction to face without need to actually moving.
Negative value have the same attribute, but speculative (right) direction.

-----------------


Ok, that's all so far now!
There's some little extra stuff on the official thread and on my youtube channel. But you don't need to get there: I am watching this thread.

[Stainless]

I have just ported Speedball 2 Brutal Deluxe to AGP and it has an option of tilt control.

It's awful. Truly awful.

For a start if you don't calibrate the initial position correctly, the game is unplayable.

Secondly you end up banging your head on anything nearby as you try and see the screen and tilt it at the same time.

It's one of those ideas that should be strangled, hung, shot, stabbed, poisoned, drawn, quartered, dipped in molten tar, and hung on the front page of Devmaster.Net as a warning to others.

[Alessandro]

Stainless, on 15 April 2013 - 03:48 PM, said:

I have just ported Speedball 2 Brutal Deluxe to AGP and it has an option of tilt control.

It's awful. Truly awful.

For a start if you don't calibrate the initial position correctly, the game is unplayable.

Secondly you end up banging your head on anything nearby as you try and see the screen and tilt it at the same time.

It's one of those ideas that should be strangled, hung, shot, stabbed, poisoned, drawn, quartered, dipped in molten tar, and hung on the front page of Devmaster.Net as a warning to others.

It's ok, I am not willing to be the "master" of this project. I shall do as well my job: if the use of accelerometer are out of reach or too much overwork I can simply re-design the whole concept for the touch/swipe on screen.



The problem with buttons on touch screen is the missing "physical feedback" which forces players eyes to distract from action to check "where his/her finger are" until doesn't memorize. But I can easily think about some alternatives... one for example is to use the border of the screen as that "physical" reference one's need.


I can remove and add some things that come up in my mind.. but I need to work with a team to know what exactly can be done and whatnot.


Anyway, I am working on other gamedesing that will post soon (I've roughly other 3~4 game design in mind)... so there's plenty to choose from before actually starting developing.

[Stainless]

The best system I have found requires multi-touch.

On the left of the screen you have a floating dpad. The first touch defines the centre, any movements away from this point are the input.

So touch and move up == dpad up

Any touches at the right of the screen are treated as a fire button.

[Alessandro]

 Stainless, on 17 April 2013 - 05:10 PM, said:

The best system I have found requires multi-touch.

On the left of the screen you have a floating dpad. The first touch defines the centre, any movements away from this point are the input.

So touch and move up == dpad up

Any touches at the right of the screen are treated as a fire button.

This is a well know a very used way within nowdays VG on touchscreen devices, and I can't argue on it: it's a very good way to translate joypad gaming on touch screens!
But in this concept there's no UP and DOWN buttons: it's just you running on the X axis and, sometime, falling down below at Y. A whole d-pad cross on the don't give enough "weight" to the importance to running on X asis.

[Alessandro]

Great news people, we've managed to set up a dev team (we're named "Jackass Penguin" now) and our first project will be Dungeon Fall. You can find more on:


Thanks everyone for all the inputs given... but we need more if want to do this game uniquely enjoyable! Please, share your though at our page on Steam Greenlight, IndieDB or Desura
-----