You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We'll need a broad roadmap of what sprites should be created first.
There're several reasons why this matter, some to keep in mind are:
Some sprites rely on others (Vehicles generally rely on a peep model, etc.).
Some sprites may pose technical or design challenges that need to be discussed first.
Some sprites are currently not supported by our toolset yet.
Something like the ground sprites are very prominent in the game, they may be a logical first target. But due to their prominence, we probably have to talk about the texture that we'll use for it. A different color of grass may heavily impact the look of the entire game for example.
As such it might be best to focus on less prominent graphics to test the waters with. They may be easier to change out later on as well. If we end up not liking these first endeavors.
Currently, our Blender tool does not support tracks. Due to this feature not being available yet we can not yet start generating track sprites unless we use X7's specialized track renderer.
We do not need to plan out every single individual object, but a general idea of which types of objects we want to tackle first, and which will come much later down the line will be important.
I think we should start with recreating some stuff from G1.dat. I think that peep sprites should have a high priority, since almost all the ride sprites will rely on them. Along with peeps, we could start with supports sprites or land tiles (or other G1.dat stuff).
If we want to start with simpler and less game-changing sprites, we could start with some basic scenery items. Once we are confident with our sprites, we could tackle the ground sprites and other prominent ones (like Oli mentioned).
On Mon, Jul 26, 2021, 13:49 Patrik Kalamár ***@***.***> wrote:
I think we should start with recreating some stuff from *G1.dat*. I think
that peep sprites should have a high priority, since almost all the ride
sprites will rely on them. Along with peeps, we could start with supports
sprites or land tiles (or other G1.dat stuff).
If we want to start with simpler and less game-changing sprites, we could
start with some basic scenery items. Once we are confident with our
sprites, we could tackle the ground sprites and other prominent ones (like
Oli mentioned).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPIOP37RFEH2JWBI4BPI7DTZVDTNANCNFSM5A5SH2DQ>
.
I would suggest going for scenery first get the feel of creating everything and it's easy enough to test. Then when you have your process nailed move onto peep models and rides. Then by then we should hopefully have an easier way to swap out g1 assets.
I do like the idea of going for scenery first. Feels like the safest option. A lot of G1 objects have additional complications of having to fit together, or being highly dependent upon by other sprites throughout the project.
Starting with scenery would allow us to get comfortable with the setup. Additionally, scenery pieces are the easiest sprites to render. We could start out with a basic tool that only does scenery, and expand from there as the project grows.
If we order graphics based on difficulty, and required tools I would say we should loosely follow this order:
Static stand-alone scenery objects
Has no dependency on anything.
Animated scenery
Requires tools that support multi-frame exports.
Vegetation (trees and bushes)
Requires more research to figure out how to best render plants.
Building pieces
Lots of shared materials and shapes need to match with their counterparts, textures, and shapes for these needs to be carefully curated.
Misc G1 stuff
At this stage, we should be comfortable with our direction to impact some essential sprites (e.g: landscape).
Peep
Requires character modeling and animating expertise.
Track rides vehicles
Requires tool for rendering from all necessary angles, with separate peep renders.
Flat Ride
Requires tool for rendering animated rides in multi parts if needed, with separate peep renders.
Landscape is no longer part of g1 (okay it is but objects are made for it) so that is all ready for objects. Track is part of g1. Suggest also adding UI to the list. It would be good to make the ui an object i think. Also may as well structure this as follows:
Objects: each of the object types, dependencies and difficulty
Entities: Guest, Staff, (vehicle part is objects), duck, balloon, explosions, ...
Track: track, some bits of flat rides, supports, ...
Ui
Activity
nfeho commentedon Jul 26, 2021
I think we should start with recreating some stuff from G1.dat. I think that peep sprites should have a high priority, since almost all the ride sprites will rely on them. Along with peeps, we could start with supports sprites or land tiles (or other G1.dat stuff).
If we want to start with simpler and less game-changing sprites, we could start with some basic scenery items. Once we are confident with our sprites, we could tackle the ground sprites and other prominent ones (like Oli mentioned).
ExileFox commentedon Jul 26, 2021
duncanspumpkin commentedon Jul 26, 2021
I would suggest going for scenery first get the feel of creating everything and it's easy enough to test. Then when you have your process nailed move onto peep models and rides. Then by then we should hopefully have an easier way to swap out g1 assets.
oli414 commentedon Nov 25, 2021
I do like the idea of going for scenery first. Feels like the safest option. A lot of G1 objects have additional complications of having to fit together, or being highly dependent upon by other sprites throughout the project.
Starting with scenery would allow us to get comfortable with the setup. Additionally, scenery pieces are the easiest sprites to render. We could start out with a basic tool that only does scenery, and expand from there as the project grows.
oli414 commentedon Nov 26, 2021
If we order graphics based on difficulty, and required tools I would say we should loosely follow this order:
Has no dependency on anything.
Requires tools that support multi-frame exports.
Requires more research to figure out how to best render plants.
Lots of shared materials and shapes need to match with their counterparts, textures, and shapes for these needs to be carefully curated.
At this stage, we should be comfortable with our direction to impact some essential sprites (e.g: landscape).
Requires character modeling and animating expertise.
Requires tool for rendering from all necessary angles, with separate peep renders.
Requires tool for rendering animated rides in multi parts if needed, with separate peep renders.
Requires by far the most complex tool.
duncanspumpkin commentedon Dec 1, 2021
Landscape is no longer part of g1 (okay it is but objects are made for it) so that is all ready for objects. Track is part of g1. Suggest also adding UI to the list. It would be good to make the ui an object i think. Also may as well structure this as follows:
Objects: each of the object types, dependencies and difficulty
Entities: Guest, Staff, (vehicle part is objects), duck, balloon, explosions, ...
Track: track, some bits of flat rides, supports, ...
Ui