gamedevlists-design — List for discussing game development design

Re: [GD-Design] Speed kills

[Hakan Y. <hak...@3t...>]

I have read the document you wrote. I have some points those I dont agre
with you:

You say" I was talking to my friend Rob Trickey about game design, and he
made the comment that "games just need a speed slider".  And, by golly, he's
right, and thinking about his comment made me realize that speed is the
fundamental parameter that makes an action game easy or hard."
I totally disagree. Good action games are fast paced games. But speed isnt
the fundamental parameter of this games. In all sort of games desicion
making and interaction level is the key element. Yes in action games you
have to decide,act/react fast. But increasing the speed to make the game
harder is just make the player to think he's being cheated. He'll see the
same kind of events and problems becoming just faster. He"ll say "Hey i did
this before, I have to do this just faster". I think (an examle) the player
shoud make desicion in between 1-2 seconds. This 1-2 seconds shouldnt change
for the whole game. Oponent style, intelligence, equipment, event types etc
should change.

You say: "The difference between a skilled player and an unskilled one is
the delay from confrontation to reaction -- in other words, their speed of
response."
I disagree. Actually I agree the first sentence. But I dont think "their
spped of response" make them fully skilled. In quake 3 arena you sould
listen the sounds, know the map, experience the possibilities, experience
the events, and at last you should have aiming and jumping skills. I know
some players, their aiming and jumping skills are very good, But they play
mindlessly, players can increase their aiming and jumoping skills in quake 3
arena but these dont make them good players. I have played q3 in nightmare
mode 3-5 days ago. Computers shoots very fast and its moves better than me.
But it moves precditably and stupid. I know where he is going or doing, I
know he will come from that door, I can hear its voice, So i react and kill
him before he get out of the door. So does the spped of my aiming and
jumping/moving make me kill the bot or my desicion making, knowledge of the
map and game? If you increase the speed of  the bots in quake 3 more the
game will be unplayable. Because when i see the bot I am dead, so i started
to play the game by hiding all the time. Again designers make the NPC's more
intelligent to make the game harder.

You say: " we're stuck with health and ammo restrictions and limited enemy
spawn points."
No, we're not resrtricted to them.  Todays games are lack of artificial
intelligence. The enemey doesnt have the sense of real opponent. Consider
quake 3. Suppose that I am playing quake 3 areana with you. I am a good
player and you're a bettter player than me. What makes you a better opponent
isnt the speed of your character or rate of fire. What makes you better is
your desicion making and playing skills(you make better rocket jumps, good
timing, good aiming vs). The only thing here related to speed may be your
aiming. You may aim faster than me. Take these to single player mode.
Computer should think better, so react better. It must react like a human.
Designers should make the computer more intelligent to make the game harder
an challenging.

You say: " In many cases, they alter the rules enough that the game itself
changes nature between difficulty levels -- instead of becoming harder, the
game becomes harder and different."
You're right. In some games when you change the difficulty level it becomes
a different game. But is it a bad thing,if the game is still playable and
enjoyable?

You say: "An exemplar of this is Hitman 2, where difficulty is adjusted by
limiting the number of saves!"
I agree. Limiting the number of saves isnt related to difficulty. Its
another problem of game design. Its more like cheating to me. Designers
shouldnt use the save game count to make the game harder.

You say: "And there is an element of truth to that, but altering many
variables at once is generally considered more dangerous than changing only
a few.  It's easier to balance and test a system with fewer parameters."
Its lazy design and its very limited, not creative.

You say: The ironic thing is that several games today have included
speed-modification as a way to make the game easier, but in the form of
power ups.  Max Payne's "bullet-time" feature slows down the action, which
in turn makes it much easier for the player to analyze his surroundings and
take appropriate action in a deliberate, unhurried way.  Prince of Persia
and Viewtiful Joe also includes the ability to slow down the action as power
ups.
I agree. Its a good idea but makes the game easier. It doesnt have side
effects except its lessening when used. Maybe in harder difficulty levels
this bullet timing ability could be removed(Maybe they did this I dont know
yet. I just played max payne 1-2 but i didnt played harder difficulty
levels)

You say: "Of course, there is no magic bullet, so there are some complaints
and weaknesses.  A lot of people equate speed with excitement, but I don't
believe that there is as much of a correlation as you'd expect.  Consider
the original Quake, where the player runs at a rate probably twice that of a
character in Call of Duty -- yet I doubt anyone would argue that Call of
Duty is less exciting than Quake.  Speed definitely contributes a certain
degree of base elemental adrenaline to an action game, but I don't think it
is the sole determining factor."
I totally agree here and the following paragraph

Most of my answers will be like these. I  think i give the idea of aht i
think.

My result is changing the speed will not make a game harder or easier most
of the time(Maybe in a few games it can make). Designers should wealth their
games, with challenging NPCs and events. We need more intelligent NPCs, We
need to give the players alternatives to go over. We need to make  playable,
interacting environments. etc. After these are done you can make a fast
paced or slow paced game, an action or strategy game. Speed wont be a
challenging factor in games. Making of desicions in a short time will be
hard, not in shorter and shorter times. Beating one intelligent monster will
be hard and exciting but not 10 fast movoing stupid monster. Action is
exciting but faster action is just overwhelming. Games should be deepened
even action games.

Hakan Yuksel

----- Original Message ----- 
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Saturday, December 27, 2003 4:14 AM
Subject: Re: [GD-Design] Speed kills


I just did a slightly more cohesive write up on this, in case anyone
is interested:

http://bookofhook.com/Article/GameDesign/SpeedKills.html



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=ick
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU6

Re: [GD-Design] Speed kills

[Hakan Y. <hak...@3t...>]

I have read the document you wrote. I have some points those I dont agre
with you:

You say" I was talking to my friend Rob Trickey about game design, and he
made the comment that "games just need a speed slider".  And, by golly, he's
right, and thinking about his comment made me realize that speed is the
fundamental parameter that makes an action game easy or hard."
I totally disagree. Good action games are fast paced games. But speed isnt
the fundamental parameter of this games. In all sort of games desicion
making and interaction level is the key element. Yes in action games you
have to decide,act/react fast. But increasing the speed to make the game
harder is just make the player to think he's being cheated. He'll see the
same kind of events and problems becoming just faster. He"ll say "Hey i did
this before, I have to do this just faster". I think (an examle) the player
shoud make desicion in between 1-2 seconds. This 1-2 seconds shouldnt change
for the whole game. Oponent style, intelligence, equipment, event types etc
should change.

You say: "The difference between a skilled player and an unskilled one is
the delay from confrontation to reaction -- in other words, their speed of
response."
I disagree. Actually I agree the first sentence. But I dont think "their
spped of response" make them fully skilled. In quake 3 arena you sould
listen the sounds, know the map, experience the possibilities, experience
the events, and at last you should have aiming and jumping skills. I know
some players, their aiming and jumping skills are very good, But they play
mindlessly, players can increase their aiming and jumoping skills in quake 3
arena but these dont make them good players. I have played q3 in nightmare
mode 3-5 days ago. Computers shoots very fast and its moves better than me.
But it moves precditably and stupid. I know where he is going or doing, I
know he will come from that door, I can hear its voice, So i react and kill
him before he get out of the door. So does the spped of my aiming and
jumping/moving make me kill the bot or my desicion making, knowledge of the
map and game? If you increase the speed of  the bots in quake 3 more the
game will be unplayable. Because when i see the bot I am dead, so i started
to play the game by hiding all the time. Again designers make the NPC's more
intelligent to make the game harder.

You say: " we're stuck with health and ammo restrictions and limited enemy
spawn points."
No, we're not resrtricted to them.  Todays games are lack of artificial
intelligence. The enemey doesnt have the sense of real opponent. Consider
quake 3. Suppose that I am playing quake 3 areana with you. I am a good
player and you're a bettter player than me. What makes you a better opponent
isnt the speed of your character or rate of fire. What makes you better is
your desicion making and playing skills(you make better rocket jumps, good
timing, good aiming vs). The only thing here related to speed may be your
aiming. You may aim faster than me. Take these to single player mode.
Computer should think better, so react better. It must react like a human.
Designers should make the computer more intelligent to make the game harder
an challenging.

You say: " In many cases, they alter the rules enough that the game itself
changes nature between difficulty levels -- instead of becoming harder, the
game becomes harder and different."
You're right. In some games when you change the difficulty level it becomes
a different game. But is it a bad thing,if the game is still playable and
enjoyable?

You say: "An exemplar of this is Hitman 2, where difficulty is adjusted by
limiting the number of saves!"
I agree. Limiting the number of saves isnt related to difficulty. Its
another problem of game design. Its more like cheating to me. Designers
shouldnt use the save game count to make the game harder.

You say: "And there is an element of truth to that, but altering many
variables at once is generally considered more dangerous than changing only
a few.  It's easier to balance and test a system with fewer parameters."
Its lazy design and its very limited, not creative.

You say: The ironic thing is that several games today have included
speed-modification as a way to make the game easier, but in the form of
power ups.  Max Payne's "bullet-time" feature slows down the action, which
in turn makes it much easier for the player to analyze his surroundings and
take appropriate action in a deliberate, unhurried way.  Prince of Persia
and Viewtiful Joe also includes the ability to slow down the action as power
ups.
I agree. Its a good idea but makes the game easier. It doesnt have side
effects except its lessening when used. Maybe in harder difficulty levels
this bullet timing ability could be removed(Maybe they did this I dont know
yet. I just played max payne 1-2 but i didnt played harder difficulty
levels)

You say: "Of course, there is no magic bullet, so there are some complaints
and weaknesses.  A lot of people equate speed with excitement, but I don't
believe that there is as much of a correlation as you'd expect.  Consider
the original Quake, where the player runs at a rate probably twice that of a
character in Call of Duty -- yet I doubt anyone would argue that Call of
Duty is less exciting than Quake.  Speed definitely contributes a certain
degree of base elemental adrenaline to an action game, but I don't think it
is the sole determining factor."
I totally agree here and the following paragraph

Most of my answers will be like these. I  think i give the idea of aht i
think.

My result is changing the speed will not make a game harder or easier most
of the time(Maybe in a few games it can make). Designers should wealth their
games, with challenging NPCs and events. We need more intelligent NPCs, We
need to give the players alternatives to go over. We need to make  playable,
interacting environments. etc. After these are done you can make a fast
paced or slow paced game, an action or strategy game. Speed wont be a
challenging factor in games. Making of desicions in a short time will be
hard, not in shorter and shorter times. Beating one intelligent monster will
be hard and exciting but not 10 fast movoing stupid monster. Action is
exciting but faster action is just overwhelming. Games should be deepened
even action games.

----- Original Message ----- 
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Saturday, December 27, 2003 4:14 AM
Subject: Re: [GD-Design] Speed kills


I just did a slightly more cohesive write up on this, in case anyone
is interested:

http://bookofhook.com/Article/GameDesign/SpeedKills.html



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=ick
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU6

Re: [GD-Design] Speed kills

[Brian H. <ho...@py...>]

I just did a slightly more cohesive write up on this, in case anyone 
is interested:

http://bookofhook.com/Article/GameDesign/SpeedKills.html

[GD-Design] Speed kills

[Brian H. <ho...@py...>]

After talking to some friends about different games and their 
respective designs, I realized something that is obvious in hindsight 
-- game speed controls difficulty almost exclusively, at least in 
action games.  This means fighting games, shooters, platformers, you 
name it.  The slower the game is, the easier it is.

In fact, this is so obvious that several games have used slow-mo as a 
power up -- Max Payne 1/2, PoP, and Viewtiful Joe.

And yet games today still insist on using the most idiotic variables 
to control difficulty.  From the immensely stupid "number of saves" of 
Hitman 2, to the standard fare like "enemy damage", "hitpoints", 
"health and ammo availability", they never just adjust the speed of 
the game to match the response/reaction capabilities of a typical 
player.

And that's really what separates great action players from mediocre 
ones, their recognition, decision making and response.

The one game that could be improved the most with this is Madden 2004. 
 Instead of just affecting the speed of the game by, say, -40%, -25% 
and 0%, and keeping everything else constant, they tweak a bunch of 
variables that make it tough for a Rookie player to advance to 
All-Pro, because the crutches they had on Rookie disappear.

In fact, in the NFL it's even an adage that the difference between an 
experienced player and a rookie is that "the game slows down" for the 
experienced player.  This is also true of full contact sparring -- 
experienced fighters "see" the fight at a much slower rate than 
someone who isn't used to fighting.

Would Soul Calibur be more approachable if there was a novice setting 
that simply moved 25% slower?   I would argue "hell yes".

Obviously there are "fun factor" issues to consider, like obviously 
don't make it slow ALL the time, but the general notion is there.

-Hook

Re: [GD-Design] Ideas for a short game coding party

[nearaz <ne...@in...>]

First, thanks everyone for the replies!

> An apparently very successul idea for a new input gadget is
> used by Eyetoy for the PS2. It uses a simple camera to track
> player movements in  front of the camera, so the player has
> to perform all kinds of weird 
> stuff in front of the camera. Great party fun. :)

This could be done... In fact, IndieGameJam1 used similar one (your shadow is 
your input).

And in fact, we already have the technology required to extract human 
motions/poses from optical camera data. Too bad that this technology is 
priopretaty of the company I work at; and I don't have right to develop 
another one for non-competition reasons :( If not that, we would have used 
computer vision in the very first LTGameJam...


Ok, eventually the next LTGameJam will have some theme. I like the microphone 
input quite much!


Aras Pranckevicius aka NeARAZ
http://www.gim.ktu.lt/nesnausk/nearaz/

Re: [GD-Design] Ideas for a short game coding party

[Jan E. <ch...@in...>]

On Fri, 10 Oct 2003, Mickael Pointier wrote:

>Tom Forsyth wrote:
>> I like the idea of having a strange input. So you could say "your
>> only input is the microphone". Another nice one I like - "your only
>> input is mouse position" - i.e. no buttons!
>>
>> But it's not exactly a game "engine", really just a random
>> restriction to prod games in a different direction. But that's not
>> such a bad idea.
>
>Using micros at input has been done numerous time.

An apparently very successul idea for a new input gadget is used by Eyetoy
for the PS2. It uses a simple camera to track player movements in front of
the camera, so the player has to perform all kinds of weird stuff in front
of the camera. Great party fun. :)

-- 
   "I like the idea of democracy. You have to have someone everyone
       distrusts," said Brutha. "That way, everyone's happy."

                                        -- Terry Pratchett, Small Gods

RE: [GD-Design] Ideas for a short game coding party

[Tom F. <to...@mu...>]

You could build on previous engines. 100k units, but now your only input is
a single button! (and no copying stuff from WarioWare :-)

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Aras Pranckevicius [mailto:ne...@in...]
> Sent: 10 October 2003 13:34
> To: gam...@li...
> Subject: Re: [GD-Design] Ideas for a short game coding party
> 
> 
> > For the mic game idea, you should provide some basic signal
> > processing code, like FFTs, zero-crossing analysis, tone extraction
> > and tracking etc.
> 
> Yes - but that's only the sound part. I can also, say, assume 
> all games will
> be 2D, and provide some sprite rendering and related utils...
> 
> You see, not every participant (if any!) will be professional 
> developer, so
> it's best to provide as much pre-made utilities as possible 
> (even if most of
> them get unused in the actual game)...
> 
> 
> Aras Pranckevicius aka NeARAZ
> http://www.gim.ktu.lt/nesnausk/nearaz/
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=556
> 

RE: [GD-Design] Ideas for a short game coding party

[Jamie F. <ja...@qu...>]

but how many people would recognise them as signal processing basics, or
know what to do with them? I know i wouldn't :)

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Ivan-Assen Ivanov
Sent: 10 October 2003 13:23
To: gam...@li...
Subject: RE: [GD-Design] Ideas for a short game coding party


> > But it's not exactly a game "engine", really just a random
> restriction
> > to prod games in a different direction. But that's not such a bad
> > idea.
>
> Yes - that's exactly the remaining problem with both. It's a
> restriction/idea on games design, but some engine has to be
> made. There's not that much developers that can write a game
> in 2 days from scratch - hence some

For the mic game idea, you should provide some basic signal
processing code, like FFTs, zero-crossing analysis, tone extraction
and tracking etc.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556

Re: [GD-Design] Ideas for a short game coding party

[Aras P. <ne...@in...>]

> For the mic game idea, you should provide some basic signal
> processing code, like FFTs, zero-crossing analysis, tone extraction
> and tracking etc.

Yes - but that's only the sound part. I can also, say, assume all games will
be 2D, and provide some sprite rendering and related utils...

You see, not every participant (if any!) will be professional developer, so
it's best to provide as much pre-made utilities as possible (even if most of
them get unused in the actual game)...


Aras Pranckevicius aka NeARAZ
http://www.gim.ktu.lt/nesnausk/nearaz/

RE: [GD-Design] Ideas for a short game coding party

[Jamie F. <ja...@qu...>]

You could try picking up a free game engine, and let the people do what they
want. I hesitate to suggest our own :) (www.qubesoft.com :)

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Aras Pranckevicius
Sent: 10 October 2003 13:17
To: gam...@li...
Subject: Re: [GD-Design] Ideas for a short game coding party


> But it's not exactly a game "engine", really just a random restriction to
> prod games in a different direction. But that's not such a bad idea.

Yes - that's exactly the remaining problem with both. It's a
restriction/idea on games design, but some engine has to be made. There's
not that much developers that can write a game in 2 days from scratch -
hence some framework/utils/PreMadeCode is needed...


Aras Pranckevicius aka NeARAZ
http://www.gim.ktu.lt/nesnausk/nearaz/



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Gamedevlists-design mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=556

RE: [GD-Design] Ideas for a short game coding party

[Ivan-Assen I. <as...@ha...>]

> > But it's not exactly a game "engine", really just a random 
> restriction 
> > to prod games in a different direction. But that's not such a bad 
> > idea.
> 
> Yes - that's exactly the remaining problem with both. It's a 
> restriction/idea on games design, but some engine has to be 
> made. There's not that much developers that can write a game 
> in 2 days from scratch - hence some 

For the mic game idea, you should provide some basic signal
processing code, like FFTs, zero-crossing analysis, tone extraction
and tracking etc.

Re: [GD-Design] Ideas for a short game coding party

[Mickael P. <mpo...@ed...>]

Tom Forsyth wrote:
> I like the idea of having a strange input. So you could say "your
> only input is the microphone". Another nice one I like - "your only
> input is mouse position" - i.e. no buttons!
>
> But it's not exactly a game "engine", really just a random
> restriction to prod games in a different direction. But that's not
> such a bad idea.

Using micros at input has been done numerous time.

In last march at the EIL party (Error In Line) in Dresden (east germany) a
compo was using a pong engine and two microphones to control the bat
position using volume and frequency of signal :)

And in 1984 I had a breakout game on my oric that could be played using the
tape recorder: you just have to "hisssss" and "shhhhheeuuuu" into the built
in microphone to move the bat left and right ;)

But was funny =)

    Mike

Re: [GD-Design] Ideas for a short game coding party

[Aras P. <ne...@in...>]

> But it's not exactly a game "engine", really just a random restriction to
> prod games in a different direction. But that's not such a bad idea.

Yes - that's exactly the remaining problem with both. It's a
restriction/idea on games design, but some engine has to be made. There's
not that much developers that can write a game in 2 days from scratch -
hence some framework/utils/PreMadeCode is needed...


Aras Pranckevicius aka NeARAZ
http://www.gim.ktu.lt/nesnausk/nearaz/

RE: [GD-Design] Ideas for a short game coding party

[Tom F. <to...@mu...>]

I like the idea of having a strange input. So you could say "your only input
is the microphone". Another nice one I like - "your only input is mouse
position" - i.e. no buttons!

But it's not exactly a game "engine", really just a random restriction to
prod games in a different direction. But that's not such a bad idea.

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Aras Pranckevicius [mailto:ne...@in...]
> Sent: 10 October 2003 12:10
> To: gam...@li...
> Subject: [GD-Design] Ideas for a short game coding party
> 
> 
> Hi,
> 
> I'm planning the next LTGameJam party, and some interesting 
> ideas for the
> games/engine are needed. We've though some, but more would be 
> welcome :)
> 
> Short description of the party: LTGameJam 
> (http://jammy.sourceforge.net);
> which is in turn similar to IndieGameJam 
> (http://www.indiegamejam.com/), is
> a short game development event. Someone prepares a small 
> specific "engine",
> invites a bunch of game programmers/designers, and over two 
> days they try to
> make small games. Of course, two days to study the engine and 
> write a game
> is a very short time, so main focus should be on original 
> ideas, etc. We've
> made two Jams already, first being direct IGJ0 clone - "100k 
> game units!",
> second being "physics, cars and stuff". Now, it's time to 
> think of the idea
> for the next one...
> 
> If anyone has a crazy idea and is willing to share it, you're 
> more than
> welcome. Anyone willing to participate is welcome also, though so far
> LTGameJam was in Lithuania (hence 'LT'), and only Lithuanian 
> programmers
> were participating (but noone enforces that :)).
> 
> Here's a short list of ideas currently "in processing":
> 
> 1) Old maze-like games. This is simple and easy, but not very 
> original or
> interesting. Basically, it's 2D maze at logic level, with 
> engine providing
> pathfinding, collision, entities, particle effects, camera etc. The
> participants take this "2D maze" thingie and write some game logic.
> 
> 2) "guess the packet" network games - there's a server that 
> basically just
> broadcasts packets. And there are clients. The twist is, that 
> while client
> games use the same server and same physical packet structure, 
> they don't
> know the packet semantics. So, every games interprets the 
> packets in it's
> own way. To keep at least some control, something is known about the
> packets - eg. a packet is bunch of bytes with known small 
> range. This could
> turn out totally unplayable, though. The problem is, what the 
> engine should
> provide, except networking? Possibly some 2D games stuff 
> (sprite renderer,
> 2D pathfinding, etc.)?
> 
> 3) "microphone is the input". Nothing much more is known, 
> except that, well,
> microphone is your input device :) The problems are the same 
> as 2) - what to
> provide except the input?
> 
> 4) "vehicle building". Basically, you don't write a game, but 
> rather code a
> vehicle - assemble it from pre-made components, add input processing,
> auto-aiming, whatever. In the end you end up with vehicle 
> "plugin" that is
> plugged into premade networked game. You don't write AI for 
> it - it will be
> controlled by human. This idea is a strange one, as it's not "game
> programming" anymore...
> 
> 
> 
> Aras Pranckevicius aka NeARAZ
> http://www.gim.ktu.lt/nesnausk/nearaz/
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=556
> 

[GD-Design] Ideas for a short game coding party

[Aras P. <ne...@in...>]

Hi,

I'm planning the next LTGameJam party, and some interesting ideas for the
games/engine are needed. We've though some, but more would be welcome :)

Short description of the party: LTGameJam (http://jammy.sourceforge.net);
which is in turn similar to IndieGameJam (http://www.indiegamejam.com/), is
a short game development event. Someone prepares a small specific "engine",
invites a bunch of game programmers/designers, and over two days they try to
make small games. Of course, two days to study the engine and write a game
is a very short time, so main focus should be on original ideas, etc. We've
made two Jams already, first being direct IGJ0 clone - "100k game units!",
second being "physics, cars and stuff". Now, it's time to think of the idea
for the next one...

If anyone has a crazy idea and is willing to share it, you're more than
welcome. Anyone willing to participate is welcome also, though so far
LTGameJam was in Lithuania (hence 'LT'), and only Lithuanian programmers
were participating (but noone enforces that :)).

Here's a short list of ideas currently "in processing":

1) Old maze-like games. This is simple and easy, but not very original or
interesting. Basically, it's 2D maze at logic level, with engine providing
pathfinding, collision, entities, particle effects, camera etc. The
participants take this "2D maze" thingie and write some game logic.

2) "guess the packet" network games - there's a server that basically just
broadcasts packets. And there are clients. The twist is, that while client
games use the same server and same physical packet structure, they don't
know the packet semantics. So, every games interprets the packets in it's
own way. To keep at least some control, something is known about the
packets - eg. a packet is bunch of bytes with known small range. This could
turn out totally unplayable, though. The problem is, what the engine should
provide, except networking? Possibly some 2D games stuff (sprite renderer,
2D pathfinding, etc.)?

3) "microphone is the input". Nothing much more is known, except that, well,
microphone is your input device :) The problems are the same as 2) - what to
provide except the input?

4) "vehicle building". Basically, you don't write a game, but rather code a
vehicle - assemble it from pre-made components, add input processing,
auto-aiming, whatever. In the end you end up with vehicle "plugin" that is
plugged into premade networked game. You don't write AI for it - it will be
controlled by human. This idea is a strange one, as it's not "game
programming" anymore...



Aras Pranckevicius aka NeARAZ
http://www.gim.ktu.lt/nesnausk/nearaz/

Re: [GD-Design] demo vs complete game

[Mike W. <mi...@ge...>]

one game demo in particular that has struck me as an example of this 
type of feature limitation is the Midnight Club 2 demo (very cool).  The 
demo has a number of cars & types of races etc that you can play, but 
the demo doesn't save any info you set while playing.

if you want to tweak your in-game settings, change the color of your 
car, and other options (whether you want music playing or not, controls 
etc), you CAN, but the demo doesn't save it once you quit.

as well, the demo limits you to a set number of powerups you can achieve 
(nitro in this case).  i can see this being a major motivation for 
buying the full game.

actually most of the suggestions that have been brought up here were 
demonstrated in this demo - having non-skippable intro cinematics, 
limiting what the game saves between sessions, etc...but the demo still 
gives the player access to every major feature in the game - online 
play, different types of races, etc but only gives the player, 
effectively ONE of each type of gameplay style to sample - if you finish 
the one race & win, that's it, you don't pregress, etc...

not to mention the game itself IS the biggest draw to wanting to buy the 
game.  no annoying nag's, no blasting the user with 15 splashscreens on 
exiting the game, etc...

hasn't stopped me from playing the demo nonstop for a week, and i likely 
WILL buy the complete game as a result (need more nitro for my stupid 
car if i'm gonna win these races ;P )

anyways
mike w
www.gekidodesigns.com

Ben Hawes wrote:

>>PS So yes, the second and subsequent times are still as free as the first
>>one, but you have to do all of the setup and config work again. You sort of
>>expect to do that the first time, so the I guess the first time is still
>>effectively cheaper.
>>    
>>
>
>Ugh, no. Speaking from a user perspective, if a game did that to me on the demo, I'd decide a sadist like that didn't deserve my money :P
>This is going to be a personal taste issue in the end, I suspect, but any drastic limits on a demo put me off very quickly. It gives me the impression the developers don't deem me "worthy" to handle their game unless I pay them money...I know that seems melodramatic, but I hopefully it makes my point.
>
>Ideally, a demo should be a good game in its own right, A short game, devoid of some small niceties (like hi-scores, perhaps save games, depending on the game), but a "proper" game nonetheless.
>
>[ cruise / casual-tempest.net / transference.org ]
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
>at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
>_______________________________________________
>Gamedevlists-design mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_idU6
>
>
>  
>

Re: [GD-Design] demo vs complete game

[Ben H. <cr...@ca...>]

>PS So yes, the second and subsequent times are still as free as=
 the first
>one, but you have to do all of the setup and config work again.=
 You sort of
>expect to do that the first time, so the I guess the first time=
 is still
>effectively cheaper.

Ugh, no. Speaking from a user perspective, if a game did that to=
 me on the demo, I'd decide a sadist like that didn't deserve my=
 money :P
This is going to be a personal taste issue in the end, I suspect,=
 but any drastic limits on a demo put me off very quickly. It=
 gives me the impression the developers don't deem me "worthy" to=
 handle their game unless I pay them money...I know that seems=
 melodramatic, but I hopefully it makes my point.

Ideally, a demo should be a good game in its own right, A short=
 game, devoid of some small niceties (like hi-scores, perhaps=
 save games, depending on the game), but a "proper" game=
 nonetheless.

[ cruise / casual-tempest.net / transference.org ]

Re: [GD-Design] demo vs complete game

[<phi...@pl...>]

> > I believe this is a good general principle. If you want to play it a
second
> > time (as in, a second session, not a second go), you should probably
buy
> > it.
> >
> > The first time is free.

> That way, you can never show the game to a friend that is on visit
though.
> People will delete the game instead. Thats a visibility potential you
> loose there.

Nah, I'm not saying you can only play it once, that would be fairly dumb.
What I'm actually proposing is that the demo doesn't store any information
between sessions. No settings, preferences, hi-score tables, save games,
progress, stats, or even a flag to say you've played it before. On quitting
the session, you should show an easily quittable slideshow of features in
the full version, and a clickable link to a website where you can buy it.

Ideally it should be packaged as a single file that can be run from
anywhere. If you need to unpack data, do it to memory, not the disk. If you
do insist on crapping all over the users hard drive, then your uninstall
routine bloody well better work. The single file encourages secondary
distribution. If your friend comes over, plays the demo, and likes it, you
always have the distribution file to copy, because it is the game. Or you
can mail it to him, or whatever.


1: Do not piss off potential customers.
2: Make it easy for them to give you money.
3: Your game should be the best advertisment for your game.

I'd also reccomend using something like PayPal. Their interface is scarily
easy to use from a customers perspective. I've stopped halfway through
buying cheap stuff just because I had to type in my address, and CC number.

Cheers,
Phil

PS So yes, the second and subsequent times are still as free as the first
one, but you have to do all of the setup and config work again. You sort of
expect to do that the first time, so the I guess the first time is still
effectively cheaper.

Re: [GD-Design] demo vs complete game

[<ma...@ch...>]

On Mon, 25 Aug 2003 phi...@pl... wrote:


> anyway. But
> > if they play the game a _second_ time... then it's worth telling them
> about
> > the cool things in the full version.
> 
> I believe this is a good general principle. If you want to play it a second
> time (as in, a second session, not a second go), you should probably buy
> it.
> 
> The first time is free.

That way, you can never show the game to a friend that is on visit though.

People will delete the game instead. Thats a visibility potential you 
loose there.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
Being comfortable with your beliefs is like being comfortable with
syphilis. Belief is a sort of disease that comes from the ego's need to
protect itself from reality. 
                                       - /. comment on 2002.05.01

Re: [GD-Design] demo vs complete game

[<phi...@pl...>]

> > - Offering new features: new levels, and new options (fullscreen,
> > highscores, etc)

> Additional content is always a good thing.  I would be leery of making
> fullscreen a registered-only version, since it affects satisfaction of
> the demo version.  Highscores are similar in that respect.

I'd agree that full screen must be in the demo. However, hi-scores, you
could leave out. Or rather, you could make it so that the demo version
doesn't save anything, and completely resets when you quit the application.


> If they only play the demo once, they weren't going to buy the full game
anyway. But
> if they play the game a _second_ time... then it's worth telling them
about
> the cool things in the full version.

I believe this is a good general principle. If you want to play it a second
time (as in, a second session, not a second go), you should probably buy
it.

The first time is free.

Cheers,
Phil

RE: [GD-Design] demo vs complete game

[<phi...@pl...>]

> On Wed, 20 Aug 2003 15:56:31 +0100, Tom Forsyth <to...@mu...>
wrote:
> > Microsoft MVP
> Is this a required disclosure? Like "registered sex offender"? ;-)
> If so, just to be fair:
> George Warner - Macintosh bigot. ;-)

Eurgh! I know you're just jesting, but can we please leave that one alone?
I still have the scars... ;)

Cheers,
Phil (ex-PC and ex-Mac developer)

RE: [GD-Design] demo vs complete game

[Tom F. <to...@mu...>]

It just means that if people have problems with DirectX then I'm one
possible point of call for support or bug reports. At the very least I can
point them in the direction of Someone Who Knows.

Oh yeah, and they send me free stuff, so I figure a mention in the .sig is
fair trade. :-)

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: George Warner [mailto:ge...@ap...]
> Sent: 22 August 2003 18:19
> To: gam...@li...
> Cc: Tom Forsyth
> Subject: RE: [GD-Design] demo vs complete game
> 
> 
> On Wed, 20 Aug 2003 15:56:31 +0100, Tom Forsyth 
> <to...@mu...> wrote:
> > Microsoft MVP
> 
> Is this a required disclosure? Like "registered sex offender"? ;-)
> 
> If so, just to be fair:
> 
> George Warner - Macintosh bigot. ;-)
> 
> -- 
> Enjoy,
> George Warner,
> Schizophrenic Optimization Scientists
> Apple Developer Technical Support (DTS)
> 

RE: [GD-Design] demo vs complete game

[George W. <ge...@ap...>]

On Wed, 20 Aug 2003 15:56:31 +0100, Tom Forsyth <to...@mu...> wrote:
> Microsoft MVP

Is this a required disclosure? Like "registered sex offender"? ;-)

If so, just to be fair:

George Warner - Macintosh bigot. ;-)

-- 
Enjoy,
George Warner,
Schizophrenic Optimization Scientists
Apple Developer Technical Support (DTS)

RE: [GD-Design] demo vs complete game

[Tom F. <to...@mu...>]

Nah - whole different kettle of fish actually writing a game - any =
game.
Renderers seem like rocket-science, but they're really not. You have a =
known
problem and known tools and you solve that problem. Writing a game on =
the
other hand - you've got to somehow capture this thing called "fun" and =
nail
it to the monitor. Very tricky.

We had a work-experience kid in here for a week a while ago. He =
reckoned he
was pretty cool - knew C++ really well, had written lots of assembly
software 3D renderers and so on. Good coder. So I got him doing PacMan. =
"And
what shall I do for the rest of the week" he said. Bah - took him the =
whole
week to do a decent version. I was impressed that he did actually =
finish it
in a week, which shows that he's a good coder and all, but still... =
games
are hard!

Of course now you can port your puzzle game to 3D and so on, and as =
every
publisher knows that will make it three times as fun! Right? :-)

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Ignacio Casta=F1o [mailto:cas...@ya...]
> Sent: 21 August 2003 18:03
> To: gam...@li...
> Subject: Re: [GD-Design] demo vs complete game
>=20
>=20
>=20
> Thanks for the advices!
>=20
>=20
> Tom Forsyth wrote:
> > *cough* need any beta-testers? *cough* :-)
>=20
> Yes of course!
>=20
> After writting 3d engines, I feel somewhat embarrased=20
> writting a puzzle
> game, but I wanted to try that out. I like the game I've=20
> done, but I don't
> really know if other people will like it. So any advices=20
> would be highly
> appreciated. The game should be finished around the next week, so =
I'll
> contact you privately if you are still interested.
>=20
>=20
> --
> Ignacio Casta=F1o
> cas...@ya...
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a=20
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click=20
> here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D556
>=20

Re: [GD-Design] demo vs complete game

[<cas...@ya...>]

Thanks for the advices!


Tom Forsyth wrote:
> *cough* need any beta-testers? *cough* :-)

Yes of course!

After writting 3d engines, I feel somewhat embarrased writting a puzzle
game, but I wanted to try that out. I like the game I've done, but I don't
really know if other people will like it. So any advices would be highly
appreciated. The game should be finished around the next week, so I'll
contact you privately if you are still interested.


--
Ignacio Castaño
cas...@ya...