game design/ proof of concept Dicidia

hello, me and my friends are developing a game of 3rd person action rpg.
So far we have figured the control schemes and its variety of movesets.

We also have referenced one game, just one game, as a point of start.

Problem now is that, we are thinking of moving towards one particular direction of development.
Whether to collect concept art, make animation proof, or go straight ahead towards gameplay design.

My friend the artist, decided it’d be best to collect concept art since it’ll be comfortable to visualize the mood, character, and the size of the game and its story.
Me as the programmer think it’d be best to design a prototype for playtesting variety of its control schemes, speed and maybe even create database for our state machine.
Both ways has its downsides, in which concept art being very literal so the guesswork rely on aesthetics…
While going to prototyping means we are lacking in assets, which means we may be stuck on mannequin for animations and variety of things…

The goal of this project is of course to create something entertaining, and visually pleasing.

But being our first project, we may need to avoid multiplayer nature and focus on linear storytelling gameplay…
Which then leads us to what it means to be visually pleasing and working in motion : animation.
We are thinking of making a proof animation, a trailer of sorts, and from there we sample viable gameplay attributes, from character speed, collission size, frame rate, maybe even FXes from our flat 2d content, and maybe actually try the rig firsthand in visual. Some sort of point of reference?

But of course, the third way, is very long and too time consuming. It may serve as good marketting content, and we can’t afford the final content to be too different from it.

What do you think is the best solution for indie developer like us?

Your first project can be pretty intimidating. I’d focus on a gameplay prototype first, and I’m sure others would agree, unless your game is more focused on the visuals/environment/story/etc than gameplay mechanics. In that case, I’d go straight to the art.

Also, this isn’t really the right forum :slight_smile:

Both of these should be followed - send the artist down his road and you design the prototype. Any simple (quick) assets you need - request them from the artist. Make sure he knows these are not final assets - just simple placeholders to put in place so you can continue prototyping.
The artist - on his road - should be gathering reference material, and setting up a pipeline for asset development. This is sort of prototyping for him. He needs to be conscious of how all the assets he creates goes into Unity and how to set them up for you to ‘code’ into the game.
He will need to understand how the physics work and which bones he’s going to want to animate and which bones he’s going to let physics control.
He should research physics, mecanim, lighting, shaders, particles, the difference between animator and animation, import settings for all assets.

When the artist has enough reference material - you both can sit and come to an agreement about aesthetic, style, mood etc.
The artist should also be researching mecanim and the animation system in Unity. There is a lot of content that will probably be animated in Unity that is a lot simpler than setting it up in an external application and importing it in. Just animate in Unity for simple - inorganic objects.

He should also be setting up some particle systems to get the feel of how they work and how to incorporate them into prefabs.

And lighting - this is a big one. The artist should be learning about lighting while you are prototyping mechanics and functional elements.

Yes avoid multiplayer - nuff said.
You can design a character controller that has public variables and hand it off to the artist to experiment with. The artist can create a simple functional character with a simple rigged stick man to use in your prototyping scenes.

Once all prototyping and design has all been ironed out - only then will you be ready to start your game.

This might seem like a long drawn out process - but it’s how professional game developers go about creating a game and also successful indie developers.

Prototype and design - not with finished assets - with simple stuff to use as place holders.
The artist will be testing, prototyping and researching as much as you will be.
The asset store is a great source for placeholder content (and finished publishable content) that can be temporarily used until you are ready to really start your game.

Good luck to you. It’s a great asset to have an opposite friend (programmer/artist) who is ready and willing to be a development partner - to put in the same time and effort you are willing to offer.

1 Like

which one is the right forum then? :> We could use all the good direction.

And to theANMATOR2b thank you for the elaborate thinking and direct conversation.
Your experienced commentary will move us way ahead in our project, and we will be documenting it.

As i said before we are very new at this, with minimum funding, and little channel to release and sell our game. We are still figuring many thing, like how to make the game replayable by providing some sort of skirmish or exhibition mode of gameplay with independent AI entity to compete with and variety of objectives to play in, the right style of art to correspond with the right audience or age range, and variety of things, so the weight of the designing process somewhat forces us to
pick between focusing one aspect of the games first…

And being a small team, our communication is nimble and fast, allowing us to connect well in either art or programming and get jobs done faster.

For lighting and aesthetics, art is somewhat a subjective matter, and its appearance is relative to the subject nearby it.
or so said by my friend. We already crossed that from our checklist, being fancy and super polished.
We are heading to something more indie and lowpoly.

Currently we are also building rig for the prototype character…
do you have opinion or idea on the range/scale that constitutes a good rig and skinning (for humanoid character), ready for games and somewhat, fault-proof in presentation?

1 Like

Sorry, I hope I didn’t come off as rude - I just don’t want you to get your thread closed because I think it is a good discussion :slight_smile: Probably General Discussion would be a good place for the thread? Maybe a mod will move it for you.

Good luck on your project - hopefully when you have some stuff to show off, you’ll post it here so we can check it out :slight_smile:

Sorry yanuaris - I may have missed where you explained the type of game this will be. You mentioned skirmish, but I’m unclear if that is specific to only one type of game. :slight_smile:
The rig really depends upon how detailed and complex you want the animations to be.
It’s a no brainer - if you want to be able to retarget and have the most fluid retargeting process - use a rig that matches the Unity humanoid bone structure. You can have extra bones, but that comes with more work to get animations to retarget accurately, and more time/experience knowing how the system works. You can retarget with generic too, but its more involved and susceptible to inconsistencies.
If you are doing a fps - either choose a fps arm rig for the player view, A two rig setup where it is switched out depending upon the player camera pov, or a full up humanoid rig so there is no disparity to deal with for swapping rigs, or having to have two rigs one for player pov and one for alt player povs.
Since I’m kind of an animation nut and will stare at in-game models and awesome environmental effects just to see the cool motions and movement, I’m all about animation so the more complex - the more fluid - the more clean the transitions - the more I geek out at it. :slight_smile:
But I also understand only building things to the complexity needed, so If you can animate a hanging satchel with the common biped rig - do it - rather than making it a separate object with it’s own animations, or adding bones to the base character rig to give the satchel proper animations.
Also realism adds complexity - so if you are going for a stylized concept or a less realistic look - animation rig complexity can be reduced if needed - OR can be exaggerated for effect.

Ah, this is overall a good idea. I’m sorry for the misunderstanding, english is my not native language and i tend to blurt out jargons however it sounds cool in english…

I understand your points, being a very nimble team, there is a tendency to reach for the best and forgot the original point.

how would you suggest us to approach this in our GDD then?
In point form, step by step? what should we consider first and next to the last when building a rig, and finally actually building the rig?

my fellow friend is also a geek in animation so he might love to consult you more in the future, especially after seeing your reel…

HAHA - I’m available for discussion here on the forum, or PM if needed.
That animation reel is nearly 5 years old. Man time flies. :slight_smile:

I’d suggest going as lean as you can initially and building upon and beyond a base humanoid rig - only if needed. Prototyping all the way into Unity and setting up several characters with different rigs is really the best for your unknowns. Setup the state machines and everything. You will gain the answers you need by just - doing -
The work doesn’t have to be final - it’s just like game mechanic prototyping, but instead of testing out the mechanics - you are instead testing out the pipeline. Workflow (pipeline) has to be properly worked through - then once you have the workflow you desire and all the hiccups ironed out - all other questions/options about rigs and resolution of the rig, models, accessories - will be resolved.
You will learn the answers to your questions best by prototyping the workflow.

Hope this helps - some times a proper nudge in the right direction helps.

I really can’t help with GDD - I do it different than anybody else I know. GDD gets written while prototyping is ongoing. Update the GDD when you eliminate aspects of the game that don’t work, and update when improvements are done.
I also keep a morgue at the end of GDD that links back to the specific sections. So when I descope something, or change something - it is documented - “Hey why did I do it this way?” The morgue tells me why I scrapped a specific idea or element.
This is just how I have worked in the past - it works for me, but you might have a better process that fits your needs better.

I see…
we actually are going to template the game based on a popular franchise that features variety of monsters
and humanoids, quadrupeds, machines and all kinds…

it’ll probably just be one from each archetypes first… and maybe we will budget the polygon by about
500 tris or less to just genuinely illustrate our capacity. Thanks to your insight, we have decided on many things to remove
before our team is fully capable.

As for the GDD, your suggestion is noted, currently document is leaning towards printouts and is very unforgiving in content updates… So having this morgue of links and references is very very great to actuallly worry less about what we might miss. thanks alot!

Do you understand about IK handle and spline?
We happen to encounter problems with spline…as it deny our character’s torso from rotating. Very inconvenient as we have to redo the whole thing again.