Roadmap

[JuhaKiili]

Any ideas how to approach the roadmap?

Does anyone have experiences on what kind of approach works? I'm thinking that adding too much formal planning takes out the fun of organic development, but total lack of roadmap might not be ideal either.

Should start by just adding one-liners to the Wiki or do we bloat the Issues with feature requests?

What about milestones. Any use for those?

I should probably maintain some sort of light leadership role, but because of my total noobness in open-source collaboration, I feel a little bit lost.

[JoeOsborn]

It's not uncommon on GitHub to use issues for feature plans, and categorize/filter them appropriately. Wiki changes may make sense for features or changes that we aren't sure about, but I think issues are more likely to generate discussion (especially since they send out email notifications).

Milestones only make sense if we plan releases. While I think the master branch of this repo should always represent a working RagePixel, if you want to update the Asset Store version periodically then milestones and release tagging and stuff do seem reasonable. I think we should hold off on that for a little bit, though.

To sum up: I'm happy with a list of "nice to have" features in the Issues list that we then sort, filter, prioritize, deprioritize, close as "won't fix", etc.

[JuhaKiili]

I agree with holding off from making a big deal out of milestones and official release. People can always come and get the latest here if they want. We'll figure out the time for actual milestone release later on.

Using the Issues for features sounds fine to me. If it gets too chaotic, we'll reorganize.

Should we use the Wiki for the documentation of the new features then?

[Bloodyaugust]

As for the wiki on RagePixel, what is currently planned to be included? Is it going to be used as the main RagePixel wiki? If that is the case, I'll be doing some writing in it. I've been sharing around RagePixel, and have had a number of questions that could be easily answered by a mildly comprehensive wiki.

I'm also planning on writing a tutorial series, and I think a list of tutorials should be maintained here.

[JuhaKiili]

@Bloodyaugust write your stuff to the Wiki by all means. I added you to the collaborators list now.

[Bloodyaugust]

Excellent, many thanks!

[ericraue]

I think we could use this issue to discuss the initial roadmap and use a wiki page to prioritize and summarize our ideas. It will probably fluctuate a bit at first. Once we have a a better view of what needs to be done we could use issues to keep track of who is working on what feature.

I'll start off with some of my ideas. I'm currently working on a zero g space themed game that utilizes PhysX and has lots of rotation so some of these ideas are specific to that.

Camera

Adding convenient shortcuts for moving in 2D, zooming between pixel sizes that stops on integer positions, rotation, and screen shake.

Tilemap

I would like to see something like Pixothello where you can quickly switch between placing tiles and painting them. The solution we choose should be able to handle collision detection too but that depends on how we approach physics. I thought of a few ideas but I'm not sure what the best approach is.

Tile map is one GameObject with one sprite per tile as children

When the tile map is selected it's in tile drawing mode. In that mode you select a sprite from a palette of sprites. The selected sprite appears in preview window (sort of like the current colour in sprite drawing) with it's name underneath.

• Left mouse button to paint
• Right mouse button to pick tile
• Press V or H to flip tiles
• Ctrl + alt + z to undo
• [ and ] to cycle through frames on the tile brush
• Ctrl + left mouse button to select a sprite (selecting that object and exiting tile map mode)

In sprite editing mode you press Esc to deselect the sprite and select the tile map if it's parent is a tile map.

Tile map is one GameObject with one mesh

Similar to the first idea except it stores all the sprites as a single mesh that are individually accessed through the tile map. Switching to drawing mode spawns a temporary sprite to edit that is deleted when deselected.

Combine sprites and tile maps into one editor

Not my favourite solution since there is so much code in the RagePixelSprite class already.

Drawing

The pencil tool currently skips pixels when moving the mouse too fast. To fix this we could use the line drawing tool to fill in the pixels in between.

New tools

• Line drawing tool
• Ellipse tool
• Box tool

Mirror axis

Inspired by Pixothello, being able to mirror the x or y axis while drawing. Video of feature in action

Animation

Editor preview window

While working on an individual frame it would be incredibly helpful to see an animated preview. By default it will play all the frames from left to right looping. Underneath the preview the user could specify the range and direction.

Onion skin

When the animation dock is expanded the sprite could generate another quad behind with UVs to the previous frame and vertex colours multiplied by 0.5 alpha.

Parallax

Grouping sprites under an empty GameObject with a RageSpriteParallax script attached to it. The parallax object communicates with the camera to determine how much to move. It could even have a layer tint colour that overrides the individual sprites. The Super Meat Boy Editor is a good reference to study. (video of it here)

PhysX

I know @JuhaKiili suggested writing a simple 2D collision system and I think that should still be done. I've been toying with a script that decouples the physics into a separate object. I found that without continuous collision detection it sometimes will go through objects due to the 1 unit = 1 pixel scale. If this works out I'm not sure if it should be included in the main branch.

Update & Export

I already started on the Update feature which keeps track of imported textures. The next step is to add an export feature should someone make changes to them. It also should support breaking the connection.

Wow this has become quite long. Let's get this discussion going!

[Bloodyaugust]

@ericraue: IMHO, the two least important features here are the new PhysX integrations and any modifications to in-editor drawing. Physics in 2D are usually relatively easy to implement, and with the update function, why not use an external editor?

On the TileMap front, I'm using a hacked together build of my own right now, which wouldn't take a whole lot to spruce up. It supports node mapping and pathfinding as well, and I'm planning on coming up with a file format to parse to/from.

[JuhaKiili]

Sorry it took me some time to think about this and reply @ericraue

Camera:

• I agree

Tilemap:

• There are lots of variations of what the term tilemap actually means, but I'm referring to something that has equal sized rectangular tiles on a grid. No tile goes over the other. More complicated tilemaps should go into separate components IMO.
• I'm strongly against using child GOs too. It has some perks, but there an overhead per GO so it's very unscalable.
• I'm all for the one mesh, one GO, one TileMap. Users should be informed using several tilemaps instead of one huge 1000x1000, if they want to prebuild big worlds.
• I think drawing doesn't and shouldn't spawn any temp sprites. Tilemap component should handle drawing itself. The goal should be to let user always draw onto everything, and the various RageComponents should always have their implementation of the various drawing commands. I'm writing a IRagePixelDrawable interface for this now. I'm not sure I get it done before 14th (when I start at Unity). Someone needs to take over.
• No animation support I think. It would be "nice to have", but awful performance-wise. It can be done with some tricks, but I wouldn't worry about it now. If you want animation, you just put stuff separately over the tilemap I guess.
• I think the tilemap should support a tile-painter with tile-brushes. Tile-brushes would mean a sprite with some cell(s). Let's say 9 cells with some rocks (top-left, top, top-right...). The tile-painter would then pick the correct cell while painting. There is something similar in 2D Toolkit tilemapping (http://unikronsoftware.com/2dtoolkit/doc/tilemap/Tutorial.html). There are many details into making this and it's hard to start guessing beforehand what are the best choices. If you look back at the history of 2D games, there seems to be hundreds of different approaches for tilemapping.
• In the old days, people would cram several terrain types and transitions into one tileset, but I think it's not worth it anymore. I think the tilemap could have N layers and when building it's mesh, it could have intelligence to leave out layers that aren't going to be visible. The individual cells could have isSolid property (cached) by looking at alpha channel to make this easier.

Drawing:

• I agree

Animation:

• I agree

Parallax:

• My friend always tells me that parallaxing in Unity is much better/easier with having just separate cameras and some rendering layers. I can't remember what were his arguments, but I think he had some good ones :) Gotta ask again.

Physics:

• Both approaches should be covered IMO. The RagePixelCollider/RagePixelRigidBody with pixel perfect stuff and maybe some cool ways to use alpha channel. On the other hand we should have easy ways to create PhysX colliders. It's easier to do the latter first so maybe go with that.

Update & Export:

• I agree