Added this to the game today, and it works fine, although it feels weird, especially since I spent the last one year playing the game with keyboard and mouse…
Most of the work today was more game design related than tech, fine tuning parameters so that shooting feels fine/cool…
For the normal weapons, I feel I got it… Basically I check the line of sight in the direction the player is facing, see if there’s any enemy there and if he’s in a small cone in front of the player, shoot directly at it, instead of the actual direction… There’s about 5 degrees tolerance (maybe this must be distance dependent, instead of just angle based), since the gamepad isn’t as precise as the mouse in this regard… This also accounts for differences in height between the enemy and the player…
Now I have another problem: positional weapons… For example, the teleporter jumps into the cursor position when fired, but now I don’t have a cursor anymore, so I have to figure out another way to do this, like the grenades… Unfortunately, what was one of the most powerful weapons in the game will become just a nifty thing instead, I think…
I considered in adding a pause mode so that the player can leisurely select the teleport destination, but I think that runs a bit against what I’m trying to build with the game, so I’m running an experiment on “length the secondary fire is pressed” to define where the target will be… Maybe that works!
Now listening to “Coal” by “Leprous”
Finished the movement code with the gamepad…
The control system is dynamic, that is, if you start using the gamepad, the mouse cursor disappears and you’re in gamepad mode, but if you move the mouse, the cursor reappears and you can play with the keyboard and mouse again… That’s important, since there’s a lot of stuff that’s not prepared for controller yet (most of the UI, for example).
There’s also stuff that we might want to map in different ways (for example, to skip a text during a cutscene, the jump key should also be usable for skipping… With keyboard, that use is not too apparent, but with the gamepad it is).
Now comes the hard part: shooting.
Now listening to “Tall Poppy Syndrome” by “Leprous”
Link of the Day: One of the best/weirdest commercials ever:
Finished the groundwork for the gamepad support on Gateway… Went rather well, already got the menu control with the controller working, which is great!
Tomorrow I’ll probably make the player move with the gamepad and maybe start on the shooting code as well…
Without screenshots, these updates look very small! 
Now listening to “Instrumental Core”
Well, just finished to hack a version of GLFW that can work with DirectX…
Basically, I just created a #define that allows to shut down all the OpenGL, window management, etc of GLFW, and built the library with it…
It was rather simple, just time consuming (searching for all the OpenGL functions, etc).
Now I need to build an abstraction layer for the gamepad (because that’s something I do), and I can start working on the actual code for moving… Targeting will be a bit harder, since there is no cursor anymore, so I need to check what’s in LoS in the desired direction and adjust Y for it… Hopefully the gameplay fun-factor will remain the same with the gamepad (a bit “scared” about it).
So, good progress, hopefully I’ll have most of the gamepad support done in the next couple of days (except for UI, since that will require a bit more work, which I’ll only work on when I have the final UI work, which should be started shortly after I get this done).
Now listening to “Shatter Me” by “Lindsey Stirling”
Link of the Day: WadgetEye Games is at it again… This looks like another excelent graphical adventure, it even looks better than the previous ones:
This one:
Controller support for Gateway!
I’ve been meaning to add this for a long time, but some higher priority stuff came along…
I really want to use GLFW for it, since the API seems nice and it does most stuff I want it to do, but on the other hand I can’t use the D3D renderer with it (since GLFW is tied to OpenGL)… I have three options:
-
Rip out/Modify the controller code on GLFW to make it D3D/OpenGL agnostic… Might not be ok due to the GLFW license
-
Don’t support D3D or controller in D3D
-
Roll my own for D3D
So I’m investigating if option 1 is viable at all, since it would be the easiest option, and I only have to care about the Windows build on that…
Now listening to “Amaranthe” by “Amaranthe”
Link of the Day: Great article about the indiepocalypse: http://jeff-vogel.blogspot.pt/2015/09/the-indie-bubble-revisited-or-are-we.html
Sorry about it, guys, but I’ve been really busy with real life stuff, and really incapable of making time to develop the game… Doesn’t help motivation is a tad low at the moment…
Anyway, here’s hoping this week I’ll get back to normal!
So, one of the complaints I had from the Game Dev Camp was the font I was using for the “wall of text” (tutorial stuff) wasn’t very legible… So today I invested some time in trying to sort it… Still not 100% happy with it, but I think it’s better… Before on top, current on bottom:
Font is smaller, but more rounded, so it helps with legibility, I think… Will keep searching for a better one anyway (if you have suggestion, just let me know, I usually look for free fonts at www.dafont.com).
Besides this, I decided to optimize a code path… I was changing render targets a lot; for example, I was setting stuff like this: RT0 –> BackBuffer –> RT1 –> BackBuffer –> RT2 –> BackBuffer –> etc. So I had to go to the backbuffer everytime I wanted to switch render targets, even if I didn’t use it…
So I changed the code around so that it would just go (in the above example): RT0 –> RT1 –> RT2 –> Backbuffer… Was expecting this to yield some FPS, but the end result was none… 
So, it was a bit of a waste of time (at least on the video cards I own), besides the satisfaction of having a more efficient system…
Now listening to “Z2” by “Devin Townsend”
Link of the Day: Most indie gamedevs know “The Meatly” comics, and he’s running a Kickstarter campaign with lots of cool stuff… Unfortunately, it’s not getting much traction, so how about you give it a push? 
You can find out more about it at https://www.kickstarter.com/projects/1950781914/themeatly-takes-on-gaming
Well, I had way less time for development here in the Netherlands than I expected…
My hotel room was so small, it didn’t even have a table! So, I had to lie down in the bed to code, and after 10 mins my back was killing me…
Anyway, I fixed one of the oldest things in my to do list: overlapping planets/links… Sometimes the generation of the galaxy would lead to this:
So, there’s at least a link that passes through a planet… Of course, we can say “it’s below the planet”, but it looks bad, so I decided to remove those cases…
So, first try led to this:
It disappeared, but a lot of other links (valid ones) disappeared as well! 
After some tweaking the point to line function, I got this result:
Which was exactly what I wanted… Now, I’m not sure if I want to remove the links that overlap other links as well (like in the bottom of that map)… It might look nicer, but less “real”…
Next few days I’m back to Portugal, but I have a thousand things to do, so not sure if I’ll have time for development…. can’t wait to start my new job to have a more “regular” life editing our documents with sodapdf software!
Or sort of…
I came to the Netherlands to finish some work for my previous employer, just tying loose ends, so I don’t have much time during this week to work on the game…
Still, I’ve been making some progress, and most of the stuff called out on the Game Dev Camp are fixed and/or sorted; still missing some stuff related to art, but that’s minor…
One of such doubts is the resolution of the ground texture… This is how the game currently looks:
Some people have remarked that there is too much discrepancy between the texture on the ground and the rest of the textures… So, I’m playing around with the UV repetition rate:
The problem is that the pattern becomes too obvious, in my opinion, and even a bit distracting…
So, what do you guys prefer?
Now listening to “Endless Forms Most Beautiful” by “Nigthwish”
Link of the Day: I need this… because of reasons:
Busy squashing bugs… Most of them are quite small stuff that was more nuisances than actual bugs, but in the last couple of weeks I’ve found some “big” stuff.
One of these was some conditions where the story planets couldn’t be generated properly, which meant the game would get stuck in the generation phase… That one’s fixed, was just a matter of having enough fallbacks… Note that I generate the galaxy, then choose planets that fit the story, I don’t generate the galaxy based on the story… On hindsight, that might have been a good idea…
One long standing bug was the loader not showing up during loading… Now that’s sorted… It’s fun because the root cause was quite simple, but it should happen all the time, not just on release/final builds…
Also fixed a couple of crashes (bad edge cases, easy enough), some issues with the spawners (they would spawn even if the player was in a cutscene), and some bad generation of camps (they’d spawn on top of the temples in some cases)…
Still have about another 20 or so bugs/features to polish to have a version that fixes most of the issues that came up on the Game Dev Camp… Then I can do a “pause” of sorts and work on a feature instead of just bug work…
Now listening to “Paradise in Flames” by “Axxis”
So the problem ended up being the fact that the z-buffer associated with the render target wasn’t the same size, so it got clamped… It still smells of driver bug in fact, since depth testing, writing, etc, was turned off, but it was more or less simple to fix: just create a 1024×1024 depth buffer for the screen-based effects (like the SSAO)…
I think the whole frame buffer system on OpenGL is a bit convoluted, requiring you to jump through hoops to do something that should be simple… For example, let’s imagine I want to do a pass on the scene, where I write to a color buffer and the “default” depth buffer… I don’t think this is possible under OpenGL… I would have to create a frame buffer and a depth buffer, and do the render, but when I get back to the screen buffer, the depth buffer associated with it isn’t filled, so I couldn’t take advantage of early-Z, etc, without rendering to it again (because I can’t set the depth buffer of the screen buffer, like I can on DirectX, but I also can’t get the default one to give it to the second frame buffer I create)…
This can of course just be a lack of comprehension on my part on how OpenGL works, but I’ve found no references on this on the Internet…
Anyway, problem solved, now I only have 10000 other stuff to do!
Now listening to “Soundtrack for the Voices in my Head” by “Celldweller”
Link of the Day: Rammstein… a capella! 
