Jump to content
  • Advertisement
  • entries
    69
  • comments
    254
  • views
    47704

Entries in this blog

Bug fixing in Godot

Now I am back from France and it has been raining for days here in Wales, I have finally had a look at fixing some of the bugs in Godot engine which had stopped me making Android builds. The biggest, and stop-ship bug has been a bug in the skinning. It turns out if you try and run a Godot game using OpenGLES2 with hardware that doesn't support float texture (a lot of hardware!), it crashes when you have a skinned mesh in the scene. Well not anymore!!   This was very painstaking to debug, which explains why no one had managed to address it for the months it has been a problem. If you want to debug Godot engine on desktop, you compile the engine, and just run it, and can place breakpoints and debug from QT Creator. If however you want to debug the engine on an external device, it's a lot more complex. I don't know how reduz etc dealt with this but I resorted to the tried and true method of placing print statements throughout the rendering code. Everytime I wanted to debug I had make a change, compile the entire Android export templates, export the project from the IDE to the device, watch it crash, then read the print statements in adb logcat. A very slow and laborious business. But after around a day of this I finally zeroed in on what was causing the crash. It wasn't as I had initially thought, been a GPU issue. It was in fact a regression issue. The bone data for the skinned meshes was being saved in main memory, and was required for skinning, but this was only happening on desktop, not on devices. What is more this issue only occurred in the backup codepath for when float textures was not supported by the hardware (which is most older hardware). Once I had identified the crash, I hard coded in some values and was able to avoid the crash (but not render the skin correctly). From there I managed to modify it, practically a one line change that allowed the hardware tablets and phones to also store the bone data in main memory. This has fixed the problem! I explained the problem and solution on the issues on github, however it was clear I'd have to *gasp* learn how to use git. I'd looked through a couple of tutorials and it looked inpenetrable. Luckily I found a good simple tutorial and slowly worked through bit by bit with help from the Godot documentation, and I had created a 'pull request', which gets reviewed for putting into the master branch. It is still there as now but it is pretty obvious it solves the issue so I'm sure we will get it into the engine soon, with modifications if necessary from the guys who mainly write the rendering code. I also fixed another bug in the texture importing, and it is now pretty much good to go for running Godot on older Android devices (and also iOS). I made some test APKs for others to test then I tried converting one of the demo programs successfully, then I have made a first version of my side scrolling shooter game which I made for the last gamedev challenge. This is working great on my Google Nexus 7 2012 tablet, before it would just crash if I tried to run anything. There is still some work to do, I need to get the shadows working if I can, and I need to make the buttons bigger and more polished for the user interface. But it works great, the frame rate is decent without optimization yet. Very exciting both at the prospect of now being able to get all my previous Godot games working on tablets / phones and also at how useful this is going to be for others with the same problem.  

lawnjelly

lawnjelly

Side scrolling shooter challenge - alpha version

I'm off on various real life missions until the end of the month, so this is my potential release candidate for the challenge, which is available for download for windows and linux from the project page below. If there are any easy bugs to fix I will try and sort them. This video is actually from a few days ago there's been a few changes since then, I now have a creative commons sky (still to put in credits!), creative commons music, new terrain textures, new physics reps for the rocket / lander, bombs, low fuel management, and various fixes to the level generation. Bugs There were some very tricky bugs fixed today which only occurred sporadically. One was due to rocket parts being moved a long way on the map and storing themselves to the wrong section, and the other I haven't fully tracked down, it may be a threading issue between the physics and rest of game, but the fix seems to be working. Music After spend many hours looking for music I managed to find some fitting retro 80s synth music by Eva (which you can of course turn off lol). Note that I didn't adhere fully to all the challenge guidelines, especially about the weapons, but I figured I would replace them later, but I kind of ran out of time. Anyway hopefully it should be okay. Future I'm actually very pleased with how it has worked out, the whole pooling system allows you to have large levels without overloading things (runs pretty fast on my PC, 400fps or so without vsync). I've also started on the Android build, but will readdress that after the challenge as there are some Godot bugs in OpenGLES2 which need to either be fixed or worked around.  

lawnjelly

lawnjelly

Side Scrolling Shooter - Tech Test Version

I'm hard at work trying to finish within the next week or so on the side scrolling challenge, running out of time, so I may add some extra stuff to the game after the deadline but want to get something working to submit. I'm just working on making some objectives and level ends / changes but I thought I'd break with tradition of waiting till the end before giving downloads, and provide some tech tests so I can see if the game works on other people's machines. Anyway you can download from my project page a test version for win32 and for linux64. Objectives : Each level you must destroy a certain amount of alien bases and collect a number of parts. This is indicated on the top right of screen. Keys: Cursors - Move Tab - Fire Q - Tractor beam Space - Bomb Info You can at the moment drop bombs on the alien bases, you will probably have to destroy them all to complete level. You can also pick up rocket sections with the tractor beam / shoot them along / bomb them along until you get them on the player base, which is the yellow hatched base. It's quite tricky with the physics, I might adjust the tractor beam. There are respawning enemies and also perma enemies which are just the fly, rocket and lander for now. The collision reps for the rocket and lander aren't correct but I'm going to use these in a different way as they are too big for enemies, as they keep getting stuck with large collision reps. The levels are now repeatable, I haven't put in the full amount of variations for different levels yet. I'll try and have different background / terrain textures on different levels. There is also no music yet. Please let me know any feedback if it runs and how well, and ideas etc.  Try running fullscreen from the options too. Alien Base - bomb these Player Base - Move rocket parts to your base Health Platform - replenishes health Fuel Platform - replenishes fuel  

lawnjelly

lawnjelly

Godot side scrolling shooter challenge - May update

Despite a strong start time is already creeping up on me with the end of the challenge at the end of May. I actually have to go away before this so I have even less time. However I'm confident I can have a couple of playable levels. Android I managed to waste a week trying to convert the project to Android. Support for OpenGLES 2.0 is new in Godot 3.1, and well, it's a bit flakey. This is not entirely Godot's fault, the GLES2 scene is a nightmare in general I know from writing GLES2 code. The problem is mostly down to a lack of standardization in what features devices will support, and bugs in the devices and drivers. Really they should have standardized a number of tiers for GLES2 devices, and mandated support for certain elements in each, and had rigorous testing. But instead, the situation is like the wild west, with devices picking and choosing features to support. This makes development and testing a nightmare. So my current situation I have an Android phone which Godot doesn't support at all (too early Android version, godot had to update the signing method, something to do with security at google play not allowing older APKs), and on my tablet, I can run the game up until a skinned character appears on screen and then it crashes. The godot skinning method is not supported on all devices. Open source of course means that the onus is on ME to fix these bugs .. and I have Godot compiling in QT Creator and the export templates, but clearly a significant investment in time will be necessary to be able to fix such things in the renderer. Unfortunately the core team don't seem to be working on ES2, perhaps more working on Vulkan now. That would be one thing I have noticed about the Godot project, is that there is a lot of effort towards implementing new features, however some would argue that bug fixing should take greater priority. This is perhaps a feature of open source, where people will work in preference on interesting new features rather than boring bug fixes. Anyway I have decided fixing Godot has to take a back seat for now and I am concentrating on getting working gameplay. Some things I have been working on: Improved terrain rendering / collision Procedural level generator Artwork for platforms, health and fuel generator platforms Camera improvements I still haven't decided on the objective for completing the levels. It may be just crossing from A to B, or it may be transporting an item with the tractor beam. Or destroying a certain number of things .. perhaps I could have varying requirements on different levels. I'm not sure what is going to happen on the artwork side, it depends how much time I have. Ideally I'd like to create a full set of specific space models, but if no time I can reuse some of the frogger ones. Once again, 3D Paint is proving awesome on the artwork creation front. I must get around to making some windows builds.

Side scrolling shooter challenge - respawning enemies

One more video before I have to go away from home for a bit, I probably won't be able to work on the game for 10 days or so. A bit chaotic here, but now as well as the permanent dynamic objects on the map there are now Spawning monsters (at the moment just white spheres) white respawn when you shoot them. The laser is using a multicolour shader, there are now bombs too white are just placeholder boxes. They only explode when hitting objects so far but I'll add an area effect soon. There's also healthbar and lives although the death screen needs a bit of work. I've also tried some texture mapping on the terrain and put in a crate model which looks a lot better than the plain box. I think everything should look nicer when I have replaced the placeholder graphics. More particle effects Sound improvements Also I'll have to do a bit of work on the level generation soon, and maybe add some more elements like fuel and ammo drops or platforms that replenish health. Note that the laser and bombs don't fit with the no conventional weapons thing of the challenge, making a shooter without guns is so far eluding me. I'll probably modify them slightly / have a game mode without them for the challenge.

lawnjelly

lawnjelly

Game careers and the mythical 'game developer / designer'

Probably one of my more controversial and patronizing posts, I'm sure some will disagree and I did think twice about posting but hey ho I've written:   It seems that almost every day a naive post comes up asking how best for a budding 'game developer' to get into 'the industry'. Somewhere along the line, somehow many people seem to have bought into the myth that there is some generalist role in game development that is a viable career and will make them huge $$$. It irks me that this is the case, because in my opinion it is a distortion of the truth, and can lead to mistaken career decisions - particularly wasted education where there may be another far more suitable alternative career they are overlooking as a result. Note that in this article I am addressing the big budget console etc games business, rather than independents, and smaller / mobile games, which may use different business models. Follow the Money One of the basic facts in the games business, is that profits charts tend to follow a classic L shaped curve (long tail). By far the largest proportion of the headline profits made by the industry are made by very few big players (on the left of the dotted line), names you will all have heard of, and the other 99% of the industry makes very little, if any profit. This is similar to the situation in many entertainment industries - movies and music being similar. Newsflash - those companies that aren't making profit won't be able to support you in a viable longterm career.  They might by random chance enable you to strike it lucky and make some money from time to time, but they are unlikely to be reliable for putting bread on your table / roof over your head / support a family kind of way. Note how many game companies regularly close down and developers have to move area / country to have a hope of keeping afloat. And that is among medium / bigger companies. This leads to 2 very important points: There are not as many career opportunities as you think. There are far fewer stable jobs than can support the number of graduates of game development courses. Hence there is high competition for roles (and some employers will take advantage of this). There is a high competition between game products. It is often a 'winner takes all' type market. If a kid has 50 dollars to spend he either buys your game or someone elses. To win your game is likely to need better content, better gameplay, better advertising, better hype. Competition In order for a game product to compete on the world market, it is not usually sufficient to buy some assets from the Unity asset store, put them together in an innovative way and expect the dollars to roll in. This is to a certain extent a lie perpetuated by engine sellers, either because it makes them money, or to encourage you onto their ecosystem. Producing AAA games is still a labour intensive business. There are expectations from customers in terms of content etc. Division of Labour To be competitive and profitable, the modern big budget games industry, like most industries, uses division of labour. That is, instead of having generalists who can do every job a little bit well, jobs tend to be done by specialists who are expected to be experts in their field. That means, aside from indie companies and those that make small games, careers in the games industry tend to be for specialists. A comparison with house construction I find the misplaced expectation that game development is filled with generalist careers to be analogous to the situation in the house building industry. Most of us use and enjoy houses on a day to day basis, in much the same way as many people use and and enjoy video games. And yet if you ask most youngsters, they are not so naive about the jobs involved in the construction industry. It is easy for them to understand the difference between using and enjoying a house, and building a house. The type of people involved in building a house are architects, surveyors, planners, brick layers, roofers, plumbers, electricians, plasterers, etc etc. As a young person, you would not likely aspire to be a 'house builder', so much as aspire and train to be one of the roles within the industry. And yet when it comes to the games industry, newcomers seem in denial that it might be the same. But big budget games are not built by generalist game developers. They are built by environmental artists, character artists, character animators, tools programmers, graphics programmers, AI programmers, sound programmers, animation programmers, scripters, designers, musicians, audio  technicians etc. In practice these roles are often split and specialized even further, look at some credit lists. Final Ramblings And so when I hear yet another hopeful announce that they want to follow their dream of making their living in the big budget game development world, I have to admit it makes me groan a little inside, and wonder whether they do have any potential career in a team environment, or are just a dreamer barking up the wrong tree. What is more encouraging is when people express an interest in their area : 'how do I educate myself to become an amazing 3d artist', 'how do I become a better graphics programmer', 'how can I improve my AI programming' etc.  It is actually surprisingly easy to predict who has potential based on their forum posts, their ability to seek out information and learn and progress. Paradoxically a lot of people who *are* successful in games aren't specialized only in games. They are often quite adaptable and can work in e.g. movie / tv in the case of artists / sound / music, or other branches of programming in the case of programmers, and there is a lot of cross movement in these careers. So many times I have heard people profess that they love games, as if it is the only qualification needed. I love chocolates, it doesn't mean to say I want to spend my life in a chocolate factory. The industry does not need more people that love games, it needs people who love doing the jobs that are involved in making games. If you identify more with the first category than the second, perhaps a career rethink is in order.    

lawnjelly

lawnjelly

Side Scrolling Shooter Challenge - Monsters and Tractor Beam

Spatial partitioning for Pooling After spending many hours debugging my old spatial partitioning scheme, I decided it was too clever for its own good. I had been attempting to keep objects sorted in x order, so as to decide when to activate / deactivate pooled objects. However the problem is that objects have varying widths, which makes things more complex, I was needing a sorted x list for both minimum and maximum x values, which was difficult to debug in gdscript. So I decided to try out the old faithful grid partitioning scheme, although simply in 1 dimension for this game. As objects are activated and deactivated they are removed and inserted into the grid. Searching for new ones to activate then becomes simply iterating through a small range of the grid. There is still a little bit of tweaking to be done, especially for wide objects like platforms. These might be 'missed' for activation as their centre may be in a grid square off the screen. There are two obvious workarounds for this - I can extend the range checked further (which will entail a little unneeded extra processing for the narrow objects), or I can place the wide static objects into more than one gridsquare. But this is quite easy to fix. Monsters There are now 4 different monsters (might be enemy spaceships, don't know yet). They will have their own behaviour. I'm just reusing some models from my frogger game for now. They tend to more get in the way of your progress at the moment rather than attack you! Tractor Beam My first step to allowing you to interact with the environment is the tractor beam, which you can activate by pressing space. It was actually really simple to implement. In Godot I made an 'Area' underneath the player, and in the area you can give it modified physics when switched on. So I simply changed gravity inside the tractor beam. There are various other improvements too, to the UI and sound etc. Physics Almost by accident the physics features have turned out very cool. You can pick up boxes etc and unblock / block routes, which I might use as part of the gameplay. The enemies do tend to get in the way physics wise too, which I'm not sure yet whether is good or bad. There are a couple of snags with the physics too. One is that sometimes you can get stuck. This is a common problem with physics. I'll probably do something like leave a trail of breadcrumbs behind you, and if it detects you getting stuck, reverts to one of the previous positions. The other problem is more a game / level design issue. It is quite possible to get into situations where boxes are blocking off your way through the level. I can either have some complicated logic in the level generator (I'm planning on auto generating levels), or I can have some way to remove them, such as shooting them or have the tractor beam work sideways.

lawnjelly

lawnjelly

Side Scrolling Shooter - Sound

Have spent today and most of yesterday trying to workaround what appears to be a bug in the Godot sound causing glitching. Finally have a working solution: https://godotdevelopers.browse-tutorials.com/discussion/20619/audio-glitches-when-changing-position-and-volume-of-audiostreams-i I'll fix up some decent different sounds, these are just for testing. And I figured out the audio buses, I now have 3 buses, one for short reverb one for long and one for music. I've adjusted the view angle a bit to make things appear more 3d and put in shadows, and replaced the player box with my frog from my frogger game, this is just temporary though, will probably be a spaceship. And I've put in some kind of scrolling background, just a plane will do rather than skybox as the challenge is for a 2d type view. I discovered by accident that it was quite easy to make spinning static physics objects. These will make great obstacles, I'll have some spinning and maybe some like moving platforms blocking the way.    

lawnjelly

lawnjelly

Side scrolling shooter - Day 1

Day 1 of having a play with ideas for the side scrolling shooter challenge. I really have no idea what to do about the no weapons thing .. I was fully intending to make a space shooter but now I'm not quite sure what to do... Anyway I made a quick mockup last night with no physics (which is perhaps more arcadey) but then had a change of heart today and decided that as physics is free in godot there are a lot of benefits (realistic collisions etc) so I'd try and change the parameters to make it more arcade like. Or maybe I'll have a kinematic body for the player, not sure yet. I've been originally thinking of a side scrolling horizontal space shooter like defender or ground attack, however not sure what to do with the no weapons.  

lawnjelly

lawnjelly

Chess challenge - first alpha

I've just been hurrying to finish a passable first version of my chess game I'm doing as a challenge with Rutin. After a quick flurry of activity on the user interface and the rules, I tried to make some vaguely sensible recursive tree searching AI. It was interesting, and involved a lot more debugging than I originally intended. It was quite slow, play for a bit, discover it doing something wrong, isolate a case and fix. It became clear that chess engines are things that people spend years working on .. but I'm happy to have a pretty stupid AI.   Doing it all in gdscript was quite a challenge too, normally I'd do vaguely compex stuff in c++. But it is all possible in gdscript, just slower runtime than c++ (like 100x lol) and more tricky to debug.  Anyway to prevent the calculation times becoming stupid this version is limited to how difficult you can set it. It plays a passable game (cough!), and I've tried to include most end conditions. En passant and castling are mostly working, however there's no exchanging pawns, I might put that in at a later date. There's obviously a load I can do to make it look better too, a skybox and different camera views, better pieces and it would be nice to have a timer for the AI to give some indication how close it is to completing. But not necessary for a first release. Anyway if this works roughly for anyone else who tries it I'll move onto the next official gamedev challenge, the side scrolling shooter (with no guns!). Download from my project page here:

lawnjelly

lawnjelly

Game of Chess - Menus, Music, Sound Framework

Once I had the basic AI working I have been doing a bit of housekeeping but much closer to finishing, I have taken my menu, sound and music code from my Frogger game and tried to make them into a generic framework I can slot into later games. At the moment the menus are pretty identical to Frogger but I can change them. The AI is also a bit better with the heuristic since last time, you can see it a bit better here: Next stop is: Put in more than 1 move lookahead improve the heuristic further En passant, castling and recognise Checkmate Once that is done it should almost be ready for first alpha release. Then I'll want to improve the looks, make it easier to recognise pieces, change the background and put in some more helper graphical indicators to better show threats to pieces.

lawnjelly

lawnjelly

Game of Chess - Day 2

As promised, here is a video of the enemy AI starting to work. I've only just started and there are still some bugs in the heuristic, it moves into positions where a piece is threatened where it should not. And it doesn't yet have any concept of check, check mate and en passant and castling, and exchanging pawns. The lookahead is only 1 move so far so it isn't that intelligent, but I wanted to post this as I may be busy with shopping etc before I can improve things. I'll also try and get some menus in soon to build a framework for the game.

lawnjelly

lawnjelly

Game of Chess Day 1

About 24 hours after starting, here is a video. I have most of the rules implemented in a generic way (still to do en passant, castling and double pawn moves but these may be treated as special cases). As you move it calculates which pieces you are threatening and which threaten you. These are highlighted in red and green. I will use a heuristic combining the number of your pieces threatened and the number of the enemy threatened for the AI, to help decide on the next move.

lawnjelly

lawnjelly

Game of Chess

Having a few potentially free days I've decided to have a go at Rutin's challenge, making a chess game: https://www.gamedev.net/blogs/entry/2266806-challenge-1-3d-chess/ I've fancied having a go at this for a few months now as I've never done one before and think the AI will be interesting to try. Anyway I'm using Godot again and have managed to write a basic framework and build some dodgy chess pieces in Blender. This has taken me about 3 hours, so I'm pleased that it is already taking shape. I will probably have to modify the pieces to make them easier to identify, for instance the knights are too similar to the bishop at the moment. My plan is to give each piece type a ruleset for how it can move and take other pieces. This can be used to determine legal moves for the human player, and to determine moves for the AI. I'm thinking along the lines of using some kind of heuristic function to determine a score for each team, based on how many pieces are left, and which enemy pieces are threatened, and which of the team's pieces are threatened. The initial goal for the AI will be to try lots of possible moves and go for the one that increases the AI score the most. This could involve a lookahead for 1, or several moves, maybe trying to predict the enemy countermoves. I'm sure there are some well established algorithms for all this, but first of all I'm going to try it blind without doing any googling. I find it a lot of fun trying to figure out these things myself, I can always cheat and read some references once I've given it a go.

lawnjelly

lawnjelly

Islands and Land

I've been slowly progressing on my boating game over the past few weeks, it's been great that I seem to have a few people interested on youtube, despite me having no firm idea on a game design. I guess once you have water and land and boats you can use it for everything from racing to pirates / trading type games. Physics Physics has (allegedly) improved since my last blog post, instead of taking just one height sample at the centre of a boat I now use 3 samples in a triangle, to get an idea of the normal at the sea surface. This means that boats can now more closely match the surface instead of just up / down. The up / down motion is now working through the physics, rather than my previous approach of running the physics on a level ocean, then applying wave height to the displayed model only. There are disadvantages and advantages to this and it is subject to change. On the plus side it should eventually interact correctly with things like land masses, but currently the impulses to push the boats to sea level cause mad jitter on beaches! Boats also can take off now if you drive them over waves over a certain speed.   Skybox First I tried using the world environment to create a skybox in godot, but had very mixed success. It was easy to create a procedural sky but because of the PBR shaders, the boat models etc ended up having a horrible blue colour cast. I tried various methods to get rid of the cast but failed miserably.
In the end as I'm not really interested in PBR for this game I changed the world environment just to clear to a blue colour without a skybox, and I created a quick manual skybox in blender which I move around as the camera moves (needs a little tweaking). This looks good enough for my purposes and it means it doesn't get used in the PBR lighting so no colour cast (in fact I suspect it is defaulting to simpler shaders). Moving Origin As I was thinking of maybe having large worlds with a lot of sea to cover, I decided to have a 'moving origin' system to prevent floating point error in physics etc. It is quite easy to put in at an early stage, but more of a nightmare if you leave it till later, so I put it in early. The third person camera is focused on a particular boat at any time (e.g. player), and if that boat moves more than a certain distance from the origin, the whole world resyncs so that the boat is now centred on the origin, and the objects around are all teleported to their offsets from the player. This seems to work fine providing it is done at the correct time in the physics. Land Originally I was thinking of a simple game at sea only, but then realised it would be a lot more flexible to have land too. First I experimented with a simple plane for a beach, with a static collision box underneath it for the physics. I was planning on having a few different variations of beach geography, then stitching them together. The more I experimented the more I got dissatisfied with this approach, as it looked very inorganic, so I brainstormed for some other techniques. The difficulty was as well as looking right the approach had to work efficiently with the physics (and the moving origin). I wondered about using Delauney triangulation with some random points to get some land masses, but having a nice c++ implementation already in my library, I couldn't quite face translating this to gdscript. Plus, how would I handle the physics? Maybe Godot handles some polygon soup, but it would probably not be pretty. Next stop was a heightmap, but again I was worried about the efficiency of the physics and lots of special cases. Then this morning in bed I had a brainwave. Yesterday I had been experimenting and Godot has the ability to automatically build a convex hull physics rep around a mesh. I know from previous experience convex hulls work pretty good with physics, so instead of making e.g. a beach with this technique, why not create an entire island? Maybe I could just place islands on top of each other, interpenetrating, to create more complex coastline? It probably will look awful on the joins but given the ease of implementation this is my current winning technique. I made a quick low poly island in blender this morning, used the 'convex hull' operator in blender to ensure it was convex, UV mapped it and then did a quick texture paint in 3d paint. Whapped it in the game, added a convex hull static collider, and it's working great! Usually in these situations I'd also do procedural texturing but gdscript is a little slow for that, when I tried it in my frogger game, so probably just some manual textures for a few island types will do the trick. Anyway the final result is shown in the video. There might be some physics jiggle on the beach in this, I have to work on the boat physics on land, there seems to be some crazy interpenetration physics bug even in simple circumstances with a box against convex hull, maybe it is a bullet bug or some scaling or epsilon that is wrong.

lawnjelly

lawnjelly

Playing with water physics

While I've been mostly busy this past month with moving house, I have been making a few models and experimenting with making some water physics in Godot. I got thinking about when doing Frogger, about having a section with the frog driving a boat, but didn't really have time. Anyway as far as I can see there is no built in support for water in Godot using Bullet or internal physics engine, but I figured it couldn't be too hard to hack something together. Fixed tick rate physics First things first, I figured a good way of getting physics to work in combination with a fixed tick rate and interpolation. I will probably write a separate post on this, but I was successful in this case by completely separating the physics representation from the rendered object representation (the 3d model etc) in the scene graph. This ensured that any interpolation code on the rendering side did not interfere with the physics.   Buoyancy Next step was to turn off gravity, and add some kind of manual forces to keep the objects around the waterline. It turns out that you have to be very careful how and when to apply manual forces on every tick, so as not to disrupt the simulation. In Godot I achieved this by using the _integrate_forces function, NOT the _physics_process. I found that rather confusingly adding forces (particularly angular) within _physics_process borked the simulation. _integrate_forces on the other hand gives you access to the actual physics state. My current code to keep objects at the surface is rather simple: It calculates the y offset (y is up in Godot) of the object from the surface, and applies an impulse in proportion towards the sea level. I actually increase this above water for some kind of gravity, but I'm sure I will come to a more robust solution for this, such as turning on real gravity when significantly above sea level. Righting This works reasonably well, however, there is a problem, boats etc roll around in the water and don't stay upright. Clearly there needs to be some kind of way of 'righting' objects. I posted a thread to get advice on this (https://www.gamedev.net/forums/topic/700213-angular-velocity-and-water-physics/) however in the end, rather than using a complex and CPU intensive technique to calculate proper buoyancy I have for now opted for a rather simple hack. I essentially calculate how far an imaginary mast is from pointing vertically up, and calculate an angular velocity towards this. The details are in the thread. This seems to work pretty well, at least in the flat ocean case. I may have to either modify this or opt for a more complex technique for large waves. Waves   It was pretty easy to put in some keyboard control to move a boat or similar about, next step was to see if I could get some kind of waves in the ocean. It turns out Godot has a simplified method of writing multiplatform shaders, and it was pretty easy to follow a tutorial and get a vertex shader with some moving waves. This was already looking better but I wanted the boats etc to move with the waves. As there is no way of reading back the results from the shader, I essentially duplicated the shader wave height function in the main code, did some hackery for scaling, and ended up with a function where I could calculate wave height in the game at any location that would match the shader. My first thoughts were to simply plug in the wave height into the existing buoyancy code, however, probably due a delay between the impulse being applied and having a decent effect, the objects ended up bobbing out of sync with the waves. Due to the velocity being applied the objects tended to overshoot the surface continually. Really I just wanted to have the objects match the surface with loads of friction, so I realised for a hack I could apply the wave height to the rendered representation, and not apply it to the physics. I tried this out and it seems to basically work (for now). The physics is working on a flat ocean, and the waves are added afterwards to what you see. Obviously this is not ideal, there will be collisions in the physics where there would not be in reality due to the wave heights, and there is no momentum due to the waves etc. This is all a work in progress. Anyway these are the results so far I think it is promising. Large Worlds Soon I want to experiment with a large world. For a boating game I'd like to be able to travel a long way at speed, and this may cause precision issues if using single precision floats. So I'll see if I can have some kind of scheme where I teleport the player and objects once they move a certain distance from the origin, while keeping the physics and waves consistent. Another alternative is keeping the player at the origin and moving the objects relative to the player, however that might be a nightmare interfacing with the physics engine.

lawnjelly

lawnjelly

Random game mode and options

Just a little post that I have uploaded new version of my frogger game (011) on my project page, there is now a random game mode, and options where you can change difficulty, full screen toggle, and sound and music volume, and an as yet untested MacOSX version. The fullscreen toggle may be a bit dodgy, it works a couple of times on my linux PC but then has some graphic corruption, I don't know whether that is a Godot problem or graphics drivers. Adding random gamemode and difficulty took a lot of playtesting. Difficulty mostly changes the speed of the enemies, but there are some other effects too. When you get real good you can play on max difficulty, make sure to have lots of caffeine before this.

lawnjelly

lawnjelly

 

Frogger - Post Mortem

Finally made a first release of my frogger game for the gamedev challenge yesterday: What went right Using Godot Engine. Godot and GDScript was very quick to learn and get started with, and is very good for these types of small scale games. Overall I preferred it to Unity which I used last challenge. Using skin modifier for modelling in blender. This enabled me to make game creature models fast, around a day for modelling, rigging, animating and texturing a model. Using 3d paint for texturing creatures. Having spent many months developing 3d paint, it is really starting to pay off in quick texturing of assets. Blender can do this texturing too, but the workflow is much faster in 3d paint. What went wrong 3d sound broken in Godot. I had to do some bodging to get any kind of positional sound working, and it is flakey at best. I hope they will fix this soon. Android support not yet working. My android hardware / emulator only seem to support OpenGL ES 2, and Godot only supports ES 3, up until the 3.1 release. I tried the 3.1 alpha but no joy as yet. Creating art assets took most of my time, approx 2/3 of the development time (I am not an artist!). Moving house - I only realistically had the first 3 weeks to work a lot on the game, so tried to finish as much as possible early up. I do not even have access to computer / internet at new house yet. Dealing with different aspect ratios. I don't really deal with this as yet, I may have to address this. Normal mapping the assets. I tried this on the cars but it is very finicky to get working right and I don't have much experience. Took a lot of time and the difference was negligable so I dropped it. Procedural terrain texturing. Implemented but was too slow in GDScript, so I precreated 5 terrain textures and just used them in the levels. Same algorithm was fast enough in Unity in C# so I think GDScript is several times slower currently. (However I do prefer the GDScript language to C#) No wheels on cars. This is just funny, I always intended to put them in but never got round to it!! Dropping lots of features due to lack of time. This is typical of gamedev in general, but luckily I had enough features to make it playable. There is already support for other pickups like score and poison etc, I just didn't have time to make the models.    

lawnjelly

lawnjelly

 

Frogger - birds

Been a bit slow on the progress front past few days, maybe because I was making more assets which is slow - lily pad, snake and bird. These are now in the game although I haven't put in sound effects yet. I need to re-export the snake because it has lost the motion of the root node which is why the slithering looks super silly lol.   Today I've been starting to put in some basic functionality for creatures that are not on rails, first one being the bird. The AI is pretty simple at the moment but it looks passable, they just try to get at you and peck, although the peck does nothing yet. I was thinking about maybe having the peck reduce health rather than be an insta kill, or do something like freeze you or move you off path so you are more likely to get hit by something else. There is collision detection between the birds but not with the traffic etc, as I can see it getting expensive in gdscript, I might have the free moving creatures on specific maps on their own. I also have done some clever jiggery pokery with the fixed timestep. The frog and input are now working at 60 ticks per second, and everything else at 10 ticks per second. I was previously running everything at 30tps, however this is a waste once you start having AI creatures, 10 is fine for them, and 60tps gives nice responsive keyboard input for the player.

lawnjelly

lawnjelly

Using the Skin Modifier in Blender to quickly model creatures

Introduction After spending many hours painstakingly attempting to model creatures entirely by hand, I finally discovered (a couple of years ago) the skin modifier in Blender, which is a fantastic quick way to build organic creatures and shapes, especially for the artistically challenged like myself, and also makes rigging a breeze. I thought I would write a quick description for those unfamiliar. If you want ultimate control, particularly for a low poly creature, there is no substitute for manually creating polys. However this can be very time consuming and tedious. If you are instead in a position where you are willing to trade off speed of creation against 'perfect rendering efficiency', or are making medium / high poly models, or models for later sculpting, then one of the options available is the skin modifier. The skin modifier works instead of modelling the skin by hand, instead you place the joints (as vertices) of a creature to build a kind of skeleton, and allow the skin modifier to automagically generate a skin around this skeleton. Process Typically I start off by creating a plane, then go into edit mode, and merge the vertices to 1 in the centre. Next set up the modifier stack to create the skin. At the top of the stack goes a mirror modifier, because most animals are symmetrical bilaterally. Next goes the skin modifier, which creates a simple box-like skin around the skeleton. Finally add a subsurface modifier to smooth the skin, and make it more organic. Once the modifier stack is ready you can begin modelling. In the case of this bird I started with a topdown view. Select the start vertex (there should now be a 'blob' around the single merged vertex), and create the skeleton by pressing 'e' to extrude and place a new vertex. I did this to place several vertices to create a backbone for the bird. You can then create wings and legs by picking one of the vertices in the backbone, and extruding to the side. If you follow this process you can form a rough top down skeleton, it doesn't have to be exact because it is easy to adjust, that is one of the beauties of skin modifier. I find it useful to google pictures of the skeleton of the animal for reference. Next look at side views and adjust the up down position of the vertices (joints). The legs needed to be going downwards, and the head slightly up. Once I am happy with the basics of the structure, I start to fill it out. You do this by selecting a vertex, then pressing 'ctrl-a' then dragging with the mouse. You can make the skin thicker or thinner at each vertex. This can quickly give you a reasonable shape. You can further refine the shape by pressing 'ctrl-a' then limiting to either the x or y axis by pressing 'x' or 'y' before dragging. I used this to give a broad flat tail and wings. Conclusions Pretty soon you can build a pretty good model. You can tweak a few things in the skin modifier, especially set a root vertex (e.g. pelvis) can make it easier for later animation. Skin modifier also makes rigging easy. Once you are happy with your skeleton, make a copy of the whole thing (so you don't lose the original), then choose 'create armature' from the skin modifier. This will create an armature and link it to the mesh so it is ready for posing and animating! I also typically choose smooth shading in the skin modifier, then manually add hard edges in mesh edit mode (ctrl-e, hard edge, and use in combination with the edge-split modifier). I also use this to select seams for uv mapping. Note that once I finish the skin modifier version I usually have to do a little tweaking of the polys manually, because there are some things it is not good at. Anyway this has been a brief introduction to this method, I would encourage trying it and following some youtube tutorials. After some decimating and very rough texturing (~640 tris)

lawnjelly

lawnjelly

 

Frogger - night mode

I spent a couple of days adding a procedural splatting terrain texturing system, similar to the one I used in tower defence. However it does run slower than in the Unity version, I suspect gdscript is currently quite a bit slower in Godot (3.05) than C# in Unity. As a result I've thought about pre-generating some terrain textures as .jpg, compressing them a lot and using them instead of doing it on the fly. This is an option, but I've left it procedural for the time being. The road and rivers are not needing the procedural system, so there is less area that needs doing, so I may get away with it. Certainly an advantage to procedural, as well as variety, is that I can change the terrain around buildings etc should I put them in. I've started adding some more cameras too. You can now switch between a top down traditional ortho camera, and a perspective low down camera that follows the frog, and shows closeups where necessary. I've added an easy way to layout each level, I specify the number of tiles of a type (grass, river, road at the moment), then for each row I can specify the type of traffic, speed etc. And lastly I've been playing with the lighting, experimenting with the spotlight in godot, possibly for a nightmode. I don't know how it will affect performance if I do a mobile version, but certainly the spotlight is fun, and changes the gameplay a little as you sometimes can't see the vehicles coming. I've been thinking of putting a 'spyfrog' slant on things, and this lighting would work for a spy. I still have to get around to thoroughly debugging the collision areas. I'll probably attach some visible bounding quads to each object to check the bound matches up with the visual rep, it's quite a bit off in some cases which is why you die jumping on certain bits of logs etc. I will add lily pads soon, and have realised that if I make a snake, it can act just like any other bit of traffic, just moving on the grass.

lawnjelly

lawnjelly

 

Intellectual Property and Clone Games

I'm just today thinking about the rights issues of my little frogger game for the gamedev challenge. It is quite common place to make clones of games as a learning experience and for jams, but it is worth spending a little time thinking about rights issues. I got to thinking about this because sometimes I notice a promising game, where the assets are obviously ripped from other games / sources without licence. I too had no qualms about this kind of approach when e.g. learning to program a new language, and not intending to distribute the result. Indeed this can be a valid use in production, with placeholder graphics, as long as you are sure to change the final versions (there is a danger of tripping up on this one, even big companies can mess this up!). Plagiarism I remember vividly being told of the dangers of plagiarism in my education, in the world of science, but equally applicable to games and artwork etc. Once you spend some time either programming, making artwork, sound or music, you begin to realise the effort that goes into making the results. How would you feel if someone took your hard work, used it for profit and attempted to pass it off as their own? I like to think of it that I would like to treat others work how I would like mine to be treated. On top of the legal aspects, when applying for jobs, many employers will take a very dim view of plagiarism. If you thought it was okay to 'steal' anothers work for something on your cv, what's to stop you thinking that it is okay to copy anothers work during your job, and expose them to huge risks? Quite apart from the fact  the interviewers may have personal experience of being plagiarised, in many cases your CV will be filed directly to the rubbish bin. Creative Commons and Open Source Luckily in the case of assets, instead of infringing on others works without permission, a huge number of people (including myself!) have decided to make some of their work available for free for others to use under a number of licences, such as creative commons, often for nothing other than an attribution in the credits. (And think of the huge contribution of open source software. I am writing this now on an operating system that is open source, and has been freely given away by the authors for the good of everyone. That to me is fantastic!) I remember spending some time compiling the credits list for my tower defence game, making sure as well as I could that everyone was properly credited, every model, animation, sound, piece of music. It took some time, but I feel much better knowing that I had used the work as the authors intended, quite apart from feeling more secure from a legal standpoint, even for a free game. And also, speaking as an author myself, it is quite fun to google yourself and find where others have used your work, and encourages you to share more. https://opengameart.org/
https://freesound.org/ Copyright++ Things seem pretty cut and dry for outright copying of assets, but the situation is more complex when it comes to assets that are 'based on' others work, and for things like game titles, and game designs. Some of this intellectual property (IP) protection is based on trademarks, rather than copyright. I am no expert in this, and would encourage further reading and/or consulting a specialist lawyer if in any doubt. Also note that IP laws vary in different countries, and there are various agreements that attempt to harmonize things in different areas. Of course, whether you run into trouble making a clone game depends not only on skirting around the applicable law, but whether the rights owners are able / willing to take action against you (or the publishing platform). Nintendo for instance are known to be quite aggressive for pursuing infringement, whereas Sega have sometimes suggested they are happy with fan games: https://kotaku.com/sega-takes-shot-at-nintendo-encourages-fans-to-keep-ma-1786527246 I do understand both points of view. Indeed in some jurisdictions I understand that legally the rights owner *needs* to take action in order to retain control over the rights (this seems nonsensical, but there you are). So a company being overly-aggressive may have been forced to do this by the legal system. Anyway, for my little research into frogger, my first guess is that the rights are with Konami / Sega / both. Of course you never know. Companies sometimes sell the rights to IP, or one goes out of business and the rights are then assigned to a creditor. Who is to say that a future rights owner will not take a different approach to enforcement. In the Wild It seems there are a number of frogger clones out there, with some successful and profitable (e.g. crossy road). Of course that does not mean making a frogger clone is 'ok' in any way, it just suggests that the likelihood of running into trouble is lower than if there were no frogger clones in markets. Currently I am thinking I will gradually modify the title / some aspects of gameplay so I can put it available for download after the challenge. I really should have thought of this sooner though, and made my main character something else, or put a different slant on it, like 'game of frogs', or 'crossy frog' (that one is taken!). :) Some light reading https://en.wikipedia.org/wiki/Copyright_and_video_games
https://www.newmediarights.org/guide/legal/Video_Games_law_Copyright_Trademark_Intellectual_Property
https://en.wikipedia.org/wiki/Berne_Convention
https://en.wikipedia.org/wiki/TRIPS_Agreement
https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act
https://en.wikipedia.org/wiki/WIPO_Copyright_Treaty
https://en.wikipedia.org/wiki/Directive_on_Copyright_in_the_Digital_Single_Market

lawnjelly

lawnjelly

 

Frogger - animation

I have now added some animations from blender to Godot. Mostly they went in very easy, and the AnimationTreePlayer makes it easy to set up node graphs for the animation logic. Although I couldn't work out how to do certain state changes, I gather this is being changed in new version though. The animations look good in the game, especially the frog. I also added logic for controlling the yaw of the frog as you move. The only bug I've encountered in the animations is that, particularly in a window, sometimes it is showing streaked corrupted black triangle down the screen. I initially thought it was to do with shadow mapping but now I think there may be bug in the engine vertex buffer / shader code somewhere. I did maybe wonder if I had exported my animations wrongly, but the process is pretty simple so on balance I think it may be an engine bug in 3.05. Will see if it fixed in the 3.1 alpha or my compiled from source version. Next I aim to work some more on the core game, fixing collision / river, and adding progression in skill / variation through levels. Then I will look at some different cameras, and dealing properly with traffic leaving the screen in different aspect ratios. Also I want to look at revamping the background graphics, not quite sure what to go for yet.  

lawnjelly

lawnjelly

 

Frogger - programming day 4

Quick update to show how everything is going. Ignoring the river doesn't drown you, collision bugs etc, I've been pressing on with getting the major features in. There are now menus, UI (basic to start), game state logic, winning, losing, and just today I was putting in sound. Sound has been quite tricky because 3d sound and listeners seems to be currently broken in Godot (3.05 at least), so I've had to bodge around the broken bits considerably. If they fix it I can solve some of these things but for now sound will have to be pretty simple. Still loads of stuff to fix, as well as putting in some kind of progression as you complete levels. I was thinking of making roads / rivers wider, or multiple versions with more traffic, different speeds / densities. Also I might put in some other stuff like a fly to eat and otter and snake, depending on time. I also figured out some performance issues were occurring because Godot was defaulting to a 4096x4096 shadow map (!), gawd knows how this was decided to be a good choice lol.  

lawnjelly

lawnjelly

 

Frogger - programming day 2

Just a quick update to show how my frogger challenge entry is coming along. I had a day off yesterday and have today put in collision detection and a few other things. You don't die yet if you drown and the crocs and turtles are going the wrong way, the collision detection has lots of bugs, but it is getting there. My plan is to first get a working version, then flesh it out as time allows. I will put in UI soon and work out how to do menus etc. Once it is playable and meets the challenge I will put in animation, improve backgrounds, cameras etc.  

lawnjelly

lawnjelly

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!