V0.5 brainstorm thread

V0.5 brainstorm thread

Postby odamite » 26 Jul 2012, 18:42

Hello,

I really like the idea of achievement system but I think that it shouldn't be our main goal for 0.5. The biggest thing that should be improved is the addon system to allow players to upload and download addons easily.

Some other features for the future:
  • Own themes for levelpacks (includes graphics, music and sound). This brings nice variation to the game.
  • Decoration blocks for background which helps creating different environments.
  • New icy blocks with little friction.
  • Particle engine. This might be used for backgrounds (e.g. snowflakes) or other effects (e.g. picking up collectiable)
  • Random or predefined scrolling level for main menu background.
  • Allow theming menu elements. done!
  • Layered backgrounds with parallax scrolling: layers scroll with different speeds creating a nice effect. Already done...
  • Touch screen controls.
  • Undo/redo for level editor.
acme_pjz {l Wrote}:* Full OpenGL renderer which supports fast image rotating and zooming

I think that we shouldn't handle that ourselves. SDL2.0 (or 1.3) brings hardware accelerated graphics and it seems that its release isn't far (source). However SDL2.0 breaks API compability with SDL1.2. So we need to choose which one to use. The problem is that SDL2.0 will be much worse supported at first so we need carefully think everything before doing anything.

acme_pjz {l Wrote}:* Maybe some more new block types? For example change gravity direction (Rotating the level completely, needs fast image rotating), and collectible power-ups...

We could add new blocks and items but at the same time we need to keep the gameplay as simple as possible.
Last edited by odamite on 01 Aug 2012, 08:43, edited 1 time in total.
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: [IDEA] Achievement System?

Postby Edward_Lii » 26 Jul 2012, 20:23

Hello,

acme_pjz {l Wrote}:Roadmap for V0.5 is OK, but for further versions, I'm not sure :| It depends...

The roadmap doesn't have to be detailed and is by no means final, I just think it's best to have a general idea of what we want.
A bit like Supertuxkart has done (http://supertuxkart.sourceforge.net/Milestones).

acme_pjz {l Wrote}:* Full OpenGL renderer which supports fast image rotating and zooming

I agree a full/proper openGL renderer couldn't hurt, but I'm not sure about the rotating and zooming. :think:
It would allow some fancy effects, but IMHO it should be optional so that the game can still be played with software rendering for mobile platforms, etc...

odamite {l Wrote}:We could add new blocks and items but at the same time we need to keep the gameplay as simple as possible.

I fear the same, adding new blocks will in most cases feel bloated or out of place not fitting in the style of the game.

odamite {l Wrote}:Own themes for levelpacks (includes graphics, music and sound). This brings nice variation to the game.

This will most definitely give the game a polished feel, the only downside is that it will raise the bar for creating content.
Instead of making the levels or a theme one is "forced to" create a theme, sfx, music and the levels.

I think we should try to have a few default themes (including sfx and music) in different styles that levelmakers can use.
This will make sure that creating (level) content is as simple as designing levels and choosing a theme, it should still be possible to create their own theme, though.

odamite {l Wrote}:Random or predefined scrolling level for main menu background.

I don't quite like that, it will be a bit busy. I like how the menu is quite calm at the moment. ;)
Wouldn't it be better if we had a few cloud layers that scroll (very) slowly?

odamite {l Wrote}:Allow theming menu elements.

A theming system for the GUI can be done but isn't mandatory IMHO.
It gave me a nice idea, though, what if a levelpack can define the background, level and levellocked images of the levelselect screen?

odamite {l Wrote}:Layered backgrounds with parallax scrolling: layers scroll with different speeds creating a nice effect.

Already implemented. :cool:
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: [IDEA] Achievement System?

Postby leovilok » 26 Jul 2012, 21:15

Hello,
We could add new blocks and items but at the same time we need to keep the gameplay as simple as possible.


I fear the same, adding new blocks will in most cases feel bloated or out of place not fitting in the style of the game.

Allways the same problem, people have nice block ideas but we don't want a bloated game ... what if there was a way of creating scripted block in addons level(packs) ? :think: :shock: but the huge amount of work will probably prevent you from doing that ...

It would allow some fancy effects, but IMHO it should be optional so that the game can still be played with software rendering for mobile platforms, etc...
Yes, I think that M&MS should keep (optionnal) software rendering : at the moment the game is very light and works on nearly everything including dinosaur computers ... and some of these platforms doesn't have (proper) graphical accel.

Own themes for levelpacks (includes graphics, music and sound). This brings nice variation to the game.


This will most definitely give the game a polished feel, the only downside is that it will raise the bar for creating content.
Instead of making the levels or a theme one is "forced to" create a theme, sfx, music and the levels.

If the default fallback theme stays I think there is no problem.

odamite {l Wrote}:Random or predefined scrolling level for main menu background.

What about radom/infinite levels to play (as in frogatto), wich would be more skill/arcade oriented than regular levels? ( :think: still dreaming ...)

Edward_Lii {l Wrote}:It gave me a nice idea, though, what if a levelpack can define the background, level and levellocked images of the levelselect screen?

:heart:I like that
Edward_Lii {l Wrote}:Wouldn't it be better if we had a few cloud layers that scroll (very) slowly?

:heart: That too
Edward_Lii {l Wrote}:
odamite {l Wrote}:Layered backgrounds with parallax scrolling: layers scroll with different speeds creating a nice effect.

Already implemented. :cool:
:heart: :D
leovilok
 
Posts: 32
Joined: 22 Oct 2011, 20:22

Re: [IDEA] Achievement System?

Postby Edward_Lii » 27 Jul 2012, 05:52

Hello,

leovilok {l Wrote}:Allways the same problem, people have nice block ideas but we don't want a bloated game ... what if there was a way of creating scripted block in addons level(packs) ? :think: :shock: but the huge amount of work will probably prevent you from doing that ...

I've thought about scripting support before and although I see some uses for it I'm afraid it will be misused.
Take for example XMoto, they have scripting support in their levels and there are some fun/impressive levels made thanks to that.
But there are also a lot of levels that are unclear, they change certain things without giving any graphical feedback (eg )
(And it's a lot of work to implement. :p )

leovilok {l Wrote}:If the default fallback theme stays I think there is no problem.

That's true, I was just suggesting we have 'a few' default themes.
This way levelmakers can have some variety in their levelpacks. ;)

leovilok {l Wrote}:What about radom/infinite levels to play (as in frogatto), wich would be more skill/arcade oriented than regular levels? ( :think: still dreaming ...)

Interesting idea, not sure it fits in, if the infinite levels auto-scrolls it will be a pain to move your shadow along.
Playing around with (semi-)random level generation could be fun, but doesn't have a high priority.

One thing I would like to see is a solution for the borders of (small) levels.
Now we have multiple resolution support some levels of the Castle Rescue levelpack look a lot less nice.
A castle wall suddenly stopping. If we add support for a repeating part that stretches to the edge of the level it will still look good when the screen is larger than the level?
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: [IDEA] Achievement System?

Postby acme_pjz » 27 Jul 2012, 08:58

Hi everyone,

odamite {l Wrote}:I really like the idea of achievement system but I think that it shouldn't be our main goal for 0.5.


Well, different developers has different interests. Anyway I'll try to implement it :)

odamite {l Wrote}:New icy blocks with little friction.


Anyone has any ideas about its physics properties?

Edward_Lii {l Wrote}:I agree a full/proper openGL renderer couldn't hurt, but I'm not sure about the rotating and zooming. :think:
It would allow some fancy effects, but IMHO it should be optional so that the game can still be played with software rendering for mobile platforms, etc...


Well, in my classmate's old computer Me and My Shadow runs slowly, but SuperTux 0.3 runs flawlessly... Maybe because SuperTux 0.3 is OpenGL accelerated?
As for mobile platforms, if it supports C/C++ mostly it supports OpenGL ES too (correct me if I'm wrong)

leovilok {l Wrote}:What about radom/infinite levels to play (as in frogatto), wich would be more skill/arcade oriented than regular levels? ( :think: still dreaming ...)


It's not so hard, we need two following features:

* Auto-scrolling screen
* Semi-random level (simply randomly combine some predefined patterns)

Edward_Lii {l Wrote}:Playing around with (semi-)random level generation could be fun, but doesn't have a high priority.


Well, it's very hard to implement well even in a simple puzzle game, for example my TurningSquare/TurningPolyhedron (Bloxorz clone) really have a genetic-algorithm based true random level generator which can produce great results. But as for Me and My Shadow, I'm afraid that the game rule is too complex to write a good random level generator :|

Edward_Lii {l Wrote}:One thing I would like to see is a solution for the borders of (small) levels.
Now we have multiple resolution support some levels of the Castle Rescue levelpack look a lot less nice.
A castle wall suddenly stopping. If we add support for a repeating part that stretches to the edge of the level it will still look good when the screen is larger than the level?


How about hit test problem?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: [IDEA] Achievement System?

Postby odamite » 27 Jul 2012, 11:13

Hello,

One thing that we forgot is records (thanks to MCMic on IRC). We should have a simple way to play and manage them. First step would be implementing a command line parameter but I think that a GUI is also required. We need to think things like how to record specific game and then play and share it. :)

Edward_Lii {l Wrote}:One thing I would like to see is a solution for the borders of (small) levels.
Now we have multiple resolution support some levels of the Castle Rescue levelpack look a lot less nice.
A castle wall suddenly stopping. If we add support for a repeating part that stretches to the edge of the level it will still look good when the screen is larger than the level?

This would work for closed walls and ceilings and maybe open floors but not with open walls creating a new corridor or plane to walk on. So these extra blocks should be visually different and non-walkable and of course optional since they doesn't fit every level. :D
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: [IDEA] Achievement System?

Postby odamite » 27 Jul 2012, 13:57

Edward_Lii {l Wrote}:A theming system for the GUI can be done but isn't mandatory IMHO.
It gave me a nice idea, though, what if a levelpack can define the background, level and levellocked images of the levelselect screen?

This is what I mostly had in mind. I've started implementing it in SVN r.483. :) But this brings some problems. :(

Dark background won't work because it hides most of the black GUI elements. So we need to make them themable. I'm thinking that we could have two predefined themes for them: light (black GUI elements) and dark (white elements). The theme maker could could choose either one. We don't need a very complicated system where one can choose every color. What do you think?
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: [IDEA] Achievement System?

Postby Edward_Lii » 28 Jul 2012, 15:14

Hello odamite,

odamite {l Wrote}:Dark background won't work because it hides most of the black GUI elements. So we need to make them themable. I'm thinking that we could have two predefined themes for them: light (black GUI elements) and dark (white elements). The theme maker could could choose either one. We don't need a very complicated system where one can choose every color. What do you think?

The way I look at it is that we need to allow the themes to theme the GUI/menu.
This means they can define the menu background and the level(locked) images opposed to using the actual theme background and block images.

So we kind of move the problem to the theme maker(s), maintaining two sets of GUI/menu themes is IMHO not desirable.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby BioHazardX » 30 Jul 2012, 19:23

I want to see more types of traps, like the twomps and the balls'n'chains in super mario bros, or mad chainsaws like super meat boy style!! (are there bad ideas? :| ).

And of course, more levels please...
SURVIVAL STRATEGY!
User avatar
BioHazardX
 
Posts: 183
Joined: 07 Jan 2012, 12:03
Location: from the 90's

Re: V0.5 brainstorm thread

Postby odamite » 30 Jul 2012, 21:30

Hello,

BioHazardX {l Wrote}:I want to see more types of traps, like the twomps and the balls'n'chains in super mario bros, or mad chainsaws like super meat boy style!! (are there bad ideas? :| ).

They aren't bad ideas at all. Something like that can be already achieved with (moving) spikes so it's more like about the graphics. Luckily we're planning to create a easy way to bundle whole or partial themes with a levelpack.

BioHazardX {l Wrote}:And of course, more levels please...

You can always lauch the game and press Map Editor. :D
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: V0.5 brainstorm thread

Postby acme_pjz » 31 Jul 2012, 07:57

BioHazardX {l Wrote}:I want to see more types of traps, like the twomps and the balls'n'chains in super mario bros, or mad chainsaws like super meat boy style!!


Personally, I don't really like this idea :| After all this is a puzzle game, not action adventure... In order to implement balls'n'chains we need a block with round trajectory :| I'm not sure I'd like to implement this... Of course, in the future versions with script support you can do this easily ;)
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 brainstorm thread

Postby Edward_Lii » 31 Jul 2012, 17:18

Hello,

acme_pjz {l Wrote}:Personally, I don't really like this idea :| After all this is a puzzle game, not action adventure... In order to implement balls'n'chains we need a block with round trajectory :| I'm not sure I'd like to implement this... Of course, in the future versions with script support you can do this easily ;)

I agree, our primary focus should be the puzzle aspect, but a bit of variation in the way the player dies couldn't hurt. ;)
Such things should be mostly visual IMHO.

One thing we should change/extend is the behaviour of moving blocks and switches/triggers.
Imagine we want a door that is only open when either the player or the shadow stands on a button.
The button should be set to Toggle and when someone steps on it the moving block should follow its path to the end.
When the button is released the moving block should follow the path backwards.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby acme_pjz » 01 Aug 2012, 07:25

Edward_Lii {l Wrote}:One thing we should change/extend is the behaviour of moving blocks and switches/triggers.
Imagine we want a door that is only open when either the player or the shadow stands on a button.
The button should be set to Toggle and when someone steps on it the moving block should follow its path to the end.
When the button is released the moving block should follow the path backwards.


I don't know :think: maybe we should make a simple document first?

And I have a crazy idea: Moving blocks with spline trajectory?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 brainstorm thread

Postby bgalon_2000 » 28 Sep 2012, 14:09

How about "Scroll bar for the toolbox window in the level editor"?

Just to allow displaying all the possible tiles in the toolbox window while maintaning 800x600 support....
bgalon_2000
 
Posts: 15
Joined: 26 Sep 2012, 16:40

Re: V0.5 brainstorm thread

Postby acme_pjz » 29 Sep 2012, 05:08

bgalon_2000 {l Wrote}:How about "Scroll bar for the toolbox window in the level editor"?

Just to allow displaying all the possible tiles in the toolbox window while maintaning 800x600 support....


Possible ;) PS: You can scroll your mousewheel when mouse in toolbox window...
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 brainstorm thread

Postby Edward_Lii » 06 Oct 2012, 17:09

Hello all,

I have implemented a new record mode, it's in svn revision 516.
Basically instead of pressing space repeatedly the player holds down space.
While holding down space, the moves of the player will be recorded.
Once the player lets go of the space bar the recording stops and the shadow will mimic it.

To test it for yourself run meandmyshadow using the following command:
{l Code}: {l Select All Code}
./meandmyshadow -set quickrecord 1

Or set quickrecord to 1 in the config file.

One downside I noticed is that on my keyboard space, left arrow and up arrow don't get along that well.
But overall I think it works quite well and we could make the record mode configurable from within the game.

Feedback is welcome! ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby KroArtem » 06 Oct 2012, 22:14

Hello,
haven't checked it yet but the idea of holding a key is not so good in my opinion. Firstly, as you have already mentioned there are some "locks" with 3 buttons pressed at the same time. As for me, I know this will happen too.
Also it's not cool if you're trying to beat yourself and complete a level e.g. in 1 record and suddenly stops pressing on the button -> fails to beat your record. Just my 2 cents.
KroArtem
 
Posts: 375
Joined: 26 Aug 2010, 19:04

Re: V0.5 brainstorm thread

Postby Edward_Lii » 07 Oct 2012, 05:42

Hello KroArtem,

KroArtem {l Wrote}:haven't checked it yet but the idea of holding a key is not so good in my opinion. Firstly, as you have already mentioned there are some "locks" with 3 buttons pressed at the same time. As for me, I know this will happen too.

There are ways to avoid this, the most obvious one is to remap one of the keybindings.
In this case the record button would be the most logical one to change, a quick test shows that for me setting it to 'V' solves it.

Another thing to keep in mind is that the player could be using a joystick.
In such case the "locking" of keys should not occur.
Besides it might be easier for the joystick user to hold down the record button instead of pressing it.

KroArtem {l Wrote}:Also it's not cool if you're trying to beat yourself and complete a level e.g. in 1 record and suddenly stops pressing on the button -> fails to beat your record. Just my 2 cents.

True, but it's also annoying if you try to beat the time for a level and you don't press space hard enough, the recording won't start. ;)
Both things can happen, letting go of a button you needed to hold or semi-pressing a button.
I think we can neglect that, it shouldn't happen to often, otherwise something is wrong with your keyboard. :p

I think it's best to make this mode configurable, but keep the old one as default.

Anyway, thanks for your feedback. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby acme_pjz » 07 Oct 2012, 08:08

Hi Edward_Lii,

Personally I don't like the new recording mode :| I'll check if it breaks the level replay feature (probably it really breaks) :think:
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 665
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

Re: V0.5 brainstorm thread

Postby Edward_Lii » 07 Oct 2012, 08:15

Hello acme_pjz,

acme_pjz {l Wrote}:Personally I don't like the new recording mode :| I'll check if it breaks the level replay feature (probably it really breaks) :think:

It shouldn't break the replay function, it runs the same code as when the player presses the space bar again.
I also tested it with the cancel recording key and so far, so good. :)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby odamite » 07 Oct 2012, 14:33

Hello Edward_Lii,

Nice work! I can confirm that it works perfectly with a joystick/gamepad without any problems. However I experienced locking keys while using a keyboard and reassigning keys didn't fix the problems. :think: In conclusion, I still prefer the old way to the new mostly because I'm just used to the traditional way. :D

But it's good that it's configurable. Should we have a option in the Settings screen for it? If so, there isn't much space left there at 800x600 so maybe we should put the settings in a scroll area. It's also smart thing to do because there may be other options to add there in the future. :)
User avatar
odamite
 
Posts: 166
Joined: 16 Jan 2012, 16:28

Re: V0.5 brainstorm thread

Postby bgalon_2000 » 09 Oct 2012, 15:41

Hi all.


I’ve been designing levels for about a week now, playing with the different features of the editor. Although it has its little quirks, I think it’s quite powerful for what it supposes to deliver.

As a level designer, there is one feature I believe will open up a whole raft of new possibilities for interesting puzzles. At the moment, you can focus (using the tab key) on the screen around the player or its shadow. This limits the scope of the puzzles. I would like to be able to create levers and switches that move things outside the view of the player – or include puzzle that require a correct path of movement to different areas outside the players view.

But from a player prospective – if they can not see the whole puzzle world before trying to solve the puzzle – such puzzles are unfair and frustrating. What I think really required is the ability to either move the camera around without moving the players (much like the arrow keys in the editor) or the ability of seeing “sized down” version of the whole puzzle world for review.

Is this too confusing? If it is – I can design a few puzzles that demonstrate the issue.

bgalon
bgalon_2000
 
Posts: 15
Joined: 26 Sep 2012, 16:40

Re: V0.5 brainstorm thread

Postby ctdabomb » 09 Oct 2012, 16:59

yes, that was confusing ;) levels demonstrating this would be nice.
Some people are like slinkies... not really good for anything, but you still can't help smiling when you shove them down the stairs.
ctdabomb
 
Posts: 1075
Joined: 13 Dec 2011, 21:21
Location: halfway there

Re: V0.5 brainstorm thread

Postby Edward_Lii » 09 Oct 2012, 17:10

Hello bgalon_2000,

bgalon_2000 {l Wrote}:As a level designer, there is one feature I believe will open up a whole raft of new possibilities for interesting puzzles. At the moment, you can focus (using the tab key) on the screen around the player or its shadow. This limits the scope of the puzzles. I would like to be able to create levers and switches that move things outside the view of the player – or include puzzle that require a correct path of movement to different areas outside the players view.

But from a player prospective – if they can not see the whole puzzle world before trying to solve the puzzle – such puzzles are unfair and frustrating. What I think really required is the ability to either move the camera around without moving the players (much like the arrow keys in the editor) or the ability of seeing “sized down” version of the whole puzzle world for review.

Is this too confusing? If it is – I can design a few puzzles that demonstrate the issue.

I understand what you mean and I agree that there needs to be a way for the user to see/view the whole level without "visiting" it with either the player or the shadow.
The only problem is how to implement this, it must be quite straightforward and easy to use.
Using the mouse is out of the question, what I was thinking of is that if the user holds tab (or a different key) he can use the arrow keys to move the camera.
Once the user lets go of that key the camera will focus on the player or the shadow again.

Is this the way to go, or does anyway have a better?

Suggestions are welcome. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 777
Joined: 20 Dec 2010, 16:46

Re: V0.5 brainstorm thread

Postby bgalon_2000 » 10 Oct 2012, 00:12

Edward_Lii {l Wrote}:Hello bgalon_2000,

bgalon_2000 {l Wrote}:As a level designer, there is one feature I believe will open up a whole raft of new possibilities for interesting puzzles. At the moment, you can focus (using the tab key) on the screen around the player or its shadow. This limits the scope of the puzzles. I would like to be able to create levers and switches that move things outside the view of the player – or include puzzle that require a correct path of movement to different areas outside the players view.

But from a player prospective – if they can not see the whole puzzle world before trying to solve the puzzle – such puzzles are unfair and frustrating. What I think really required is the ability to either move the camera around without moving the players (much like the arrow keys in the editor) or the ability of seeing “sized down” version of the whole puzzle world for review.

Is this too confusing? If it is – I can design a few puzzles that demonstrate the issue.

I understand what you mean and I agree that there needs to be a way for the user to see/view the whole level without "visiting" it with either the player or the shadow.
The only problem is how to implement this, it must be quite straightforward and easy to use.
Using the mouse is out of the question, what I was thinking of is that if the user holds tab (or a different key) he can use the arrow keys to move the camera.
Once the user lets go of that key the camera will focus on the player or the shadow again.

Is this the way to go, or does anyway have a better?

Suggestions are welcome. ;)



That is a good idea. Another possible way to go about that would be to show the whole puzzle on one screen. For example, when the player holds down ‘w’ (world) – the screen switches to a static view where the entire puzzle world is scaled down to a single screen. When the player lifts the finger – the game switch back to normal view. This allow a player to try to work out a solution before (and while) solving the puzzle.

For those who are confused about the issue – I attached the following puzzle. To solve it – player must take the left platform before taking the right. Taking the right platform first will cause the player to fail the puzzle. This is unfair as the player had no way of knowing what lies at the end of either platform. Allowing the player to look at the entire puzzle without moving “me” or “shadow” would have allowed the player to figure how to solve the puzzle correctly without any guess work.

Bgalon.

P.S. I think you just extract the files to the levelpack folder.... might be wrong...
Attachments
Examples.zip
(711 Bytes) Downloaded 432 times
bgalon_2000
 
Posts: 15
Joined: 26 Sep 2012, 16:40

Who is online

Users browsing this forum: No registered users and 1 guest

cron