Code a game competition - Sep 1st to Oct 14th

[Xerra]

I just realised I compiled Rockman with the interpreted build rather than through the much tighter compiler for the released game. I've not tested to see if it's going to make the game run a bit smoother but I also have a minor bug to fix which makes it worthwhile me doing a spot of work on it.

Will it break the rules ref modifying the game if I recompile it and fix the map bug? I'll be adding absolutely nothing apart from fixing the bug where the player character appears on top of the in-game map.

[Qube]

@Qube>>if you can't take a constructive critic / suggestion, whatever... (->for a simple gameplay, with a not too detailed scene, it is strange that it is so slow... that's all i am saying)

your game is cool nonetheless.

I did say in the description of my game "To users of integrated laptop quality video cards, you may need to reduce resolution and / or quality as it's quite graphical intensive."

It's not strange that it runs so slow for you. I'm surprised it even ran at all to be honest. The reason it's slow on your 7 year old 368mb integrated GPU is because there are multiple lights, many real time shadows, multiple full screen shaders and zero optimisation. I would never expect it to run well on anything but a half decent GPU with at least 1GB of RAM. Yes, the scenes are not complex but that's not what is causing the slowdown for you, it's all the other things.

I'm sure if I baked all the lighting, took out the realtime lights, turned off all the fullscreen shaders, put the shadow quality down to nil, reduced the texture sizes then sure, it'd run a lot better on your GPU. But that was never the goal of the game. It was just a learning experience which luckily I could turn into a game for the comp.

Will it break the rules ref modifying the game if I recompile it and fix the map bug? I'll be adding absolutely nothing apart from fixing the bug where the player character appears on top of the in-game map.

Bug fixes are allowed. How you compile it is up to you as that's not an additional game feature.

I know it is technically "adding new features," but at the same time could be considered a "bug fix" as it would make an unplayable game into a playable one.

I don't think people would get too anal over something like that. I'd just add in cursor key movement and call it a bug fix for international keyboards. By additional features I'm sure we're all thinking more on sneaking in extra levels, game features, etc.

[RemiD]

@Qube>>i don't think it is the per pixel lights which are slow, it may be the shaders (for what ?) or the real time (per pixel ?) shadows... is it possible to disactivate the shadows ? or others graphics effects which are not essential to the gameplay ?

[Qube]

@RemiD - Out of curiosity I'll take out all the lighting, bake the lightmaps, take out the particle effects ( they have lights too ), reduce shadow quality, remove all post processing and see how that runs on your laptop. The explosions have lights too so I'll take out the lights on those.

I think the game will look like a really early DirectX7 game but I'm curious to see if it runs any better without all that stuff in. Give me up to an hour to rip it apart

Note - This will not be used for competition judging.

[RemiD]

@Qube>> i have played with Unity a while ago, and i bet that it is not the per pixel lights, you can definitely use real time lighting even on a low end hardware (preferably vertices lighting than per pixel lighting)
i bet that it is either the per pixel shadows (or stencil shadows if you use another lib), or a custom shader (what others graphics effects do you use ?)

btw, if your tanks and ground parts and wall parts are subdivided enough (enough triangles each xunit), you don't need to use per pixel lights (but that's another story !)

[Qube]

@RemiD - Try this quickly cutdown version ( 59mb ) - If you could try that at different resolutions / quality settings. Hopefully it'll run a lot better.

I've stripped out all the lighting ( I think ). No doubt half of it could go back in just fine but we're just testing the basics here. I've also reduced the texture sizes as most were 2048x2048 for silly things ( yup, zero optimisation went on ).

*edit* and stripped out all the post processing stuff.

btw, if your tanks and ground parts and wall parts are subdivided enough (enough triangles each xunit), you don't need to use per pixel lights (but that's another story !)

The meshes for the wall are not subdivided enough for that. The floor is also just a flattened cube.

[RemiD]

@Derron>>the last version works well, but is really slow on my computer...


@Qube>>the last version with the "very low" settings works fast on my computer. but i think that you can add some real time lights (real time per pixel shadows and some full screen effects (like per pixel glow) can be slow on low end hardware, but the others graphics effects should be fast enough...)

instead of "very low", "low", "medium", "high", settings, it would be better (in an ideal world!) to have an option screen or a ini file to activate/disactivate some graphics effects...

[Derron]

@ RemiD
I think it is the real-time lighting. I do not have a clue how I should recreate the same visual effects without them (moving with fire/torch, burning enemies...). So baking light information only works for casting shadows of moving objects but moving lights... think this is not possible (maybe one of you knows how). Also I just tried Godot and started with "knowledge 0" and maybe now reached 1 of 100 ;-) (and with the gained experience I am not keen to try 2 of 100 the next weeks - too hmm "cumbersome"/bugged/tricked).

I could try to reduce draw calls (20x20 floor-object instead of 400 objects) but I doubt that this is the reason - most likely the real time lighting (moving + flickering).

Nonetheless I understand that you want it to work on a low-spec hardware. Next game is most likely BlitzMax or cerberus again.


bye
Ron

[Steve Elliott]

RemiD I think you've being over-critical of Qube and Derron who have both wrote a game in a very unfamiliar engine and language in 6 weeks.  Plus you expect them to have it run on your very basic system with no prior knowledge of the engines and languages used.

[Qube]

@Qube>>the last version with the "very low" settings works fast on my computer. but i think that you can add some real time lights (real time per pixel shadows and some full screen effects (like per pixel glow) can be slow on low end hardware, but the others graphics effects should be fast enough...)

That's good. OK,  two more versions to try to see where the bottle neck is ( if you don't mind ).

1.. Same as the one that works on your laptop but with the lights turned on - Download Link

2.. Same as the one that works on your laptop but with the lights turned on and the post processing shaders which handle chromatic aberration, bloom, ambient occlusion, vignette - Download Link

My guess would be that no.1 begins to show slow down and no.2 will probably kill frame rate even more. I suspect no.2 will work better than the original comp entry as the textures are all reduced in size.

instead of "very low", "low", "medium", "high", settings, it would be better (in an ideal world!) to have an option screen or a ini file to activate/disactivate some graphics effects...

I did plan on having all that in the game menu options but just didn't have the time as the last 48 hours were play tweaking and changing the HUD. It's the sort of thing I would add in if I do another 3D game. *edit* Time permitting if it's a few weeks game comp entry.

[Xerra]

As agreed, I have patched Rockman to fix a bug with the map screen and also another issue which could cause the player character to not appear when re-entering the start cave, as well as used the native compiler to build the game.

As I currently have a dead PC I need to take my source code to a friends house to get it compiled for a fixed Windows version, but the Mac fixed build is online now. I'll get this done as soon as I can.


PC build with the fixes has now been uploaded onto Itch.io

https://xerra.itch.io/rockman

[RemiD]

I don't say to make a low specs version just for me, i just suggest that it is good to be able to disactivate/replace some graphics effects, because we are small devs, so it is necessary, imo, to reach the wider audience possible. It is a good habit to have imo.

Plenty of games get a bad rating because they have abnormal slowdowns (for simple scenes) and are sometimes unplayable just because of that.

But i also understand that you had only 6weeks to work on your games, no problem!

[Steve Elliott]

I don't say to make a low specs version just for me, i just suggest that it is good to be able to disactivate/replace some graphics effects, because we are small devs, so it is necessary, imo, to reach the wider audience possible. It is a good habit to have imo.

Plenty of games get a bad rating because they have abnormal slowdowns (for simple scenes) and are sometimes unplayable just because of that.

But i also understand that you had only 6weeks to work on your games, no problem!

Oh I totally agree with you, games should scale as well as possible and be as efficient as possible.  However, spending lots of time crippling your 3D Game (2D Games should be ok) to fit onto a system that ends up with a bad frame-rate and doesn't play well only makes your game look bad - so best not to run at all.

Yes, with a 6 week game contest where a lot of time was spent learning the system, optimising could only really be dealt with after the competition.  At least Qube can get some feedback from you regards how the game plays on a basic system - which would be a great help.

[Qube]

I don't say to make a low specs version just for me, i just suggest that it is good to be able to disactivate/replace some graphics effects, because we are small devs, so it is necessary, imo, to reach the wider audience possible. It is a good habit to have imo.

Plenty of games get a bad rating because they have abnormal slowdowns (for simple scenes) and are sometimes unplayable just because of that.

But i also understand that you had only 6weeks to work on your games, no problem!

I think in my case perhaps you missed the whole background leading up to it becoming a game?. Initially I wasn't even going to enter the comp. In fact my game was chucked together over a 4 week period as in the early days of the comp I was just beginning to mess around with Unity. When I decided to dive into the comp I also said that my game would not be optimised. Turns out "not optimised" was an understatement with many textures being 2048x2048 for stupid tiny little things. This was my first game in Unity and my first time coding with C# and it's really messy in some places but overall I learned a lot for the next time.

If you could test the other two versions I've done and let me know how they perform, that'd be a great help.

While I do agree that games should target as much of an audience as possible I also think we all need to understand what's realistic for the game comps. For example the game competitions are generally based over a period of a few weeks and for many it's a spare hour or two a day over that period, so where do we spend the time? Do we all spend the time creating fancy menus, game options for graphics, sound and music and optimising for maximum audience leaving little time for the actual game itself? or do we spend the time creating a game and revisit the finer details afterwards?.

While I agree fully with your points I just don't think it's possible for everyone to do that based on the time the game competitions allow. I expect games a little rough around the edges and while I personally would prefer longer game dev times, most prefer the shorter ones, which is fine

[TomToad]

Bugfixed my entry for those with non-QWERTY keyboards.  You can now steer with cursor keys as well as WASD.