I took part in the last ludum dare and did a game with C2.
Here's the things that hindered my workflow and I think some might be quite easy to get rid of, others might not.
I hope Ashley will find something usefull (:
First, here's how I proceeded to make this game :
- I brainstormed and doodled some idea on paper around the theme "evolution"
- once I found some mecanics and managed to create some level on paper, I switched to C2
- I built each mecanism one by one using simple basic square shape as placeholder/collision
- I managed to build up to 9 levels and then decided it was enough
- I made the music (without waiting the last minutes so I could do something more polished than usual)
- I worked on graphics, adding everything in my most complex level (level 9)
- I Applied these changes to the other levels
- And that's basically all
The major issues I had was during step 4 and 7
To build level easily I use the snap feature for placing and sizing and once I'm happy with one level, I duplicate it and work on the next.
During the process I might refine/change my code, add objects, remove others.
The snap in the ribbon is hard to change
To change it you have to write the number and then press enter or give focus to something else in the ribbon before clicking back in the viewport, else the change isn't applied. If your ribbon is in auto-hide, the "press enter" doesn't work. (maybe it should be posted in the bug section?)
An idea to better work with snap
The biggest problem with snapping is the alignement regarding the position of the pivot point. If you have your pivot point in the middle of the shape, and you want to stay on a 32x32 grid, your shape boundaries will end up in the middle of the grid.
Two ideas to make it more usable:
- a snapping mode where the snapping would only worry about edge of the bounding box of objects and without considering the pivot at all. When you resize it would snap the edge(s) you are moving to the grid. When you move it would do the same, going to the closest grid corner.
- an editor-only property for objects to offset/resize the grid per instance.
Duplicating a layout doesn't keep all the layout/layer related properties
Snapping settings, Event Sheet association, Layer visibility and Layer lock aren't duplicated. In the workflow I described I had to reset all these properties every time. Ok it's not too complicated it takes 10 to 20 seconds each time. But I think that's the kind of thing we are expecting. So when I launch the game and nothing happens, I'm like o_o... "Oh yeah Event Sheet association."
You are forced to name layout a certain way to create a "go to next layout" functionnality
Ok this one needs an explanation: in my game, I have only one event sheet called "engine" I associated all my layouts to this event sheet (didn't even use include). So, to go to the next layout once I finish the current one, I do something like:
[code]On end of level -> Go to Layout "Level "&str(int(replace(LayoutName,"Level ",""))+1)[/code]
In short, I increment the numeric part of the layout name
This leads to the fact that I HAVE to name my layouts "Level 1" "Level 2" "Level 3"
I might seems ok, but:
1- such a name is really not descriptive at all, so you end up wondering "oh yeah, what is the level where we could only jump to win?"
I would much prefer naming my layouts "The Jumpy Level" or "First encounter" or something meaningfull.
2- reordering is a pain. I have to rename all the layout after the one lowest I swapped. And has we can't have two layouts with the same name, it becomes quite a pain.
So yeah, having an internal index of layout and a go to next/previous layout action would be awesomely great as well as "nextLayoutName" and "previousLayoutName" variables, or accessing layouts via an index. 'Cause I can imagine a game that would go to a "Stats" layout between each level.
Applying things to other levels:
Damn, that was the most painfull and time consuming phase. C2 is NOT (yet) built for that kind of global scale change. And I seriously think that's it's one of the most important aspect that makes the difference between using C2 for small tiny little toy game and big serious projects.
Unless you create a level editor of course.
But then why do we have layouts?
So ok here's what I would suggest. Probably some of that is already on a todo list but I'll say all that I have in mind for completeness.
We should be able to change the properties of objects across layouts
Yes we could do that in a event in a start of layout with a ridiculous long list of setting stuff... hmpf.
OR... There could be a way to change the X position of every instance on all layouts, or any other property.
Here's some ideas on how it could look:
- If you click on an object type in the "Objects" panel you select all the object in the layout and then all changes apply to all of them. If you click on object type in the "Projects" panel it currently does the same. But it could be different. If I click on the project panel object type, I could be in a "Global property change" mode with a big feedback like different background color in the property fields, or a big red message telling you that you are globally changing everything *God mode*
- You could right click on any instance and have an "applying these properties on all instances of the project"
So in short, if I'm making a HUD and I want my buttons a little bit more to the left, and don't want to go through my 110 levels... It would be great to have such feature :D
I had to duplicate the same object in all my layouts one by one.
This problem could be handled the same way as the global property I just talked about. You right click on an instance and "duplicate this instance with its properties in all layouts". It would create the instance and set the same exact properties (including position, layer, blending mode and fx)
These two last issues leads to one problem though
Layer consistency across layouts.
Indeed, If I want to apply the same object properties across all layouts the layer scheme of each layout could cause some issue.
I think it's a bit more complicated than applying changes or creating objects across layouts, because following the workflow I described, I would already have some layers, and maybe I would have renamed them and created others in some layouts, etc.
One idea could be to handle it like copy pasting files in a folder.
- you select a bunch of layers, you right click > copy layers
- you select a bunch of layouts, you right click > paste layers
And then you'll have a popup "a layer with the same name already exists : Overwriting properties / Ignoring + apply to all warnings"
We would need another operation to copy and paste the ordering of layers though. So yeah might not be the best solution, but there's definitely something to do to make global changes a bit easier.
Maybe some layout templates, a bit how family works...
Other small little things:
I didn't have to use that in my project, but I was talking with a friend using C2 and I told him something like "Oh! It would probably be easier if you had all these prites in different animations of the same sprite.
An ability to merge / split sprites would be awesome. (Well splitting is easier, just have to duplicate and get rid of animations)
Maybe copy pasting animation across sprites could be usefull also.
Set mirrored/flipped, set boolean, set visible, etc it would be great to be able to set these kind of thing in expressions.
Personnaly, I don't really like the set mirrored/flipped action, I'd like to have to choice to deactivate this feature and set negative width/height.
[code]Sprite -> set width to sin(time*360)*self.ImageWidth[/code]
-> Sprite: set width to sin(time*360)*self.ImageWidth
-> Sprite: set Not mirrored
System: sin(time*360) < 0
-> Sprite: set mirrored[/code]
yeah I know I'm picky (:
There's a better example in my LD game where I handle the fusion
It would have been much cleaner to just do a
System: Set newChar to Character.UID
character: set Right to bRight
character: set Left to bLeft
character: set Jump to bJump
character: Set animation frame to 1*self.right+2*self.left+4*self.jump
I'm not limited to 100 events but well... redundancy is ugly :D
It would be nice to have some stats available.
Like the number of currently selected object (in the status bar for instance)
Right clicking on an object type > properties and having an table with all the instances, the layout they are in and their property you could event change from there (could be a third possibility for global change)
Same for layouts, a table with a tree list of all object type and if you expand you can access each instances.
You could easily pinpoint where you have instances missing or missplaced, of some wrong initial properties...
Yeah something like that for broad changes would be great!
I think I've said all that I had in mind (:
Basically, providing some feature for big scale project would be awesomely great. I like creating level editors, but these things take a bit of time and we often lose some flexibility (mostly with graphics tweaks and tricks)
Hope you liked the game though :D