Thursday, 24 July 2014

Testing Testing Testing

Preparing V1.008 build, and today we've done more testing than coding, and that's saying something. More testing Friday too, looking for show stoppers and solid reproducibles.  A short blog today as I have an evening shift to get through, but I wanted to share a picture as promised.


One of my pet peeves to be tackled when I start the V1.009 work is the way terrains are textured. Right now a single channel controls which of the five textures should be painted to the ground. Unfortunately this means there can be zero overlap of arbitrary paint types and you get a sequential blend through the texture range. I will be thinking about how I can provide a good blending system for terrain textures without incurring more performance hit or requiring more resources. Eventually the goal is that you could blend the dark grey coal texture directly into the light pave texture without stomping through the immediate moss, mid and grass textures.  Using several channels of a texture slot would do it, but I don't have too many of them to spare, and I am using all 16 texture slots for terrain!! I could plum for 32 slots but I think some cards would fail at that, slow down the render even more and no-one will thank me for it.  There is a way (several I guess) I just need to think one up!  No blog Friday evening as I am leaving the country and passing through another for the weekend, but will resume and return on Monday to help answer any V1.008 release questions!

Wednesday, 23 July 2014

Very Loooong Day

Blogging late at night as my work run on and on this evening. Created two builds today for testing, and getting very close to a final V1.008 beta. Just needs a bit of quality testing we should be ready for release!  That said, it's well past midnight and as you know my ritual of getting up to do a normal 9 to 5 means it's way past the mark, so I will keep this blog brief and hopefully provide some nice visual shots on Thursday when I have more time to test the build and smell the roses.

I did some research into HBAO (an improvement over SSAO) but could not find any DirectX9 or Pixel Shader 3.0 source code to help me get it implemented. If anyone can locate this code, I would be most grateful!  If you find a technique that relies on DX11 or deferred rendering, then I cannot use it but you can dig out a nice HLSL shader file and accompanying source code that works with DirectX 9.0 I will be very happy.  Still doing the pre-bake but for users with higher end graphics systems, having instant ambient occlusion as a real-time shader (as heavy as it is) might appeal.

Won't bore you with the tweaks done today, but two big ones involve new IDE code which prevents the FPSC-MapEditor.exe code from launching multiple times and Simon managed to reduce the GPU video memory hit by around 400MB which was an amazing saving, and we suspect there can be more to save if we dig deeper!

For now, going to finish this uploading and catch some Z's!

Tuesday, 22 July 2014

One Of Those Bugs

A good day of bug tweaks and fixes, but some 30 minutes before the end of my working day I hit one of those 5 minute bugs that turned into an hour, and then ate into the time I should have left the office. You get them from time to time, and it's always just one more quick code line change and you're finally done. Well in hindsight it was top ambitious to introduce physics weights and frictions and expect it not to screw up every other aspect of the physics system, and fail to achieve the original fix in the process. Phew!  Now 30 minutes past the hour, I've decided to cut my loses restore the functionality that was in before but keep the code that I will need to return to at some point. I think the bottom line is that setting the mass of the physics object AFTER the initial creation takes more than a single line of code, and the actual values involved are themselves a mixed bag. It seems I was scaling the dimensions of the object down, but in doing so the new smaller values when multiplied produced even smaller results, making the 'volume' measurement meaningless, and yet this value is being used to control the mass in the present physics objects. It is not supposed to work, but it is?!  I will need a fresh day and a fresh brain to think through this strangeness, but for now I am going to start the build, test, installer test, process which I should have started an hour ago and hopefully finish before too long.  Also the jump seems to have gotten itself broken in the last day or two as well, which is another odd thing. Was it me, or some other check in code?  We will see in time!

No pictures today as simply no time to do anything visual, it's all been deep dark code work, which does not make for great screen shots!  Often I continue coding while writing my blog, and in doing so I just discovered why the jump stopped working. It seems when you entirely switch the water off, the jump code was being skipped. I changed it to allow jump if you are above the water line OR if there is no water in the level, that is, you can be in a deep ravine that used to be under water but jumping is now allowed.

Hopefully the build will pass the quick test and we can get it out to the internal alpha testers to see if it's heading in the right direction, that is, once I've tested my own code, checked in the teams code and tested that too. Phew!!

Monday, 21 July 2014

A Day Of Mostly Talking

Amazingly, I clocked about 4-5 hours of talking today!  Shows how many major decisions had to be made in light of our demo release last week. The decision is one that I hope will please everyone reading my blog. We have decided NOT to pull the demo, and instead spend some weeks improving it based directly on the feedback from the community.  Our objective was to show the great results you can get from using our game maker, and we did not make the grade, so we're going to continue working on the engine until it does. Remember the marathon we went through to get performance great on low-end hardware, well now we're looking at the visual and game play feedback with the same venom.


The first tweak to go in the demo is the brightness and contrast adjustment, and when you put the old and new renders side by side you can see how much nicer the new one is. I don't think we have any debate here, and we have also added F2 and F3 controls so you can adjust these settings to suit your own project levels.


I achieved the new setting values by taking a screenshot and putting into PSP and tweaked it until I was happy with the balance. I then migrated that know-how into a post process shader to achieve the same graphical modifications, but this time in real-time.


My next assault on the dated visuals is to make our entities blend much more naturally into the scene.  As almost every game has some form of baking step, I figured I would research my own for inclusion into the standalone export part of the engine's tool set.


I only had a few hours over the weekend but started a quick prototype which applies something called Ambient Occlusion mapping to the brick stack and to the inside of one of the buildings.  Here you can see ambient occlusion around the creases of every polygon and also a point light which is casting the shadow. The scene does not get have it's normal mapping, specular, diffuse coloring and other small touches but you can clearly appreciate how these baked shadows will contribute to the final scene.

My plan is to create a system which can take a game export, extract the static geometry, batch them by locality and texture groups, apply the baking process, then insert the pre-baked geometry back into the level. I still need to find a solution for baking shadows on the terrain (which is a woefully stretched mega texture right now) and somehow keep the memory footprint for a whole level worth of light-map textures down.

I am also going to add the UZI and SHOTGUN characters into the demo as well to really mix things up, and I am sure some engine features will come from implementing those and getting the AI just right.

At the same time as making these engine improvements, I will also be recruiting a top artist to help me blend in the demo scenery for a more pleasing layout. For example the left wall in the first screen shot is a sharp line intersecting the grassy floor which is much too clean. Adding some floor textures to blend with the wall, maybe small grasses or fallen rock pieces will blend it better into the scene.

While I work on the engine and visual elements, my Ravey and Simon team will be working on the remaining editor and engine elements relating to the main list to ensure development of the strictly editor based features proceed at pace as well.

Our hope is that we can put out another demo at the end of this enhancement work that will not only improve the perception of the product, but provide additional features for the next major build. It will also mean you will get extra assets, more in-game features and a much nicer end result when you have finished your masterpiece and ready for the pre-bake.  Don't worry though we are not inserting the pre-bake into the test game process, and your real-time shadows will still work in the improved engine, only in the standalone game export phase (at this point). There might be calls to have the pre-bake as a button in the IDE so you can see what it looks like on the fly, but bear in mind industrial quality pre-bakes can take hours :)

Final bit of good news. I got a good slot and cool interview via N4G site over the weekend, which was nice: http://n4g.com/news/1549410/fps-creator-reloaded-gets-free-gameplay-tech-demo

Friday, 18 July 2014

What Did We Learn Today

Another week, another build, and for this week perhaps another lesson. A question was put to me today, backed by the feedback since we launched the game demo. Should we pull the demo off the site?  Personally I think it's a great demonstration of game play and what anyone can do with Reloaded in a very short amount of time, but it seems the wider world are looking at it as a direct comparison to any other FPS game out there. Certainly for the modern FPS games such a comparison is not complimentary for us, and may even damage future pledges. I am interested to hear what you guys think, keep it up there as a demonstration of where we are now or pull it and only return it when it 'looks' better and has more 'game' in it. Opinions welcome.

Is it something as simple as adjusting the gamma, brightness and contrast, improving the render and assets themselves or is it more about improving the game play?

The current game demo for Reloaded

For a quick preview, I used my favorite art package to play with the colour balancing of the current opening scene, producing this:

Increased gamma correction by 1.6, brightness up 33 and contract up 55

I recall a few requests for a 'brighter, crisper' visual, so is this something we should be spending a little time on?  I am also looking into the modern methods of lightmapping games these days, whether it's radiosity mapping or something more advanced.  Might spend a few hours over the weekend experimenting with some lighting effects to see if we can get the visuals up a notch without re-doing the entire asset set.

On today's news, the build is almost ready, just doing the last few hours of testing now. Hopefully the alpha testers will approve :)

Thursday, 17 July 2014

It's Been A Bad Day - Please Don't Take Your Picture

Don't worry about the title, I'm just listening to R.E.M and it's late ;)  A normal day of development, getting stuck into small fixes to make the engine better and better. Also been reading the honest feedback on the demo we released, and it's getting clearer what we have and what the expectations are for most people.

We've had a few salvos along the lines of our engine looking like something from the early 2000's, such as this one:

Copyright Counter Strike (c) 2000

Personally I think we have a few things in the Reloaded engine that beats this visual, but we can take our lessons from almost any source (pardon the pun). Or something more recent, I dug out the same FPS brand 12 years later:

Copyright IGN & Counter Strike (c) 2012

Again more things to learn but not a radical departure from what we have now, minus the graphical assets which will come in time with model packs. I did notice a huge abundance of baked lighting in the scene and heavy use of bleached out backdrop spheres (the buildings in the distance are painted on the skybox). If you want a button which takes an hour or two to bake in all shadows and ambient occlusion into the static geometry, we can do that if that's what you need.  I'd also argue our pistols look better than the one in the above shot (but I am bias).  

I urge anyone who suspects the Reloaded engine looks like something from 2002 to send me a screenshot so I can dissect it and find out if there is any technique we can use to close the perceived gaps.

User Created Level in FPS Creator Reloaded (c) 2014

Aside from the need for more and varied assets, I don't think we're THAT far back in time, but I am willing to be taught a valuable lesson in visual fidelity of games over the last decade if you are willing and ready with shots :)  I'm not saying anyone is wrong, I'm just suggesting it might not be as far back as 2002 ;)

Just finishing off some emails, this blog and maybe a fix or two and then retiring for the evening. Friday is the day I wrap everything up and do some last minute testing before we give the build to the alpha testers and competition winners to see if we caught most if not all the remaining glaring bugs for V1.008.

Wednesday, 16 July 2014

Post Launch Polls Are In

I realized this morning that I had neglected to post a blog yesterday so 'oops' for that! The day after a demo launch often involves running around making sure everything worked, and I am glad to sat that it did. The reaction was mixed, with some positive messages coming out and some scathing insights as well. No-one likes to hear criticism, unless you're trying make the worlds easiest to use game creator :)

Had a strategy meeting today to discuss the launch, the early feedback and the plans moving forward.  As one mind the team does feel the visuals are falling short of the general expectation of the general public. With titles such as Titanfall knocking around, it's easy to see why the bar is set very high these days and explains why we've had more than one comment putting the current game somewhere in the previous decade. From this, one of the questions raised was whether we should even be looking to match or beat these top titles, especially for a small team with a limited art budget.

We still plan to have something for Steam in September, but what form that takes will be the subject of further discussion in the weeks to come as we complete V1.008 and V1.009.  I could reveal more, but I want to give the ideas we discussed time to settle and gain gravitas before I promise you all some lovely vapor.

Releases and feedback aside, our character artist has not been idle and is starting on some re-skins of our soldiers, adding more variety to the combat area.


A hostile bunch these guys, featuring a pistol Pete, rocket-man Rodger, shotgun Sam and Uzi Tom (names have been changed to protect the guilty). My suspicion is that if we added these guys into the new game demo, doubled the speed of weapons fire and reloading, tripled the number of soldiers and made it a two-shot kill combat system, it would get the heart pumping!

One feedback that did resonate with me, and one I want to resolve as quickly as possible, was a comment from one reviewer who stated that there was a "disconnect and weightlessness" in the weapon usage. If anyone agrees, can you give me your insights how this can be resolved. Something specific that I can get an artist / coder to look closer into and come up with some adjustments.

Our timetable is still set to get you the V1.008 build next week so not much longer to wait before you can make your own versions of the demo game!