Page 2 of 3

Re: SHMUpy General Production Thread

Posted: Tue Jul 22, 2014 12:02 am
by Halico
Needs better symmetry, since it was and prolly still is(haven't fraxy'd) an issue.
Also kinda needs better player hitbox, right now in fraxy it looks like it's something like 2x2, but it's actually bigger than that due to hitbox place approximation.

Just listing issues in fraxy back when I still play it.

Edit: Also change/remove the combo damage system.

Re: SHMUpy General Production Thread

Posted: Tue Jul 22, 2014 12:08 am
by Garoslaw
We'll see how things work now, for now I'm still building the most basic stuff for the engine to draw, and once I manage that, I will be able to adjust it so you could change it at any time through a configuration file (until I make a config app)

As of the alignment issues, I'll see what I can do once I'll begin letting stuff be rendered with OpenGL instead.

Re: SHMUpy General Production Thread

Posted: Tue Jul 22, 2014 5:32 pm
by TheBlueEcho
How are you handling deployment/sharing of user created content? See you are using XML's which I think is good, but what about any images or music associated with user made players, bosses, bullets and scenarios? Will they have to be packaged with the user content or pre-installed on the users copy of SHMUpy? If not eather of these, how else?

Re: SHMUpy General Production Thread

Posted: Tue Jul 22, 2014 5:53 pm
by Garoslaw
TheBlueEcho wrote:How are you handling deployment/sharing of user created content? See you are using XML's which I think is good, but what about any images or music associated with user made players, bosses, bullets and scenarios? Will they have to be packaged with the user content or pre-installed on the users copy of SHMUpy? If not eather of these, how else?
One solution is to host a server that would hold the user-made data, and any instance of the game itself would have a built-in client that could fetch the creations, materials, etc.

For now however one would have to zip the necessary things into a compressed file as you would a TRY and any other related to it things.

Right now I'm working to get the fullscreen trigger working, because it refuses to work for me properly. x3

Re: SHMUpy General Production Thread

Posted: Tue Jul 22, 2014 8:28 pm
by TheBlueEcho
The Server fetching method sounds very convenient and, potentially, very organized. On top of separating everything by content type, you could also specify whether content is Complete or W.I.P., Public or Private (available only to certain users)

I'll try not to bombard you with too many questions at this early of a stage, but alas just two more if you could bare with me. ; D

What kind of properties would you like or could imagine including for parts and playercrafts? (Besides what you generally listed -- those are categories)

In fraxy, Bosses do have some control over the player, but can't do things like change the game mode, or playership type and weapons (but you could fake player weapons). Would you allow bosses to override settings and configurations, or would you leave that to scenarios?

Re: SHMUpy General Production Thread

Posted: Tue Jul 22, 2014 8:51 pm
by Garoslaw
TBE wrote:I'll try not to bombard you with too many questions at this early of a stage, but alas just two more if you could bare with me. ; D
That's fine, for me feedback is crucial. I tend to put a lot of thought when people ask me questions. Besides, I don't have much to do lately.
TBE wrote:What kind of properties would you like or could imagine including for parts and playercrafts? (Besides what you generally listed -- those are categories)
I want to make it so that both parts and player crafts could have their own hit-box defined, either by a figure, or the shape of the sprite basing on threshold.
I don't exactly know if I understood you well on that regard though.
TBE wrote:In fraxy, Bosses do have some control over the player, but can't do things like change the game mode, or playership type and weapons (but you could fake player weapons). Would you allow bosses to override settings and configurations, or would you leave that to scenarios?
I always liked the fact that the editor offered fairly low abstraction and didn't limit itself to just making enemies. It's true however that they couldn't do everything.
My plan for FreePlay in SHMUpy is that players would be able to play things others have made in a preset environment, while in Scenario, you could do everything from scratch, thus making an actual full game with the provided engine.
I also thought of letting the enemies have their own, custom defined variables, instead of just being limited to 4 local variables and 8 global ones.

Re: SHMUpy General Production Thread

Posted: Wed Jul 23, 2014 5:54 pm
by TheBlueEcho
Garoslaw wrote:That's fine, for me feedback is crucial. I tend to put a lot of thought when people ask me questions. Besides, I don't have much to do lately.
Okay, I will ask questions when I can and when I come up with some.
Garoslaw wrote:I want to make it so that both parts and player crafts could have their own hit-box defined, either by a figure, or the shape of the sprite basing on threshold.
I don't exactly know if I understood you well on that regard though.
Well, yeah you did, but I guess I was more asking about what would you be able to do under each of those properties, and how would they interact with the event editor.
Garoslaw wrote:I always liked the fact that the editor offered fairly low abstraction and didn't limit itself to just making enemies. It's true however that they couldn't do everything.
My plan for FreePlay in SHMUpy is that players would be able to play things others have made in a preset environment, while in Scenario, you could do everything from scratch, thus making an actual full game with the provided engine.
I also thought of letting the enemies have their own, custom defined variables, instead of just being limited to 4 local variables and 8 global ones.
I agree with the variables. They could be local to the part, local to the boss (so that all parts can ref), or global to the system. Naming them would also be useful, and a method of tracking them, like a list that has the name, value, and part.

Re: SHMUpy General Production Thread

Posted: Wed Jul 23, 2014 9:10 pm
by The Phantom
Arbitrary number of local/boss/global variables is definitely a good thing.

Re: SHMUpy General Production Thread

Posted: Wed Jul 23, 2014 9:37 pm
by Garoslaw
Part Properties - Most likely similar to what you get in Fraxy: part distance(relative to it's origin point or the parent part), durability, show flag, layer (This potentially would allow enemies be drawn under the background layers, or above the player), connection type, and perhaps a few new ones like transparency

Projectile Properties - By default none, the user would be able to add a new kind of projectile emitter, end edit values from there, such as: Projectile type (This is important; you would be able to load a projectile from the default list, or a custom-defined one. This also defines what kind of the emitter is it, from which the properties change a little bit.), location of emitter (distance and angle relative to the part),

If it's a bullet-regular kind: projectile angle, size, Speed A, Speed B, Speed Fade Type (editable as a graph), turn (could expand on that by flags that would define if turn refers to a one-shot turn or a constant turn, as well as delay before turning), aim player flag, reflection property and amount, lifetime, split (Basically Ex. Param 5 and 6 combined for bullet-like types, can define to how many projectiles should it split to and how much it spreads in an angle. Can also add delay before splitting, if it's 0 then it's split immediately.), damage rate (constant or one-shot, can define how much damage does it deal to the player)

If it's a bullet-bubble kind: Same as bullet-regular, with the additional size B, size shift rate (either relative to lifetime through percentage, or through the amount of frames and how much should it shift between the two values)

If it's a bullet-laser kind: Same as bullet-regular, with specifics you'd see in homing lasers or reflect rays: trail length, trail end-size, Trail damage flag (will determine whenever the trail causes constant damage or not)

If it's a bullet-loaded kind: This basically adds the functionality of releasing shrapnel at the end of the projectile lifetime, which can be defined with a sub-projectile property (perhaps just another properties thing below the other) or defined as an explosion.

If it's a laser kind: Laser length, laser width, fire speed, damage rate, charge length, flags (Additional effects kinda like you'd see in Power Laser)

Most, if not all, properties can be altered through events, and the fire trigger can also be executed with events.

Effect Properties - By default none, player can add an emitter and edit the values from there: Sprite (can be chosen from the default list or a custom one) or Shape (rectangle, circle, and a few other shapes as well, can have an assigned gradient from one color to another), Emitter type (spark, shockwave, simple kinds, texture? Still thinking on that)

Depending on what kind of emitter it is, the properties will change as well, but I'll be still thinking on that one.

Re: SHMUpy General Production Thread

Posted: Wed Jul 23, 2014 10:42 pm
by The Phantom
What about the ability to have a projectile split, but remain, then split again, remaining, etc. basically leaving a 'wake' of bullets?

Furthermore, a projectile splitting,and then THOSE projectiles splitting, etc. etc. until some user-set lifespan elapses.

EDIT: Also, custom pickups, with custom behaviors on how they move onscreen. Example: A scoring item that drops down then goes to the top of the screen unless picked up, an item that switches your weapon to a defined one (or gives you another weapon)...

Also, a proper one-HP-only mode.