Separate names with a comma.
Discussion in 'General Gaming and Hardware Forum' started by Gaspard, Jun 7, 2016.
You're not the first, you won'tbe the last
I don't care for Steam, so in order to facilitate a GOG release I created a GOG wishlist entry. Please vote. I don't know how much attention GOG actually pays to their wishlist, but if nothing else it may bring this intriguing game some more attention.
Any chance you could give a rough example of what kind of choices and skill tests there might be involved in conflict situation like that (aside from what's been shown already)?
Sweet, thanks! Five votes already
There is a blog post coming up eventually that goes deeper into the skills and check and rolls and whatnot. Meanwhile, another tidbit of our art pipeline and philosophies from Mikk:
"Texturing in-game assets"
Since we’re making an isometric game there’s always a constant struggle with readability of shapes and detail. Things get cluttered upon things upon things upon things and because isometric perspective lacks “lens depth” (the picture doesn’t get distorted) it’s bound to get chaotic. Thus we have to make sure that every model, silhouette, and texture of every in-game background and asset is clearly and immediately recognizable to the player.
Aside: Texture Frequencies
Think of a dirty wrinkled face on a smiling old man. Up close it has small specks of dirt which, once you start moving farther, start to meld into the face since the receptors of your eye do not distinguish them any more. At some point in the distance also the wrinkles disappear. In computer graphics we usually get problems at distances on which these kinds of repeating details start to disappear into noisy weird patterns. You might want to look up Nyquist Frequency if you are interested in more theory about this. – Irve
There’s also the added bonus of in-game camera at play, which basically means that all of the detail has to “work” at all levels of zoom ie. a radio and it’s texture has to look the same in the close ups and long shots. Woo!
Now with the “Why?” out of the way let’s talk about the “How?”. Our game has this painterly or as Robert likes to call it “Paintshading” look to it. All of our backgrounds are modelled and textured in 3d, then rendered, then painted over by Aleksander to give it that handmade feel. In-game assets are real time models used within our game engine, thus the applied texture to the them has to look painterly from the get-go. This in turn means painting directly onto our unwrapped UV layouts while trying to be as artsy as possible about it.
Below you see a Villier Pepperbox, a complex gat for a complex man. Just to be clear – the model of the gun is the same throughout all three of the variations.
The first iteration had me painting a somewhat realistic version of the textures – the wood looks like wood, the metal looks like metal, and there’s a decent amount of added detail. As soon as I dropped it into the engine the problem became obvious – it didn’t fit with the visual style of our game. To add insult to injury, since the gun is such a small asset, it basically looked like a bunch overly detailed of noise in the grip of our main character.
The second iteration is a more stylized version of the previous – now the wood and metal feel like wood, instead of just looking like it. The texture is a lot more painterly and I also introduced a bold dab of green into the hand painted mix. Stylistically it wasn’t as much of an eye-sore in-game, but there were still some issues of readability.
The third iteration is a blend of both. Some of the details are exaggerated (ie. the finger rest and the grill) while others were removed entirely. Aleksander advised me to emphasize different parts of the gun by adding a stroke along the shorter axis. The firing mechanism and the round-barrel are a nice example of this while the long barrel received a painterly stroke along its longer axis to make it seem longer. I kept the dab of green and smoothed it out with some off-white milky blue to give the barrel a nice sheen.
This is now in-game and visible in one of our screenshots as well.
Pepper boxes of that size only using 3 barrels is kinda underutilizing the platform. I doubt you'd find many of those in real life.
But neato regardless.
This project is all kinds of fascinating, got some really cool unique angles including in fields way underexplored in video games, and looks really good stylistically to boot - the shaders used to produce those shots give a real cool painterly look. Was excitedly chatting about this project with a fellow inXile designer, you got our eye!
@Gaspard feel free to ping me if you wanna get in touch, if you feel there's anything I can do to aid your efforts!
@Gaspard You guys may want to set up an Indiedb page for your game.
I created a very basic Giantbomb page and will get one submitted for Neoseeker soon. I think the more places you can get free publicity, the better..
This is looking mighty interesting. A breath of fresh air setting wise. I hope you guys are able to deliver!
True. But the asymmetry of three barrels looks very nice If you look up real life reference then you´ll see that that even in this timeline the gunsmiths have underutilized the pepperboxes. Perhaps also because of them damned aesthetics or a nagging client...
Oh snaaap! Thanks! We´ll keep that in mind. Guys here are all kinds of excited to hear about that
Thanks, man! Taking notes.
Thanks. Same here. Aim high....
For this week´s dev blog post our animator Kristjan Bobkov writes about motion capture and how we´re not really using it Also, at the end of the text bit check out how the Grand Designer and Duke of All Writing acts out a scene snippet from the game.
Hi! I am going to briefly talk about how we use motion capture in our development. Now our final playable game will not use motion capture data in-engine at all. Hurray! The reason for this is that it’s not fun to retime mocap and make it loopable if necessary. The animation curves on the mocap skeleton contain a keyframe on every single frame making it a lot less manageable. It is possible to optimize mocap data but the ending result is going to be unpredictable and jittery. So instead we use a custom rig to drive the skeleton, allowing the animator to put in keyposes, control the in-between frames by graph editing and achieve a completely predictable outcome. Also we can’t use mocap because at some point we could decide that we need motion that is really difficult for the mocap-actor to perfectly perform.
Like the title says we somehow actually still use it. Yes, but only as reference. It’s a lot better to see motion from every angle. We also use video as reference and sometimes it’s enough to just look at a coworker or some random people on the street acting stuff out.
When we started working on animation, we got an idea that maybe mocap could be a good way to really quickly get placeholder animations. Unfortunately it was too time consuming and we were not sure if we should invest in proper mocap equipment. The cheapest and fastest way for us was to use two kinects and they did a pretty good job as seen below.
This week´s blog post is from a fresh face to the blogs and forumses, one of our trusty code-monkeys Markus.
"Audio & Action"
Hi! I’m a programmer. I do this and that. I implement, integrate and innovate. Let me tell you some tidbits about sound and cutscenes.
It would be great if all audio related code and components could operate off of a single central sound manager. Then some customization could be possible in Unity so our sound pipeline wouldn’t be a convoluted mess full of tiny changes.
New conundrums arise while attaching sounds to stuff. For example a case where an action can be performed quickly in succession:
Do you just play the sound each time?
Do you just cancel the effect and play it again from the beginning?
Do you crossfade the second bleep-bloop into the first bleep-bloop effectively making a single bleep-bloop that still sounds nice but indicates a repeated action?
Do you do something completely different that really fits the visuals but is kind of tricky to construct?
All of these solutions have their uses in certain situations. First two can be implemented fairly quickly. The third one – which seems like a nice general solution – needs to keep tabs on all sounds that are currently playing and perform a crossfade of different sounds. The fourth approach can be a combination of anything and everything. That’s why we are using Master Audio for audio management. It already has these kinds of functions and it’s a component we would have had to craft ourselves if it hadn’t already existed.
So once we had our basic necessities covered we could focus more on our specific needs. The camera and character moving to certain spots should change the ambiance and music in a meaningful and mindful way. So we created something that could be called a sound map! A collection of triggers embedded into the earth which send directions to Master Audio through an interpreter which has information about the current soundscape and keeps the changes logical and deliberate. This sound map can hopefully solve increasingly complex audio situations with relative ease.
Actions that the characters do are more often than not intricately weaved into the dialogue. The dialogue system and articy have “stage directions” (third party support between assets and environments really makes me feel warm inside) which are tools to make sequencable commands. So with a little preparation it would be possible for any member of the team to use these high-level commands to program the cutscenes. This means it’s important that different animations and actions automagically fit together so the whole system is as dynamic and modular as possible. Otherwise our animators would have to redo every animation after each layer of polish.
That’s it for now. Until next time.
Damn this name!
I ignored this thread because I thought it was rubbish about Furries, but on further study it's (merely) an interesting game! One that seems to be very promising... by the way, how are the endings going to be work? Fallout style, just a single ending, totally different endings (but only one each) or...?
By the way, are some of your developers Estonian? Because it's a beautiful country.
We all did.
I was hoping...
Hey, no hard feelings. About the C&C: based on your actions the endings will be different
Edit: Yup - 99.9% of the team is Estonian, born and bred. Yeah, Estonian countryside can be pretty great if you know where to look. When were you here?
At least the devs are taking this seriously. The bunny in Gryffindor colors is Jaagup, our coder, and the bespectacled amphibian is the Art Lead Rostov. Behold, Casual Friday at the Fortress Occident videogame studio:
(Source: Fortress Occident Instagram feed)
This is simply marvelous.
And the game looks very interesting.
Thread pooped I thought this would be really interesting and it is for a different reason. Looks like a pretty neat game !
2012, in Narva.
I saw the two castles, crossed the border (got a Russian passport) and saw the recreation of the Battle of Narva, between the Swedes, Estonian raised militia and Russians. Great stuff!!!
So... one ending that's changed or the Fallout style different endings for each area?
Still, that's great!
Oh, sweet. I´ve mostly passe through Narva on my way to and from St. Petersburg. Haven´t seen the battle though. The guy in the bunny suit is a big-ass LARPer.
Meanwhile our art lead Rostov (that fish) says he´s neck deep in character modeling.
Was about to throw a hissy fit because of the title. Considering that a lot of people also misinterpreted it, maybe a title change is in order?