2nd Year Games programmer at Teesside uni, on course for a 1st and looking for a placement year.
Loved modding for source but couldn't find the time to carry on after summer hols :(
That looks really nice. Taking the grass colour from the texture works really well from this game, because you're just as often viewing from above as well as glancing or parallel to the terrain; makes for really nice distance transition as well.
The whole grass system also sadly reminds me to download the Black Rock - Pure foliage rendering paper and other papers before the site disappears with the studio :(
Is it the same stipple pattern for each sample? the blur looks very checker-ed / regular.
Also, will you implement percentage closer soft shadows (closer the receiver to the blocker/caster the sharper the shadow) - how would that work with overlapping blockers, would it need a 'deep' buffer?
I'm not trying to troll, I'm trying to learn from someone who's work I admire :)
Getting a new pc next week so I'll finally get to try my pre-order - yaaaaay.
Looks great but regarding the trailer you really should show the build / block placing function earlier*, after showing the first few environments I though the platforming was pretty standard and was ready to switch page thinking I'd gained all the info I needed** - luckily the art style kept my attention a bit longer.
* I realise the collecting of blocks was displayed but without context it's easy to miss.
** Even though i'd read the minecraft reference up top... people's attention spans are often short for first impression.
Very nicely presented game and trailer overall though :)
How do you handle ledge grabbing when there is another surface above?
Wouldn't it be better to do a vertical trace from within the colliding object to find the top/ledge (exit) than trace down from some random arbitrary point to find the entrance?
I guess the next step is too check there is actually space to climb up onto the ledge once you've grabbed it.
Still cool tho, nice ik :)
Will definitely be playing the alpha once I get another pc, pre-ordered but my current/old pc is majorly dead. Looking forward to a bit of script tinkering :D
It's great that you put attention into solving basic usability / polish scenarios like the camera collision that so many commercial games take a half arsed approach to :)
Looking great in general - really need to try out my pre-order!
Really like the 1st screenshot, nice art direction.
Looks great. Reminds me of Zelda, hope you take that as a compliment :)
Because the mesh was the physics (collision) mesh not the mesh used for rendering.
In response to your other point, I assume the leaves use a vertex shader paired up with a texture (representing the stiffness) to physically/procedurally animate/displace. Although I didn't see them animated so might have misunderstood what you meant.
After eagerly watching you pump out so many news pieces this week I finally joined the ranks of preorders :D
Wish the designers and artists I work with were as talented :(
super work :)
Can't wait for the eventual implementation of ragdoll -> animation that this kind of stuff goes towards. It's a bit harder to get it looking natural but will really help the visual flow in such a physically based combat game.
@MrtwovideoCards - Nice work :)
I think modelling temporal glare would benefit your mod's pursuit of more believable lighting:
(Probably with a less detailed / more approximate implementation though! - also they're halos seem a bit too intense / visible but my eyes probably aren't the same as theirs!)
Or even without the temporal effects just regaining some of the glare patterns the industry seems to have lost when ditching sprites for realtime bloom would be nice. Maybe just a pick or gen a nice pattern and scale it with light intensity n wiggle it with the dot product of the eye / eye->light vectors.
Bloom does have it's place and is quite believable for larger areas but for smaller light sources or the glint on the edge of shiny surface like car paint or a polished metal a distinctive glare pattern would really add to the image.
Keep up the good work :)
Many of sources apparent difficulties are just niggles that snowballed or people struggling because it wasn't completely written for them already.
In reference to any actual vehicle problems the Empires team are on a mod license, not commercial: So Interwave have the advantage of more (full?) engine access, more support from Valve. And as a commercial entity they probably have more manpower and possibly more experience.
I think there are some very good ideas there but they may not have been used to their best.
UV stuff great, combining props good, making large heavy objects static good.
However Combining props into one model so their bounds check would always be true if any part of the group was visible even though from different approaches into the room you wouldn't see all parts of the group - would increase drawn geometry. Although draw calls are a large bottleneck, if a level is designed well and you guide vis with hint brushes etc then many of those draw calls wouldn't take place. PVS! - we're not in some fully destructible, dynamic environment, deferred rendered engine :)
Making those blue bins static is confusing for the player.
Try pulling the blue bins so the are up against the green or make some lying down - anything to stop it looking like you should be able to knock them over.
The bins hidden round the corner should probably be a separate group, for better vis and for re-usability; there will doubtless be more corners and flat wall spaces where you want bins but few that have that exact layout you have there.
Sorry if for the negativity, just trying to help, and inform other users who may not have your insight and then apply your advice too liberally :)
Actually, Considering more complex brush work and static meshes (and the effort involved in navmesh-ing them and the fact Valve uses Axis aligned quads for navmesh) - and the fact the valve method would be implemented regardless - the Valve hull trace method would be the way to go.
Hi Jlea, a few weeks back Shirk pm-ed me saying you were interested in vaulting. I started a decent write-up but never got round to doing diagrams which were somewhat essential.
Anyhow, I lost my old code and it was crap anyway...
Basically considering the majority of the world is static - the best way to go about it is using nav meshes: one for a vert face, one for horizontal face, one for a face border. A vertical face would allow wallrun, kick-off etc, and a border on a vertical face would allow you to vault. This is similar to the approach BRINK took: Brinkthegame.com (see UNDER THE HOOD: HOW SMART WORKS)
As for dynamic geometry - props etc, I recommend the Valve left4Dead zombie approach as documented: Valvesoftware.com page 31.
I'd go for nav mesh over hull traces because of high run-time cost of collision queries and the ability to utilise it for locomotion path planning if you want the full brink smart style.
That was a reply to zhujing, but didn't seem to indent.
Anyway - love the music, does feel like a crash tune :)
That was pretty awesome :) Think getting up animation or w/e physics blending solution you do needs a little work but as for the core of the video the kicking, reaction and flow it was super
Looks pretty good :)
Totally agree, trying to bring down the big O cost and writing with cache and memory access in mind should be the first priority, however a vector and matrix library is fairly essential in a game engine and you might as well make it a SIMD library.
Isn't OpenCL geared more to systems where the CPU and GPU have similar capabilities? (Which might not reflect the whole overgrowth userbase) Where as SSE is a pretty safe bet and can easily be used for just a few math operations rather than openCL system wide work tasking. (I don't know much about openCL :))
haha the second one from left bears an uncanny resemblance to a science technician from when I was at school; without the gun holster obv.
Really nice concepts :)
yeah bumped specular highlights and the crosshair give away the screenshot origins - but it's a pretty cool idea taking the map at its current stage and then painting over it to design / illustrate the final direction, and looks well executed.
ooh, this just got my attention - tracking... pretty sweet modelling and anims :)
5 and 8 :)
The view-sway is nice, esp the consistency such as using it with the pump of the shotgun.
The m16 needs a fair bit of work on the anims and positioning - could come into the centre horizontally and a bit closer to the player and down a bit - but that's just my preference.
Maps are looking very polished.
Keep up the good work :)
@3pidemiC - They're not acting with hubris so there's no need to be cruel.
does look good but looks like the character design has deviated a fair bit from the old mod concepts - it's fair enough it's a new team etc - however it's those kind of things that make/made it Nuclear Dawn as a recognisable/distinct brand/icon/franchise.
I just think they look too much like every other soldier in every other slightly futuristic/modern fps.
I still think the game as a whole looks great and look forward to the trailer :)
I think this trailer made the rebel gameplay look a lot more more fun; in the last one it just looked like u ran (really fast) circles round some retarded soldier ai; however in this trailer it looked a lot more team based and a more tactical pace.
Showing off breach also reassured anyone doubting the map quality after watching the dev texture maps - Although citadel shows pretty good form in dev texture, you can easily imagine it finished to a high quality :)
but lol at 1:08/1:09 - dodgey muzzle flare attachment/orientation
yeah lol, that's like saying the orig sdk only allowed fps - it's up to you to change it. and the codes in the old codebase if it's not in the new one
regular animator designed animations? They even have an ingame/engine animation editor haha.
much layering and some procedural I guess cos overgrowth team rock