Rick

That screenshot is exactly what I was thinking of. Very simplistic but looks really great!

OK, be sure to put that on the about this project area and probably a bunch of other places so everyone knows

I don't know if I'd want to get all that lore heavy with a community project. Being a sky island these things shouldn't be all that big so as to convey that it's a sky island visually. Plus for dev reasons we'd probably want them to be fairly small so we don't have to fill it with a ton of stuff so exploration would be minimized if that was the case. If we have a big terrain the player will never feel like it's floating in the sky I don't think. I've never played the new Zelda game but I did watch videos on it. They have these tombs you go into and each one has it's own kind of puzzle. Perhaps each sky island can have a puzzle and a couple easy enemies (think zoombas in mario). Solving the puzzles opens up the exit. The character can have some "powers" or something that they get in each island that is used for it's puzzle. We have enough people that I think we can come up with some puzzles and the early levels will be easy ones. If we went this route I don't know if all islands even need enemies. Some puzzles can involve enemies maybe if needed. Like one could be some major stationary bad guy that's spitting out bad guys constantly and you have to fight them so you don't get overwhelmed but there is a puzzle on how to beat the main bad guy itself.

We should probably take advantage of Eric's work for our audio needs. He posts a lot of free stuff!

I agree with sky islands (probably themed). I think that makes things more module and expandable for development purposes. The question now is what do we do on these sky islands? I would assume each one has a main goal to "beat" it while fighting enemies and solving puzzles?

I think such a detailed document is nice when you're doing a game on your own or within a company. In a setting like this I think such a detailed doc from the start is just going to bog down the process. Having this doc is more like waterfall design instead of agile which I don't think works well in a setting like what we have. I think we need a high level idea of the game for sure. We can then come up with 2-3 details for each release. Each release should sort of be playable as a game in some sort of way.

We can just have filler art for that. The other stuff parts for intro are known. I think for version 0.1 the idea should be just get a terrain and character in low poly and intro stuff and 3rd person camera/3rd person movement. That's it. We should be able to move around in this world and that's all for version 0.1. While we are doing that we can talk about more details, but version 0.1 should be bare bones something with movement.

This will be a topic for whoever will be doing the 2D art for the intro screens/main menu. I'll be doing the coding for that and I figured having a to do topic on this will help us coordinate this. The library I'm using allows tweening things with different easing so we can get fairly fancy with this with relative ease. The library works best with 2D images and it's resolution independent in sizing (it'll scale) and positioning.

I can't modify your top post to add tasks but for the UI one can you add a gfx side of that. Need 2D: Made with LE logo "Company" Logo (maybe something that has LE Community Project or something) Game Logo that's displayed as main menu screen?

I'll take the intro screens. I have a UI library that I made some time back. It's resolution independent and works with images and has some nice coroutine ways of handling doing things over time, like fading and moving, which makes for a nice UI experience. I'll use stand-in UI gfx for now but someone will need to do those. I'll make a separate post on UI Intro for me and the person doing the 2D UI stuff for it. The UI library I have also includes a tweening library in lua. So if we need to do things over time, move whatever, this tween library makes it really simple. It's nice because it has different types of tweening. Not just linear. It's based off https://github.com/kikito/tween.lua (don't use this though as the one I have is modified for LE a little). I like the bounce easing for UI as you can sort of bounce in UI elements which gives it a very polished feel.

Looks like Third person, low-poly, world exploration/monster fighting/puzzle is the winner. We need to get some requirements down. As others have stated this is the kind of game that can have it's scope blown wide open so we probably want to start small and build from there. First release should probably be very simple. A terrain and character in the style we want (low poly) just walking around with a 3rd person script. From there the possibilities are endless but without those first steps we have nothing.

I agree, let's use this poll just so it's here on LE projects.

Perhaps a tower defense with space ships as the enemies (I've never seen that before so it could be unique)? The map can just be space with some planets in the background which makes that easy. The enemies can be different kind of ships. Small & fast ships with low health, big and slow ships with high health, etc. Maybe the place where we can put defense weapons are marked as planets and the weapon sits on the planet?

I basically have zero. I always purchased my stuff or worked with an artist.

Yeah, pinned release posts is a good idea!

When I see To Do I think it's a post per task itself. Maybe it's own forum for releases? I think most tasks warrant their own posts especially if multiple people are working on a task it can be a post they can communicate on.

When Tim and I were teaming up this was an issue. Because it was the 2 of us it was easier to manage but even then it did sometimes cause issues. Ideally 1 person would own the production map file. We would have our own map files if we were testing some code out that had visuals.The main map owner would implement any functionality though ideally via instructions by the content creator of said thing.

Yeah, we probably could, but whatever we pick I'd like to have that in the back of people's minds. Will said project be easy to divide scripting (and probably models as well) so we don't end up with a monolithic approach to the development.

I usually think of the coding side when thinking about games created in this kid of setting. Coordinating is hard even when in person so doing it over the internet is even harder. So I'd prefer a game where we can have many pretty isolated scripts vs the bulk of the game being in 1 script (like the player script). This makes it easier to give someone a small script to create as long as the functionality is defined. Even if they don't know all the details about all the other scripts. It makes helping be a low barrier of entry I think. Nobody wants to read thousands of lines of code just to get caught up to help. It also makes it easier to expand on the game later. For that reason I personally think the Third person, low-poly, world exploration/monster fighting is a great choice. Each monster can have it's own script with their own personalities. Can have power-up type scripts that alter the player in some way. We can make some interesting level puzzle scripts.

I've used https://desktop.github.com/ with good success as well. I believe it works with bitbucket too.

Clever bots!

Have you ever considered switching to a text map format on a flexible format like Json that allows for expansion, addition of fields, without breaking the loading of the map itself? The idea being we can add fields to entities and if said entity has a script those fields get added to the script? It could aid in external tooling. Just a thought.

This is very cool and will allow for more artistic UI’s that are easier to work with.

I think that would be tough to do given the functions/variables are right on the entity itself. If 2 scripts share names by chance you wouldn't be able to differentiate them.

It's been awhile so I might mess this up, but CurrentWorld().entities I believe would be the list to loop over. Every entity loaded in the current world would be there. Even dynamic ones. It could be expensive so ideally do it on startup.