f13rce

Really like the game, also like the approach of choosing ball levels and car levels. I think there's a small bug in the level saving. It showed me that I finished level 2 after completing level 1. Nothing major though. And Josh, you might want to look into the leaderboards again...

I've never tried it myself, so use it at your own risk I suppose...

He's referring to the iterator, not iterator value. But you can you use the value of the iterator as a flag, although it can be dangerous in case an object or variable does have that value. An alternative way could perhaps be using it = list.end(), as end() has no value assigned to it. I don't really think there's a clean way to set it to "invalid" in any other way.

Cool stuff! Really hoping to see the car in the end. Good luck in the last week!

Any updates on your game? Would love to play it

I'd prefer a car way more that a ball. Even though the ball increases the pace of the game, a car is more suitable for anyone with any skill with video games, as they accellerate a bit slower. Cars are still challenging as well because you will have to manage all of the wheels. Maybe you can also look into a camera that follows the direction of the car so you don't have to use your mouse anymore (maybe to look at it from the side or so). I really like the game though, would love to see the end result

Working on WhiteOut, my entry for the Winter Games! It's a racing game where you race locally, online and/or against the AI. Still need to do the menu, audio and some more maps... But it's getting there! I'm coming for you, warm Leadwerks hoodie

Cool feature! Will be useful for a lot of things. I like it

Thank you Josh!

Very cool! The amount of immersion is overwhelming, didn't expect it to be that much. You can definitely see the amount of effort and passion into this project. Also glad to hear that you've passed your exam.

Can be anything, but it'd be nice to see as many summer-themed games as possible

Aww yes. Been waiting for this

I don't think you can Git Ignore anything else aside from that. The .meta, .map and .pfb files are all binary but shouldn't be excluded as they are needed for either the project or the engine itself.

All bugs are reported here.

If you're using C++, the only thing to ignore is the "Projects/Windows/PropertySheet.props" file, as it contains the abstract path to the engine of the user who created the project. This file informs Visual Studio where the library is located, which can be different for every user. So if another user has a different path to Leadwerks or doesn't have this file at all, then the user cannot compile the project. These are the following lines that probably need to be changed by every user: <LeadwerksHeaderPath>C:/Program Files (x86)/Steam/steamapps/common/Leadwerks\Include</LeadwerksHeaderPath> <LeadwerksLibPath>C:/Program Files (x86)/Steam/steamapps/common/Leadwerks\Library</LeadwerksLibPath> One way to work around this problem is to rename the file to "PropertySheets.changethistoprops" or something similar. Visual Studio won't pick up the file and you can use that file as a template that everybody needs to change to make the project work.

Are you making your game in C++? It appears that the includes are faulty after the recent update of Leadwerks itself. I fixed it by creating a new blank C++ project, open both solution files and then in Visual Studio: Go to Project -> Project Properties (or displayed as "WorldSmith/BlankProject Properties" in your case) Click C/C++ Click General Copy over the 'Additional Include Directories' from the new project to your WorldSmith project (do the Debug and Release configurations separately) Optional: Clean and rebuild the project (recommended though) If you need additional help with this then I can make a quick video or something.

Summary as far as I understood it: 4.1 official release is next week (even though you can already use it now) - "Probably a sale on a big distribution platform ;)" - "Please post fancy screenshots in the gallery for news article" Workshop not doing so well yet, is currently main focus for improvement such as: - Be able to download zip files of DLCs you bought on Steam through the workshop using your linked Steam account - Focus on more game templates for the users, preferably on the workshop If the workshop sales were more successful, we would've had over 2000 model packs already - To give you an idea, the mercenary DLC pack only brought in $150 on the workshop - Steam DLC sales compared to workshop sales are about 9:1 in favor of Steam New library for 2D drawing / window creation is in the progress - Potentially allows us for Mac OSX support, whereas the current library doesn't - No initial plans for a GUI editor, maybe later Wants to compile the Leadwerks editor to 64 bit using Blitzmax I think that's all of 'em

You can try ForEachVisibleEntityDo: Hide all the entities visible for the second camera, store all the hidden entities and re-enable them using Show() after rendering. It's probably not performance friendly but it's quick to make. You can also try to make a new world and try to emulate lighting it from there. Although I do like nick.ace's shader solution, would probably be the most performance-friendly solution of all.

I remember a technique where you have a second camera which renders the first-person model as a new layer. I found a good article about that recently, will come back with it soon Edit: I think you can do something like SetRenderTarget to render a second camera's display to a texture (which is a big as your window), which you can use as an overlay on top of your main camera using something like DrawImage.

The behavior is probably because the point they're looking to is below them. You probably only want the Y rotation of the model, so you can set the X and Z rotation to 0 using SetRotation.

Looks like I can be there for the first time

I remember this problem when using Project to draw health bars. I solved it by doing a dot product to see whether or not a point is in front of the camera or not. I don't have the code right now but can give it to you in about 12 hours from now if you want to. Edit: Oops, saw too late that you still want to draw the line. I don't have a solution for that though. Although you can use the dot product to determine whether or not it should be drawn

Making a multiplayer game gives 2 problems you would need to research first before you start developing. It can get really complicated and messy if you don't really know what you're doing. It's definitely possible in Leadwerks to make an online game. For example, I made Siege online during the Halloween game tournament. The problems are: - Finding a networking library - Setting up your game to use networking For the networking library, like above I can really recommend RakNet and ENet if you're new to networking. If you're more advanced, I can recommend looking into Boost.Asio and WinSock as it takes it to an ever lower level, giving you more control to the data you're sending out and receiving in. However, RakNet is known for stuttering as their networking tends to use TCP for reliable messages. Stuttering is where data like damage arrives later than it should. For the player it can be unpleasant as it causes things like . For a side project I've used ENet which didn't give that problem. So if I had the choice, I would pick ENet. Although, Ken Claassen made a on how to use RakNet with Leadwerks 2.0 (previous version of Leadwerks), but the idea behind it still works. You can check that out as well. Then for the implementation, there are two approaches to a co-op game. The first approach is to make the game able to host a networked game (also known as listen server), and the second option is to make a dedicated server. In Leadwerks it's easier to make a listen server as creating a dedicated server requires you to make a separate project which you will need to update constantly. A simple listen server is easier to manage both development-wise and release-wise. So whenever you finish the game, you can release it like the following: - Dedicated server: You can give the server to everyone or keep it yourself, make sure the game will still be sent to the players - Listen server: You only give the game (as setting up the server is all in the game), but tell the players to forward a port that the networking is using to establish a connection. There's still a lot to talk about for networking, but these are the basics. I'll be watching this thread for if you have further questions Good luck in the meantime. @Josh, is ENet actually implemented into Leadwerks? Haven't seen that yet.

My way is to have a 3D model with a muzzle flash already attached to it, you can give it a name too like "MuzzleFlash". Then in the engine after loading the model, you can keep an Entity pointer to the muzzle flash by using something like FindChild. After that, all you have to do is muzzle->Show() and muzzle->Hide(). For extra effect, you can attach a light to the muzzle object by creating a light after loading the model. You should then make the muzzle object the parent of the light so it doesn't go out of place.

If you want distance to be checked with the hills, you can store the waypoints and calculate the distance between each waypoint. When looking at my old code, I think it's being done something like this: std::vector<Vec3> waypoints; //Vec3 targetPos = Vec3(60); world->navmesh->FindPath(model->GetPosition(true), targetPos, waypoints); float distance = 0; for (uint16_t i = 0; i < waypoints.size() - 1; ++i) // you can also use unsigned int instead { distance += waypoints[i].DistanceToPoint( waypoints[i + 1] ); } printf("Total distance is: %0.2f\n", distance);