OpenRCT2
Planning out the Roadmap
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).
This seems like a very reasonable starting point yes. I fully agree.
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 https://github.com/OpenRCT2/OpenGraphics/issues/20#issuecomment-886631688, 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.
- Track Requires by far the most complex tool.
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