reepblue

Another week, another weekly report. Vectronic is going more smoothly then ever before taking things one at a time, and just shelling out maps and ideas quickly. Last week, I did a few improvements with how the player picks up objects, and fixing the issue of shooting projectiles through objects. I did not shell any more maps because I thought it would be better to focus on a small amount of puzzles at a time, perfecting them before making more maps. For this, I needed help. As of this week, I quietly put the first test build on in the Dropbox folder which used to host the Source build, and asked a small number of people to test out movement, mouse control, and if everything feels right before I make things more complex. From the first week of testing, I'm confident that the project is moving in the right direction. From one tester who has played all other builds of Vectronic told me that this current build has better puzzle direction and clarity, and full of gameplay unlike previous builds that was just a bunch of mechanics, pretty rooms, but no gameplay at all. I got recommended a few changes I should make, like making the box heavier so when it crashes to the floor after floating in the air, it does not bounce off a button, or adding a plane of glass to block a more frustrating solution. A few tweaks still need to be made, solutions should just work, and not fully relying on the physics engine. I recall this being a problem with Quadrum Conundrum. Word of advice though, I learned that play testers hate fully ambient lit rooms, so before you release for testing, atleast put fill lights in. One tester told me it was hard to perceive the room with a full ambient light. I have one map with fill lights as a test, and he reported that when he got to that map, he had a better experience. I also found out that this method on leak protection didn't work when you packaged your games. It failed to initialize Steamworks although Steam was running. Not sure if this has to do with how packaged games work, or something I did wrong. I could of just uploaded the raw project, but that's a difference of 88MB vs 18MB. I'll work on this for the next build which I plan on posting a new test build biweekly. VecBall Design Yesterday, instead of writing this blog post, I was in an art mood, and wanted to put something back online with a model and sounds. I was using the old ball sprite and particle effects from the Demo, and I was really unhappy on how the dispenser looked in Leadwerks compared to how it was in Source. I decided if I was gonna touch anything art related, it was gonna be the basic foundation of the Vecballs themselves. I already had an idea of how I wanted my balls to look in the previous build. I'm a huge fan of how the Portals where in Portal in pre-release builds, and I wanted to reference that. This portal design required a large amount of textures for the mask, overlay, and other things that portals need. These portals took a whopping 174MB of VRAM PER PORTAL. and this was 2006/2007. I'm told that Valve cut it only because they ran out of memory on the Xbox360. Besides them being memory hoggers, I'm happy that I have them in a mod where they work exactly like how they did in previous builds. Unlike Portals, I can do a sprial/swirl effect with my vecballs without going over budget. I really liked the idea of the balls being a swirling ball of energy, so this could work. I made a quick texture and effect before I focused more on LEX. I later put what I've did in the Vectronic Demo. I pretty much just copy and pasted my swirl edits I had before into this build with a few changes. It still needs work, but it's pretty much the same as it is in the Demo, at least for now. Now to the dispenser. What makes Vectronic diffrent from Portal is that you loose your vecballs after each level, requiring you to recollect them in the next map. When I first sat down for the design of the dispensers, I sorta saw them as the item pickup bases in multiplayer games like Unreal Tournament. In Source, the particles stood tall and really stood out. But when I was transferring the design to Leadwerks, no matter what, they appeared washed out. This might be because of the colors, but I could not replicate how they appeared in Source. So I decided to take the dispenser back to the drawing board. I felt that the bases were too small, and needed a face lift. I quickly made this out of a cylinder in blender, added some base colors, and called it a day. UV sheet is still bad though, something I always have problems with. Attached a few emitters and sprites to it and got this in-engine. This is still not final as the ball sprite can still get washed out in the environment. I'm not gonna worry about it until I start messing with post processing effects and the overall look of the maps. I'm also open to suggestions. It's good for now, and it's a hell of a lot better then how they are in the demo! So that wraps this weeks report up. I guess this weeks goal is to ask more people to test the seven maps I have and seeing how I can improve those and other things before moving forward.

Oh, so THAT's how you do it. If I knew how to do that, I would not pass classes along as pointers in LEX. (Gotta remember, only C++ coding I did before was for Source.) If I ever make a LEX2, I'm using this for classes. Thanks!

I really enjoy the revamped script editor. I can't seem to get the auto complete to work though. Also, please no Skyboxes with suns. Sometimes the sun in the skybox will be in the wrong spot in how you want to light your scene.

I really need to look more into this in the future, Is it possible you could write a few blog entries walking through how to make a C++ class fully communicable with other lua scripts? That would be cool, as I'm not following you when you said:

Starting as a modder, and starting as a indie developer are two different things. When you find a game that you love and want to make more content for it, the developer would have a sample pack of raw maps and models for you to go off of, or the community would make decompiling tools so you can look at these raw maps and models. People tend to learn better if they have examples to go by, rather then starting from complete scratch when they start their indie game. The AI and Events map is a "almost good" sample map. Yes, it demonstrates how bsp geometry, flowgraph and AI can be used in maps, but I recall the textures not being their default scale on brushes, the wall height was around 320cm tall than the 256cm that is stated in the recommended mapping standards. It would also help if the map was released in various forms showing how maps are traditionally made showing that all maps start as blocks of dev textures first, THEN it gets the art treatment when gameplay is established. Many people tend to think that the map is made with the assets from the start. So in conclusion, I recommend you release all the raw sources of models and such you tend to redo. Doing this will allow people to study it, mod it, and learn from it. For instance, I really want a viewmodel sample model to help figure out how to make my own. I learned most of my knowledge from pre-made models and maps, and I feel it's a great way of demonstration.

I'm currently working with my scripts, and I don't think auto completion is not enabled on my end. It would be nice to have a checkbox settings in options to check if it's working or not, and an option for people who can't stand auto completing so they can turn it off if they want. In the meantime, what's the cfg entry for auto completing?

Does the auto complete have all the exposed lua functions, or just the ones documented in the API reference? I use a few exposed functions that are not documented.

As I mentioned in my previous post, throughout my time of developing Vectronic on the Source Engine, the project never had more than four maps because so much time and worry was focused on the concern of how it's going to look. While the overall art style, and the balance of visual noise is importation for a project like this, I was spending more time on this than making more maps and puzzles. I decided to once again start from scratch and only focus on the maps and gameplay for the time being. With this mindset, I've gotten close to seven maps shelled out in dev textures, placeholder models, and no lighting. On top of those seven maps, I've got two more ideas down on paper. With this method of developing, perfecting the how the elements interact with each other is much easier to do. I can easily change a puzzle, or how a puzzle is solved if something ends up not working the way I intended it to, without moving a handful of models and lights. As you can see, there is only a white ambient Light being used, Doors just appear and disappear, and platforms use the Sliding Door Script. Things are coded to be as simple as possible in this era of development. I even made the two ball colors primary red and blue for simplistic identification. As I said before, if the game is fun like this, It's only going to get better from here! With how fast maps are moving, additional elements that were not in the demo were needed quicker. And the new puzzle elements such as trip lasers and ball launchers only have basic functionality built in to not slow down the development of new maps. If something needs to be tweaked, it can easily be done with little worry of it breaking something else. The elements are being developed with the maps that use them, not in some zoo developer map with code that might be needed like I've done before. I'm making it so that each idea is it's own map. Although the engine would be able to handle a few rooms in one map, puzzle games are different then story driven games. Puzzlers need to be perfectly balanced. If you introduce something too soon, too late, or too many new things at once, the learning curve will not be well, a learning curve, and you can overwhelm, or bore the player. Having each idea or puzzle tied to one map, I can easily switch the order, cut out, or add in maps in-between without much headache. I might combine maps when the order of them settle in the future, but it might just be the really small ones. I've currently been making maps in order of progression, but I think in the future, I'm just going to make puzzles not worrying about the order of progression, and workout how (or if at all) they'll fit in the game. My goal is to get ten or fifteen maps done before I even think about how everything is going to look. At the rate I'm going, I should be back in Blender and Paint.net by next month! I have ideas about updating the visual style, but nothing I plan on talking about yet. Sorry about not posting this article Friday like I said I was going to. I want to write a development blog weekly for my sake of keeping me motivated, so expect at least that.

Works like a charm! Thank you a whole bunch, and I'm sure your work will help others!

If user's could still make their own tutorials like they use too, I'd be happy to write up a few. I do understand the want of having one official page of tutorials dedicated to the engine/editor, but other tutorials like tutorials Blender from YouGroove and "How to hack this effect" articles were useful, and fun to read. Only way users can post their own tutorials is forum and blog posts, which get buried over time. But in my eyes, it's best to leave your game stuff all in lua scripts, and only have the functionality of the application in C++. This is how LEX works.

I attempted this myself. The texture is in my LEX template. Although I made the texture for fun, it's very useful for testing how normal maps and speculars will show up. It's also handy for testing shaders.

Hi all, I'm pretty much almost done with the basic setup for my trip wires. The only problem I seem to have is that scaling the laser so it does not go beyond it's starting point and it's ending point which is always updating. My Code: function Script:Start() -- Ignore pickers from picking us! self.entity:SetPickMode(0) self.startpoint = self.entity:GetPosition(true) self.distance = Transform:Point(0,0,20,self.entity,nil) -- Sprites self.sprite={} -- The end sprite self.sprite[0] = Sprite:Create() local material = Material:Load("Materials/Effects/VecBall/vecball.mat") self.sprite[0]:SetMaterial(material) self.sprite[0]:SetSize(0.25,0.25) self.sprite[0]:Show() -- The beam self.sprite[1] = Sprite:Create() local material = Material:Load("Materials/Effects/laser1.mat") self.sprite[1]:SetMaterial(material) self.sprite[1]:SetViewMode(6)--Rotate around z axis --self.sprite[1]:SetSize(0.25,10) self.sprite[1]:Show() self.positionbetween=Pivot:Create() end function Script:UpdateWorld() self:UpdateLaser() end function Script: UpdatePhysics() end function Script:UpdateLaser() local pickInfo=PickInfo() local p0 = self.startpoint local p1 = self.distance self.endpoint = pickInfo.position if self.entity.world:Pick(p0,p1, pickInfo, 0, true, Collision.Prop) then self.sprite[0]:SetPosition(self.endpoint) --if(pickInfo.entity:GetClass() == Object.ModelClass) then if pickInfo.entity.script ~= nil then if type(pickInfo.entity.script.TakeDamage)=="function" then pickInfo.entity.script:TakeDamage(1) end end --end end self.positionbetween:SetPosition((p0+self.endpoint)/2) self.sprite[1]:SetPosition(self.positionbetween:GetPosition()) self.allignvector=p0-self.endpoint self.sprite[1]:AlignToVector(self.allignvector:Normalize(),2) self.sprite[1]:SetSize(0.25,self.endpoint.z/2) end function Script:PostRender(context) if DEBUG then local player = GameRules:GetPlayer() local p1 = player.script.camera:Project(self.startpoint); local p2 = player.script.camera:Project(self.endpoint); context:DrawLine(p1.x, p1.y, p2.x, p2.y); end end function Script:Release() if self.emitter~=nil then self.emitter[0]:Release() self.emitter=nil end end What I have now is OK for now, but I'd like to have this fixed eventually. When the model is pretty far from the starting point, it looks fine EDIT: Tried it with a longer trail, still messed up., but as the box gets closer to the source of the laser, the laser is drawn through the box. It's also axis based/dependent too, so that's not good ether! I need to get the distance from the midpoint and some how implement it to the laser's scale. I also having a hard time of it registering player collision. But I assume my main problem with that right now is that the player is a pivot. Also would like to mention that I'm using code from this topic. Any help would be appreciated.

I've been thinking about this, I'll try to mention this in the next blog tomorrow.

After a whole summer of working on the LEX template, and learning new things about the engine, I'm happy to say that Vectronic will soon be back on track in full development! Before I go into full detail, I wish to mention that the Vectronic Demo has been updated with Josh's optimization edits, and the VecBall has a new effect I've made during the development of LEX. If you had sluggish performance before, I recommend you check out the update! Now that I've got a nice foundation with a menu, a precache system, now what? I was thinking I would just be "upgrading" the Vectronic project to use the LEX template, but looking back on it, I'm not really happy how it is. Back in May, I really just ported textures, sounds, and models from my Source build to Leadwerks to see if a game like Vectronic would work on Leadwerks. Of course, I was still pretty new to lua scripting, and very use to pre-built lighting and such so I did struggle a bit, the demo map was not optimized, and most of my code is a mess. To wrap it up, I mostly did not know what I was doing. I still to this day see that demo map as a map from hell; I've had so many issues with it, but I'm happy how it turned out. Now 6 months later, I feel like I've learned a lot and ready to get back onto my main project again. I decided the best way to start is to start a new project based off of the LEX project, and redo most things. I've restarted this project many times over for the past few years, but this should be the last time. Back when I was developing this project on the Source Engine, I've felt like I needed assets to make a game. I thought if I had everything, textures, models, sounds and other assets done, I could build levels like a LEGO set; having all the pieces, and knowing where everything goes. It's a good theory, but it never really worked. A old Source build of Vectronic. I only had a few maps per build. The last build had 3 maps, and the build before that had 4 maps. There was never a set of interesting and fun levels, just a . Thing was, I was so worried about how things functioned and looked that no build ever got more then a few maps, I was distracted by other things that are not important in the pre-alpha stage of things, and so were my testers, which did not help move the project further ether.. Learning from my mistakes, this time the project is going to start blank almost like the past few years never happened. Doing the reboot this way will force me to worry about scripts, and the actual puzzles. This will also make it easier to optimize the maps when it is time to bring in the assets, and not have what happened with the demo map. No lights, no models, just CSG and a few scripts. If the game is fun with just that, it's easy sailing from there! Now, that does not mean I'm gonna waste more time by re-scripting, re-modeling, and re-texturing things that are already done. There are somethings I think that can be better, and I do have ideas I wish to try, but not everything needs to be scrapped, somethings just need a revision. I eventually want to give Vectronic a look that only Leadwerks can give as the demo does look like it's running in Source. But right now, the basics need to be done! I hope to update every week on progress, I'm feeling this Friday I'll talk more about how I'm doing things and short term goals.

There are some cases in which you do need brushes not collapsed. The indicator lights in the Vectronic Demo are an example as they need to be told what color to change to during run time.

Easiest way to do this is lua. self.sound = Sound:Load("Sound/Player/Footsteps/concrete1.wav") function Script:PlaySound()--in self.sound:Play() end You can use the Flowgraph or have a trigger that emits the sound on Collision.

Strange. I tested it as a package with the stock template. I assume you've merged the template with your game which is something I don't 100% recommend. Try testing it with a clean LEX template, or launching it under sandbox mode (-sandbox) Also are you using this script for map transitions? Something you need to understand is that when the game is not launched in sandbox mode, the game uses the App class that's integrated in the executable. When you launch from the editor or that game launcher, the Main.lua script will act like the stock executable, and the scripts shipped with the template are meant to handle both sandbox and non sandbox cases. The loading screen is handled on the exe side of things if it's not ran in the sandbox. You can change it by replacing the loadingscreen_default texture file, or name a texture the same name as the map file, and the loading screen will show when loading that map. (Just make sure you put it under Materials/UI/LoadingScreen) Although you might not have the standard edition, the code is there for reading/debugging. (Map loading/saving is handled in rworld.cpp. Oh, and you can fix the clientscheme file not copying to the build folder by adding xml to the file include list. Since it's in the root directory, it should copy over even with "Only include used files" is checked. Also, keep in mind that none of the functionality of LEX will be in your Game Launcher Releases.

After the recent beta update, decals no longer show up on brushes, although they are told to do so. Decals still appear on models and terrain. However, when in-game, decals draw on brushes as they should.

Sent a PM, and studying the map now. Can't thank you enough. Map runs amazing now with that update/exe.

Thanks! I can't wait to hear what needs to be done and the mistakes I've made so I don't make them again.

Thanks Josh, since you have the raw project, just drop/replace these files. I've added Shadmar's script to the Main.lua script, while changing a few things in the map. vectronicdemohalp.zip

I disabled textures that use it and my batch count is still high. the framerate only increases if you look at a certain direction in the room. This map alone has been giving me issues since the beginning, and really gave me ideas on how to do things better when I reboot this project.

Nothing is moving in that screen. This is in that hallway right before you hit the trigger for the floor to raise up with the dispenser. The pillars/platforms that do move on the button press are set to a dynamic ShadowMode. I had an idea about the batch count, but it did not seem to be the case, so I have to look more into it later. Also, quick question: Will using Caulk textures improve the overall framerate as there are less polys, or it does not matter? I noticed the AI and Events map is all textured while my maps have Caulk textures on the outside of the maps, and any other place that can't be seen,

I'm currently playing with optimization with the Vectronic demo. After removing Buffered spotlights, and adding Shadmar's culling script, my framerate has increased, but this room is still hell when you look forward, and the Script Memory Usage count rapidly keeps climbing. Are these results "too high"? I'd be nice if they changed colors if any of these numbers get to be dangerously high as a clear indicator that something's wrong.

To Break: Open a map/Create a new map. Create a box, light or any other object. Open Single Viewport for the Perspective. Double click on a entity in the scene tree (Or right click-> Go To) Exit out of Single Viewport mode to see that your grids are messed up. To Fix: Right click on a broken view port, Go to Render view and select a different view angle. Then, change it back to the previous view angle. Continue working.