reepblue

Hooray! Leaderboards do work now! Now I just gotta fix that font issue with Rolly.

Indeed, as most people have an Xbox controller from last generation and maybe this generation with the Xbox One. Some people including myself have the X360 controller even though they don't have the actual console. Right now, we have that Xbox Controller library on the workshop, but it can only work for non workshop games.

Sorry for the whole week of silence, I ran into quite into a number of issues the previous weeks, but I'm ready to talk about them more, and how I it got resolved. Newton Physics (Or how Leadwerks uses this physics engine) has a problem when a non-physics object collides with a physics object. You expect that if a entity using the Move() function would use it's own shape to push anything out of the way. What actually happens is that since the entity has no mass, the entity pretends the physical object isn't there, and just clips right through it. This is most likely like this by design, but for Vectronic it was a huge issue. The advertised way of doing platforms is to use the Joint class so the entity will have mass and interact with other physics objects. However, the Vecboxes need to be heavy, I'm talking about setting the mass to 80 to prevent the object from bouncing like a kickball. Increasing the overall world gravity effects the player, and I want the box to be lighter when it's activated by the 0g Ball, which makes it easier to throw. Problem was that if a box was to go on these platforms with the mass I need them to be, the box would overwhelm the joint, and break it. Platforms is something I see important to the project as by now (in the earlier puzzles) they are used for demonstration of how the 0g cube works, and are in the majority of maps I have already made. If platforms can't work, I was afraid I was back on the bus of looking for another suitable engine for the game. Luckly Einlander came to the rescue and set me something that worked better than all my other attempts. Einlander's script moves the object from it's resting point to another position similar to the sliding door script. It also updates it's Physics Position and Omega in a function called in UpdateWorld. The result was exactly what I want minus a slight jitter in the box, but I'll take it. After experimenting with it though, I noticed that if a box was only partially on it, the platform would ignore the box, and go right through it; a similar problem I kept having. My fix was to create a trigger that's spawned with the platform with it's shape to handle this case, and behavior with the 0g cube. It's still not 100% perfect, but it's better than what I had before. The project was now back in gear. Another concern I was having was questioning "How much fun is my game, or is it just work?". Running around, shooting power balls at boxes so they change their properties sounds like a good concept on paper, demo maps, but imagine a full 2 hour game of just that? I was worried that just focusing on that would get really boring; so boring that it might even make people to stop short and refund the game. As if it was not clear already, Vectronic is a tribute to Portal as if it wasn't for that game, I would not be here talking to you right now. I started to think about Portal, and I started to look at it from a weird light: How would Portal be if momentum (Flinging) wasn't part of the game? There are five chambers, and the BTS areas that require or focus on using Portals to fling over gaps, and a good chunk of code is dedicated to make sure the momentum multiplies when going through each portal until the player or object hits it's max speed. But imagine if the game didn't have it, you'd have a game where you walk into walls to move mostly boxes around. Again, this might not seem so bad, but imagine playing it for 2+ hours with only the original elements; it will be similar to what I have now with Vectronic. The issue I think is the lack of Player Mobility. From my observations, people like to use their weapon to get to an extreme height. Join any Team Fortress 2 server and you'll see Soilders and Demomans blast jumping, and Scouts double jumping everywhere. With PUNT had something called Punt jumping which was like Rocket Jumping, but you could only do it on certain materials. From the feedback I got, people were most excited about that. Only issue is that it required skill, and it was never fully taught. I'm currently experimenting with this bounce jumping idea. Imagine rocket jumping only on certain materials, but all you need is to double tap Space. I've got only one map done as a proof of concept and to introduce the idea to others to see if it worked. Two days ago, I shipped the build early while this was still being figured out to see if it was worth the effort. I got a positive vibe from their feedback, I got told it was fun, although they didn't fully understand how to control it. Regardless, this might be because I was calculating how high the jump should be based on the time you're falling, not the speed, but it shows that it's not perfect yet. I should have more information about it next week (hopefully!). I want to go back and forth with my pre-alpha testers until it's a fun and fully understandable mechanic.

Nah, I understand; I'm sure it will be great.

Can we submit ideas for cars for the Leadwerks Car Pack?

Leaderboards still don't work in Rolly when published on the workshop. Apparently not, Last night I did a re-upload and still on my end of the game launcher, the font is missing. Tonight I'll reupload it to include all files this time.

I really hope this get's fixed soon. I haven't used the script editor much since the auto-complete started working the other day, but I recall having issues when it would "reload" the script when a error happened. (For example: MyScript.lua, would open as myscript.lua when an error happened on MyScript.lua, but you would edit myscript.lua instead of MyScript.lua and get confused,)

I think the better option is to have it so the user can control what files can be read in the script editor in a similar fashion as they pick what files to package before publishing.

I see this as a must have in the near future. Looking back on this topic, it started back around the 3.2/3.3 days, and obviously there was "bigger fish to fry" back then. But now with things like the Game Launcher and as it gets more popular/a way of sharing creations made on Leadwerks, I think ogg support will help keep those zip files small if the author want's to use a full music track. Again, not everyone has high speed internet, so low file sizes are always welcomed. I was working on getting ogg support/FMOD as a part of LEX, but I was having issues if installing the libraries, and the issue of the sound actually existing in my world, and not the console application. If anyone has information about that, please let me know, but I still think ogg should eventually be apart of the engine, now especially with the Game Launcher.

Use Camera::SetMultisampleMode to set multisampling instead.

I confirmed that Leader boards (and some reason font packaging) does not seem to be working. More info here.

Updated!! Fixed some stuff. I don't have a useful animated character to do so. I was first gonna make an on going runner but replace the runner with a ball, and it evolved into this. I also tried a few art styles before settling on this one. Having detailic materials actually gave me a headache due to how fast the ball was moving. EDIT: I'm noticing a few issues between the master build and the workshop upload. Issues include leader boards not working and my font not being packaged. I did check the "Only include used files".

I hope the Game Launcher gets updated soon. I'm currently uploading a new build of Rolly with this.

Yeah, the exe's did not update. They are still dated from the last update.

Very cool, I'm curious to see how this will work when it's implemented.

It's quicker and easier to print text to the screen. Overall, having text gives the health information quicker than a health bar.

If you need to code in a default value like in my application, I recommend having everything at 0 or 1 when no user settings have been defined yet

Summary A coding exercise done for the Halloween Game Tournament. It's not "Halloween-ish" but I think it's something else that will make you scream and curse out loud. I'll continue to update the project a little at a time until the Tournament ends. I'm uploading mine a bit early, in case my power/internet/life prevents me from uploading it on the due date. I'm also taking feedback on how maps should be planned out, and I'm thinking about power ups and new levels. Controls: Use A and D to control the ball. The ball will continue to go forward so W and S don't do anything. Thanks again, waiting for your feedback. Workshop Page

I was looking into these options while developing LEX, and I just used the first 3 options, really. I never saw a difference in setting the anti-alias in the context, so I adjust the msaa setting to the camera. You'll have to have the camera get the msaa value from where ever you're controlling the settings. You can also try custom settings like changing all the lights shadows to static, or making the View Modes of entities based off of their aabb. Although this will result in slower load times, it will be better then a slow game. I recently revisited the settings and I find it best to make a singleton class just for the options, and expose it to lua like: std::string Settings::GetScreenWidthValue() { xmlSettings.load_file(FILE_SETTINGS); xml_node displaynode = xmlSettings.child(NODE_SETTINGS_ROOT).child(NODE_SETTINGS_DISPLAY); std::string value = displaynode.attribute(PROPERTY_SCREENWIDTH).value(); return System::GetProperty(PROPERTY_SCREENWIDTH, value); } std::string Settings::GetScreenHeightValue() { xmlSettings.load_file(FILE_SETTINGS); xml_node displaynode = xmlSettings.child(NODE_SETTINGS_ROOT).child(NODE_SETTINGS_DISPLAY); std::string value = displaynode.attribute(PROPERTY_SCREENHEIGHT).value(); return System::GetProperty(PROPERTY_SCREENHEIGHT, value); } --Create a window local windowstyle = window.Titlebar local resx = Settings:GetScreenWidthValue() local resy = Settings:GetScreenHeightValue() window=Window:Create(title,0,0,resx,resy,windowstyle)

Thanks for your input. I'm glad you enjoy it. I'll publish it when the game has it's own character. I got some music that Hamst3r did for Blue Portals, and that might fit and I want to swap out some of the models; which should be easy because everything is prefabbed. It's not "Halloween-ish" but I think it's something else that will make you scream and curse out loud. Also, here was my inspiration. I used to love these as a kid:

If you say so, this is what I had in mind. I only really spent a few hours on it total, and I dunno where to go with this. Link

I believe the engine is soon going to have it's own tessellation support once 3.7 releases. Maybe when Josh gets back he'll have information about it. A beta shader should be on here somewhere. Article: Terrain Tessellation

Yeah, I quickly test my idea and it did not seem to work. Unless tech demo's qualify, I don't think I'll be submitting my own game, but I'll be happy to help with scripting/C++ with other projects.

That mod was made in the Source Engine in 2012. All the maps done for Vectronic are just in dev maps at this point.

Question, why did you/your team decide to use Y as up while other applications and engines use Z? Is it because Y is easier to remember as up because of all 2D Graphs? Just curious.