maxcrocky wrote:

so new vote
1.should we show an outside view of spaceship when in space(1.no/2.yes but we can differentiate all the parts/3.yes but we can only differentiate some of the parts/4.yes we can see only thrusters)

I vote 2 and also maybe we can have 2 layers to the player's ship the exterior and interior but the interior only shows when parts are damaged(also i dont know about the look if we use only exterior designs).




Edit: online players and bots would not show the interior right? Also im thinking of the gummi ship builder in kingdom hearts 3 we could get ideas from that

Well, fellow collaborators, should we start defining the tasks for step 1, as suggested in my organisation proposal?

Btw I'm still not convinced about the interior + exterior views of ship parts. Perhaps @squarepoint can come up with one example in some moment?

To begin task design, we can read again my game description and find all the items the game would contain (from costumes to mechanics) which are related to ship building, and then we can divide them into smaller tasks (one item can become one task). To help, we can also look again at the first studio of the SPEE Collab which already contains a lot of work.

lolrenz12 wrote:

(#1243)
To begin task design, we can read again my game description and find all the items the game would contain (from costumes to mechanics) which are related to ship building, and then we can divide them into smaller tasks (one item can become one task). To help, we can also look again at the first studio of the SPEE Collab which already contains a lot of work.

So, here's a first list of things we should do during step one (ship building), all departments included (except sound):

- Define the set of ship parts that exist (normal ones, but also eventual upgrades and variations like square suggested).
- The grid where you can place the ship parts, and also remove them and move them, and even rotate cannons. A bar with all available parts can be added on an edge.
- Ship validity control: Is overall energy positive? Is the spaceship connex (as in graph theory)? Are thrusters and cannons placed correctly?
- Ability to save, name and load ship designs (or not load them if the right ship parts aren't there).
- Warehouse: it contains the ship parts and the other goods (on a grid or just as a list?), and the player can access it from the hangar.
- Hangar UI: How are these many buttons spread on the screen? Do we make a hangar menu or does the grid screen also act as a menu (like in the first version)?

We also need to set a pixel's size and all this pixel-art-related parameters I don't really understand. So I let you decide that lol.

Based on the list I shared earlier, I can deduce the following tasks:

- (DESIGN) Decide upon a list of existing ship parts, including upgrades and variations, which also involves setting their names, energy costs, and other eventual properties (we may be altered later if needed ofc).
- (DESIGN) Suggest a hangar layout, which firstly involves determining the buttons and other stuff that the hangar is going to contain, and then how there will be placed on the screen to make it practical and clear. (Is the ship-building grid screen also gonna be the hangar's home screen?)
- (ART) Hangar UI artwork: grid, buttons, counters, etc.
- (ART) Hangar background.
- (CODE) Text render: as soon as now, we may need one, to print ship part names or spaceship design names. I think @infintyrussia made one.
- (CODE) Make the hangar buttons functional: every button is supposed to do something, right? (May be one task per button.) Some buttons won't find their utility yet, so those will be left unresponsive.
- (CODE) The ship-building grid! It should consist of a responsive 8x8 tile grid on which parts can be placed and removed (moving them is not really necessary imo). Make it impossible to place a part behind a thruster or in front of a cannon. Make it possible to rotate cannons (90º)?
- (ART) Grid tile artwork: normal tile and forbidden tile (in front of a cannon for example).
- (CODE) Ship validity criterium 1: overall energy is positive.
- (CODE) Ship validity criterium 2: all parts are connected to each other.
- (CODE) Ship validity criterium 3: no ship parts in front of cannons and thrusters.
- (CODE) Ship design save code generation, including a name (automatically generated name if none is provided). No saving is possible if the ship doesn't verify criteria 2 & 3.
- (CODE) Loading a ship design into the grid, unless the ship parts aren't there or the ship design doesn't verify criteria 2 & 3.
- (CODE) Saving any amount of ship designs (with save codes), not naming two designs the same way. Possibility of deleting, editing and renaming them.
- (DESIGN) How should the ship design save managing screen look like? (Which buttons will it contain? How will they be organised?)
- (CODE) Code the ship design save managing screen.
- (ART) Buttons and other stuff in the ship design save managing screen. (Should they be icons or text?)
- (ART) Ship design save managing screen background.
- (CODE) Besides the ship-building grid, add a bar on an edge where available ship parts are displayed and from where the player can select them to add them to their ship. It can be scrolled or has several “pages”, and next to each type of ship part, the amount of available parts of that type is shown.
- (ART) Make the artwork for the bar described above.
- (ART) Warehouse background.
- (DESIGN) (CODE) (ART) Warehouse UI. (Description is similar to those given before.)
- (DESIGN) Warehouse: Should items be stored in a mere list and sizes added up, or should it look like grids, like cargo holds? (@rap1412 already mad a version using grids.)
- (CODE) Warehouse item storage: Each item should have any size and any other relevant properties (item name), even thought we only have ship parts for the moment. We will invent random goods for tests. Warehouse maximum capacity.
- (CODE) Transferring warehouse contents data to warehouse UI so the player can see what's in there.
- (DESIGN) (CODE) (ART) Cargo space UI.
- (CODE) Each cargo hold is a 6x6 grid. There may be several cargo holds be ship, or sometimes none.
- (ART) Cargo space tile.
- (CODE) Placing items from the warehouse to the cargo and from the cargo into the warehouse, when there's enough space!

These tasks are written in any order and task dependency has yet to be determined.
Did I forget anything? Feel free to add stuff.

Btw, as I was writing this, I realised I hadn't though of something: how do we move goods from ship cargo holds to warehouses and vice versa? Should it be something like the ship-building grid, with a list of warehouse stored items on an edge and the cargo grid in the other side?

Ur cooking lol

lolrenz12 wrote:

Based on the list I shared earlier, I can deduce the following tasks:

- (DESIGN) Decide upon a list of existing ship parts, including upgrades and variations, which also involves setting their names, energy costs, and other eventual properties (we may be altered later if needed ofc).
- (DESIGN) Suggest a hangar layout, which firstly involves determining the buttons and other stuff that the hangar is going to contain, and then how there will be placed on the screen to make it practical and clear. (Is the ship-building grid screen also gonna be the hangar's home screen?)
- (ART) Hangar UI artwork: grid, buttons, counters, etc.
- (ART) Hangar background.
- (CODE) Text render: as soon as now, we may need one, to print ship part names or spaceship design names. I think @infintyrussia made one.
- (CODE) Make the hangar buttons functional: every button is supposed to do something, right? (May be one task per button.) Some buttons won't find their utility yet, so those will be left unresponsive.
- (CODE) The ship-building grid! It should consist of a responsive 8x8 tile grid on which parts can be placed and removed (moving them is not really necessary imo). Make it impossible to place a part behind a thruster or in front of a cannon. Make it possible to rotate cannons (90º)?
- (ART) Grid tile artwork: normal tile and forbidden tile (in front of a cannon for example).
- (CODE) Ship validity criterium 1: overall energy is positive.
- (CODE) Ship validity criterium 2: all parts are connected to each other.
- (CODE) Ship validity criterium 3: no ship parts in front of cannons and thrusters.
- (CODE) Ship design save code generation, including a name (automatically generated name if none is provided). No saving is possible if the ship doesn't verify criteria 2 & 3.
- (CODE) Loading a ship design into the grid, unless the ship parts aren't there or the ship design doesn't verify criteria 2 & 3.
- (CODE) Saving any amount of ship designs (with save codes), not naming two designs the same way. Possibility of deleting, editing and renaming them.
- (DESIGN) How should the ship design save managing screen look like? (Which buttons will it contain? How will they be organised?)
- (CODE) Code the ship design save managing screen.
- (ART) Buttons and other stuff in the ship design save managing screen. (Should they be icons or text?)
- (ART) Ship design save managing screen background.
- (CODE) Besides the ship-building grid, add a bar on an edge where available ship parts are displayed and from where the player can select them to add them to their ship. It can be scrolled or has several “pages”, and next to each type of ship part, the amount of available parts of that type is shown.
- (ART) Make the artwork for the bar described above.
- (ART) Warehouse background.
- (DESIGN) (CODE) (ART) Warehouse UI. (Description is similar to those given before.)
- (DESIGN) Warehouse: Should items be stored in a mere list and sizes added up, or should it look like grids, like cargo holds? (@rap1412 already mad a version using grids.)
- (CODE) Warehouse item storage: Each item should have any size and any other relevant properties (item name), even thought we only have ship parts for the moment. We will invent random goods for tests. Warehouse maximum capacity.
- (CODE) Transferring warehouse contents data to warehouse UI so the player can see what's in there.
- (DESIGN) (CODE) (ART) Cargo space UI.
- (CODE) Each cargo hold is a 6x6 grid. There may be several cargo holds be ship, or sometimes none.
- (ART) Cargo space tile.
- (CODE) Placing items from the warehouse to the cargo and from the cargo into the warehouse, when there's enough space!

These tasks are written in any order and task dependency has yet to be determined.
Did I forget anything? Feel free to add stuff.

Btw, as I was writing this, I realised I hadn't though of something: how do we move goods from ship cargo holds to warehouses and vice versa? Should it be something like the ship-building grid, with a list of warehouse stored items on an edge and the cargo grid in the other side?

Yeah for cargo hold to warehouse i think we could have a separate grid of whats in the ware house and the cargo hold with their icon and number of, and all items that can be transferred would be highlighted green and stuff that cant be transferred would be highlighted red this would tie to how much space is in the warehouse and what's in it. (say there are 3 sticks in the warehouse and 2 in the cargo hold the sticks would be green because they can stack on either storage)

DUBXMUSIC wrote:

(#1247)

lolrenz12 wrote:

~snip~
Btw, as I was writing this, I realised I hadn't though of something: how do we move goods from ship cargo holds to warehouses and vice versa? Should it be something like the ship-building grid, with a list of warehouse stored items on an edge and the cargo grid in the other side?

Yeah for cargo hold to warehouse i think we could have a separate grid of whats in the ware house and the cargo hold with their icon and number of, and all items that can be transferred would be highlighted green and stuff that cant be transferred would be highlighted red this would tie to how much space is in the warehouse and what's in it. (say there are 3 sticks in the warehouse and 2 in the cargo hold the sticks would be green because they can stack on either storage)

Yes that was what I was thinking of, but rather the grid for the cargo hold and the icon + number for the warehouse. And I think that the coloured highlight is a good idea!

So, let everyone tell what they want to do now. I've laid a list of tasks for step 1, and I've suggested that you complete it. But if you don't that's ok too, the list of tasks can evolve at any moment if required.
So, what should we do now? Would you like to start working on something more concrete, like taking a task?
Let me know what we should be up to so that we keep moving

I can't believe I am saying this but I had alot happen recently and I may have completely forgotten about the colab lol

maxcrocky wrote:

(#1250)
I can't believe I am saying this but I had alot happen recently and I may have completely forgotten about the colab lol

I mean, real life first, of course.

Btw, I won't be around from July the 16th to the 29th. Like, at all.

I'll start working on the task dependency tree, you can help if you want.

lolrenz12 wrote:

maxcrocky wrote:

(#1250)
I can't believe I am saying this but I had alot happen recently and I may have completely forgotten about the colab lol

I mean, real life first, of course.

Btw, I won't be around from July the 16th to the 29th. Like, at all.

I'll start working on the task dependency tree, you can help if you want.

I'll see what I can do to help get this thing moving along

So how are we going to advertise joining the collab

Sooo I made a task dependency tree (TDT) maker on Scratch: https://scratch.mit.edu/projects/1195550417/ (yeah now the link works).

DUBXMUSIC wrote:

So how are we going to advertise joining the collab

Well, we already have this forum thread. I don't have any other ideas right now tbh. Do you have any?

tbh i am lost in the tasks you posted

thumbnail task
https://scratch.mit.edu/projects/1197439916

can we agree not to use clones at all unless there's no other way

vote:
yes/no: should we not use clones unless its the only option in the final project

my vote
should we not use clones unless its the only option in the final project: yes

My vote: No.
We should allow ourselves to use clones for tiny stuff, such as buttons in menus. It makes it easier to code and doesn't cause a lot of lag to use a few clones. But I agree that we shouldn't use them in most cases.

This is probably my last post in the next two weeks btw.

lolrenz12 wrote:

My vote: No.
We should allow ourselves to use clones for tiny stuff, such as buttons in menus. It makes it easier to code and doesn't cause a lot of lag to use a few clones. But I agree that we shouldn't use them in most cases.

This is probably my last post in the next two weeks btw.

Add me to dashboard group

lolrenz12 wrote:

Btw, as I was writing this, I realised I hadn't though of something: how do we move goods from ship cargo holds to warehouses and vice versa? Should it be something like the ship-building grid, with a list of warehouse stored items on an edge and the cargo grid in the other side?

i can finally reply to this my brain failed to read it but ai helped alot

so i think it should be something like victoria3's army transfer window:https://scratch.mit.edu/projects/1198064453