• entries
69
254
• views
47704

## 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.

## 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

## 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.

## 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.

## 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.

## 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.

## 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.

## 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:

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## Intellectual Property and Clone Games

https://en.wikipedia.org/wiki/Berne_Convention
https://en.wikipedia.org/wiki/TRIPS_Agreement

## 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.

## 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.

## 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.