Yann's Forum Posts

  • Don't really know how to make a capx out of this problem.

    During the c2 contest, I added sound at the end of the process and when I tried the export, no sound played.

    As there didn't seem to be bug report about that, I thought I did something wrong (audio format, tag use, etc), but didn't find anything.

    Then I closed c2.. reopened it... exported... oh! it works!

    I report this bug because it happened again from but it's not that often.

    c2: r64 64bits

    system: windows server 2008 r2

    browser: firefox 7.0.1

  • During the c2 contest I had to import sequences and sometimes modify them. But almost each time I tried to overwrite the files, windows scolded me telling me they was "used or left open".

    I had to either create other files or close c2.

    c2: r64 64bit

    system: windows server 2008 r2

  • Hi!

    I did report this bug on my big report but decided that it wasn't a good and practical place for it, so I move it here :

    When the size of the object is set to 0,0 during runtime, the game completely freeze.

    c2: r64 64bit

    system: windows server 2008 r2

    browser: Firefox 7.0.1

    BUG-PhysicsFreeze.capx

  • if your windows is 640x480 and your layout is 1280x1024, and you want to put a button in a layer with parallaxe 0,0 that will appear in bottom left

    you should put the button around (0,400).

    Because the layer won't move thanks to the 0,0 parallaxe, you have to put the button where it should be if there were no scrolling at all.

  • I will make an entire report on what I noticed about construct 2 current build when I used it to create MoonShield for the c2 contest

    But First who the f*ck am I?

    I'm just a french guy freshly out of artschool who used multimedia fusion and construct classic quite a lot for almost 2 years (only 10 months on construct) (I did some project you can see and test on http://yanngranjon.com/games/)

    I think construct 2 will be one of the best game creator available right now (once perf issues will be erased from html5 browser support). Still, my report will cover some issues I encountered and some concept I believe might be interesting to consider.

    I don't expect all that I will write to become reality of course, but well, there could be some nice idea.

    So here I go

    In my opinion, there are 3 important points that game maker software should look for :

    • enhancing code readability : being able to reopen an old capx and quickly understanding what it does, working on big complex capx project between team members with minimum time on decrypting what the other did...
    • enhancing modularity : being able to work on a project as a team as well as alone. Games are more often made by teams than by lone crazy monster like konjak or nifflas. So we should be able to write some piece of logic algo and quickly (copy/paste ?) integrate it into the main project without logic bug.
    • still keep it SIMPLE! That is its better quality.

    So first READABILITY :

    c2 achieves that very well, you can make comments, group parts of game logic, sort these parts into included event sheets to easily reuse some part of your engine.

    Also, I love the fact that you can take a tab and put it away and see the event sheet And a layout at the same time.

    And I love the search feature (could be a whole project search maybe? and a search and replace too maybe?)

    Still, I have three ideas to increase readability even more and help creating more organized and usable project.

    1/ inline comment on global/local variable creation

    instead of alterning comments and variable definition

    you could have something like that

    It mimics the way some comments variables in scripted codes

    int myVar; //this variable does that[/code:1l15ke80]
And can make capx easier to understand when they are cluttered by so many unrelated global variables.

[img="https://app.box.com/representation/file_version_18379861793/image_2048_jpg/1.jpg?shared_name=fn8fbozksngw1hgfymib"]
[img="https://app.box.com/representation/file_version_18379862143/image_2048_jpg/1.jpg?shared_name=vcv6mlq8r99ia8194c1h"]

2/ syntax coloration.
We could select a whole bunch of code and set the background to a color, or tell the content of a group to display a given color. this way even when going through tones of events you can still know in which group you are :
[img="https://app.box.com/representation/file_version_18379859869/image_2048_jpg/1.jpg?shared_name=z5ih64ejnom6iumekesn"]
You could also have some highlighting feature to more or less make some important parts stand out more or visually associating some events.

3/ enhanced library
I think the library should evolve a bit. I'm thinking of very simple feature like : knowing if an object is used or not in an event sheet or layout. It could be done with simple color code or icons.
[img="https://app.box.com/representation/file_version_18379877247/image_2048_jpg/1.jpg?shared_name=xbace0w0hw17pbzvtxf9"]
And by right clicking an object in the library you should have information to locate them in layout and/or event sheets.
[img="https://app.box.com/representation/file_version_18379874811/image_2048_jpg/1.jpg?shared_name=a2o8s044rkane3vb2r6j"]
[img="https://app.box.com/representation/file_version_18379876585/image_2048_jpg/1.jpg?shared_name=9jb9906ufqeq56nbce0s"]
Since now deleting an object in a layout doesn't delete it from the library (which is a great, very great idea, it IS a real library of objects now) the library can become a mess pretty fast.
You could also have a dangerous cleaning feature that erase all stuff that aren't used at all.

Also for readability (but I believe you have that in your roadmap) the folder organisation in the library should appear in the ACE windows. with collapsing sections.

Now MODULARITY :
What I did in MoonShield, was building a simple level. And when I worked out all the basic mecanics, I planned to simply put all these mecanisms in an event sheet and include it in other levels with alternate gamplay (but didn't have time to do that for the contest <img src="{SMILIES_PATH}/icon_e_sad.gif" alt=":(" title="Sad"> )
[img="https://app.box.com/representation/file_version_18379855979/image_2048_jpg/1.jpg?shared_name=c5zori7wmsaouo3idows"]

Here two major problems arised :

1/ Global variable unique initialisation
As construct classic uses global variables the same way, I anticipated this one. The very nature of global variable is that if you have a layout that should restart (like "you lose" -> restart), you WILL have to reset all global variables by hand, making redundant annoying code like that :

[img="https://app.box.com/representation/file_version_18379867359/image_2048_jpg/1.jpg?shared_name=nhu29f1yfs2xdeyplqvm"]

Unfortunately, local variable won't do for that kind of situation, because they are just temporary variable that can't evolve during the game because they get reset each game loop. Which make them an awesome tool to increase readability because you will have a code like that :
[img="https://app.box.com/representation/file_version_18379881107/image_2048_jpg/1.jpg?shared_name=49xnbfju20n2dh3rhddo"]
Instead of having a big hard to read expression. And also as there are local, the global variable combobox will not be cluttered by them.

I have two solution for this problem (which are more or less the same) :
[ul]
	[li]global variable should have a property to make them travel between layout or not[/li]
[/ul]or
[ul]
	[li]having a third type of variable "layout variable" that gets reset on start of layout. You can also have the same variable name for other layout (increase readability)[/li]
[/ul]
This way you can have your layout parameter set at the beginning of the event sheet, OR a bunch of variable in an included eventSheet that will create and reset the variable you want for each layout.
This way you avoid redundance and conflict. Keeping true global variables for just the data that should travel.
[img="https://app.box.com/representation/file_version_18379869965/image_2048_jpg/1.jpg?shared_name=zzek4aqkby3t5mp8cdxw"]
Because, after all... There's not that much game that will need a whole bunch of travellable data (score?.. experience?... in rpg it's probably important yeah...)
Also, this way you really only have the variable that you need in the ACE windows (global+current Layout+current local variables), far less cluttering.

2/ Start of layout initialisation conflict
The second problem was unexpected and also pretty annoying. c2 doesn't care where I include an event sheet, he will first call the start of layout code of the included event sheet and then those from the parent event sheet. This structure makes difficult gameplay variation on a same base mecanics.
[img="https://app.box.com/representation/file_version_18379867203/image_2048_jpg/1.jpg?shared_name=r8p97kpxr1yfwgk07a2m"]
In MoonShield, I had to take all start of layout events out of the included event sheet and duplicate most of them in the "parents" of each level.
I think included code should be read in order of its call in the parent event sheet. So if I put start of layout before an include, it should be evaluated before. If I put it after, it should be evaluated after.
I think it's an expected behavior.

3/Other ideas
Other than these two problems, a duplicate layout feature can be interesting. Let say I have a game with asteroids to deviate in order to protect a planet. Now I want another level where I still have to protect my planet, but have to create another one by aggregating asteroids. I'll gladly start from the first layout, adding the new planet and some piece of code to change default positionning and add the newEarth logic.

Also, the ability to merge construct projects. Let say I work with an awesome guy who is really great in UI programming (with c2) and I prefer to code a collapsing black hole ('cause it more fun right?). It would be great that : 
  - my buddy do his thing on a layer named HUD with his objects and his code properly isolated in a standalone event sheet (included in the layout event sheet)
  - I do my part on a layer named GAME with my objects and my code the same way
Every thing works for me and for him
We all worked on the same Layout named "Level1" which has the event sheet "eLevel1"
We merge the two capx, c2 recognize the same layout name, merge all the object/layer/event Sheet in one layout with his layer on top of mines, his event sheet next to mines, and his objects added in the library, with an autorenaming feature (library & eventSheet) in case duplicated names appear. And then we're done! His HUD on top of my game without breaking any sweat

And if he wanted to use some of my objects, we could select the same object that has been renamed during the merging and right click "replace by existing object", after a little check (same instance variable/behavior/effect), the renamed object is deleted and in the eventSheet it is replaced by the proper one.

Or maybe the autorenaming feature during the merging could prompt some stuff to ask if it should autrename or merge the objects (creating the variables/behaviors that doesn't already exists)

For the last part, Keeping Things simple

C2 pretty much ace that already.
I have just a little ideas I already talked about it to ash actually.

default values.
The idea is that each paremeter global/local/instance variables, position, rotation, size, opacity,... have a default value set in parameters. But I think these default should be stored by c2 and retrivable. this way you could do something like
[code:1l15ke80]healthbar set Width to : default(healthbar.Width) * Player.life/default(Player.life)[/code:1l15ke80]
You could, along with that have a setDefault() function to change these values. Imagine if the player's max life increase, you will just have to do  a 
[code:1l15ke80]setDefault(Player.life,default(Player.life)+10)[/code:1l15ke80]
it's really simpler than creating variable to store these default values (and unreal dev kit does that)

Now for some bug and annoying stuff I encountered :
  - a freezing bug : [url=https://app.box.com/s/o2tlph5xzxvy78vyflac]BUG-PhysicFreeze.capx[/url]
  - when do a sequence of png, I importe it in animFrame with the import animFrame feature, and I try to modify these png afterward, I can't overwrite them 'cause they are "left open"
  - sometimes I have to close and reboot c2 before an export to hear the sound
  - we already talked about that but I write it to be complete, the size of an image is update after the frame is drawn, so you can't have the size of an animFrame at the same time you change it. It can be annoying for when you have to setup stuffs with loops.
  - the find function isn't case sensitive. I can see that it can be usefull, but it would be great to have either two find function or another argument to set it case sensitive or not.
  - there's no LayoutName expression to get the current name of the layout otherwise, I would have been able to overcome the include conflict by checking this value.

Annnnd that's all (:

I hope I've been clear enough and that some ideas are interesting. And that Ash will read this and give me his opinion.Yann2011-10-28 14:48:13

  • Oh! I have one little annoying remaining bug,

    Hope I can correct it in time (just one item that doesn't display in the stat screen, and didn't make the credit layout damn so the credit button redirects to the intro for now)

    Other than that, I'm more or less done.

    a) MoonShield

    b) http://dl.dropbox.com/u/23551572/C2-Games/MoonShield/index.html

    c) France

    hope you like it

    Edit : credit frame done in extremis

  • ;_; so great Thank you

  • Is boolean instance variable set <=> "is bolean True"

    Invert this condition if you want "is bolean false"

    to invert a condition, you first create it, and then click on it, and then right click and you shall see the "invert" item with a stroke equal symbol.

    Cheers to you too o/

  • That's basically how I do that, but instead of using a global variable, I use an instance variable BOOLEAN typed.

    so basically

    on left click on sprite : selected to True

    [NOT] left mouse down : selected to False

    if selected : follow the mouse

    Also I add an offset calculation to avoid the sprite to snap on the mouse position. For that I use 2 instance variable xOffset and yOffset

    on left click on sprite :

        Sprite selected = True

        Sprite xOffset = self.X - Mouse.X

        Sprite yOffset = self.Y - Mouse.Y

    if [NOT] left mouse down : selected to False

    if selected :

        set X to Mouse.X+self.xOffset

        set Y to Mouse.Y+self.yOffset

    Oh and my way works with multiple instances, yours don't.

    Cheers too o/

    Oh and... The title of your topic has nothing to do with what you asked

  • Hi guys

    I managed to get all the description of the problem in the subject of the Topic.

    Basically I have a game in which the player can zoom in and out.

    As there's no such feature, I use layerscale.

    But let say I want to spawn something in this layer by mouse clicking.

    The coordinate of the mouse gets projected onto the layer which is scaled so the object doesn't appear under the mouse.

    I tried something basic like MouseX/layerscale("Main")

    I tried by scaling an offset from the center... It worked well with zooming, but when I scroll, it gets off.

    Well, I spent my afternoon on it and didn't find any good solution. So I'm asking you guys \o/

    Here is a little capix to try things :

    scaleProj.capx

    The red sprite is in the "Main" Layer and is supposed to follow the mouse even if scaled and or scrolled.

    thanks (:

  • interesting question

    do your characters have the ability to jump?

    And if they do, Is the jump based on grid movement?

    If it is... Strange feeling

    Anyway here is what I would do... I'm actually working on some changing gravity stuff too so I already figured out some stuff like how to unify code for all direction.

    Basically I use some vector concept

    like in the basic direction you have

    Up : (0,-1)

    Down : (0,1)

    Left : (-1,0)

    Right : (0,1)

    as vector for each direction.

    if you have a character on a wall facing right, his up, left, down and right vector would be something like (1,0), (0,-1), (-1,0) and (1,0)

    etc.

    So the idea is to have 9 variables for each character (enemy or player).

    Only one is really important but the other are better for code readability

    so these variables would be :

    • direction (the most important one)
    • xT and yT (for the top vector)
    • xB and yB (for the bottom vector)
    • xR and yR (for the right vector)
    • xL and yL (for the left vector)

    the direction variable can have a value form 0 to 3 representing the 4 possibilities :

    • 0 on the ground
    • 1 on a wall facing right
    • 2 on the ceiling
    • 3 on a wall facing left).

    This way you can set each of your vector depending on this variable like this :

    Top

    xT = round(sin('direction'*90))

    yT = 0-round(cos('direction'*90))

    Right

    xR = round(cos('direction'*90))

    yR = 0-round(sin('direction'*90))

    Bottom

    xB= 0-xT

    yB= 0-yT

    Left

    xL= 0-xR

    yL= 0-yR

    and then if you want to move a character to his right you just have to :

    + MouseKeyboard: On player 1 pressed "Move Right"

    -> Character: Set X to 'xR' * 'speed' * TimeDelta

    -> Character: Set Y to 'yR' * 'speed' * TimeDelta

    Now for the grid movement :

    You have to set the size of your grid cell in a global variable

    I will name it global('cellSize')

    you also need a variable that will carry the direction of your movement during the interpolation between one cell to the other

    I propose 'xMove' and 'yMove' this way we will also use the aformentionned vector.

    And to be accurate we will store the coordinate of the character before the interpolation in 'xStart' and 'yStart'

    Then you wil have something like that :

    + MouseKeyboard: On player 1 pressed "Move Right"

    -> Character: Set 'xStart' to .X

    -> Character: Set 'yStart' to .Y

    -> Character: Set 'xMove' to 'xR'

    -> Character: Set 'yMove' to 'yR'

    now 'xMove' and 'yMove' carries the direction of the interpolation.

    while 'xStart' and 'yStart' keep the origin safe.

    Now you just have to do :

    + Character: Value 'xMove' Greater than 0

    + System: Abs(Character('xStart')-Sprite.X) Lower than global('cellSize')

    -> Character: set X to X+'speed'*'xMove'*Timedelta

    + else

    -> Character: set X to 'xStart'+'xMove'*global('cellSize')

    -> Character: set 'xMove' to 0

    + Character: Value 'yMove' Greater than 0

    + System: Abs(Character('yStart')-Sprite.Y) Lower than global('cellSize')

    -> Character: set Y to Y+'speed'*'yMove'*Timedelta

    + else

    -> Character: set Y to 'yStart'+'yMove'*global('cellSize')

    -> Character: set 'yMove' to 0

    And that should do.

    So to sum up, you just have to put whatever direction you want in 'xMove' and 'yMove' to make your character moves

    ah and the 'speed' variable is how many pixel/second you want it to move.

  • I think that might help you

    selection.cap

  • And what do you think of that ?

    bigNumberDisplay.capx

    Just store units, thousand, million, billion in different variables

    Increment each one depending on the preceding one

    and just use a bit of string manip to zero fill them when displayed.

    right("000"&number,3) does the trick.

    Are you appy?Yann2014-01-27 09:44:09

  • Oh a nice one indeed. I'll add it as soon as I have the net back (house moving).

    DONE!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • This list is a tool, what you do with it, good or evil, is your own and only responsablity \o/

    (that means yes of course)