-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Planning out the Roadmap #20
Comments
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
<#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:
|
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 |
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:
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.
The text was updated successfully, but these errors were encountered: