It's that time again! Yes, it's almost Christmas, but I'm talking about another article about Vectronic! I apologize for the large gaps in between updates, but I like to have a lot to talk about each article. So let's get on with it!
First it's worth noting that I decided to port the project to the Alien Swarm branch, or to be more exact, a modified version of that branch. Now, you might be asking why as I have less resources, harder to modify, and it would mean that Linux and OSX is out of the picture. Well here's the story.
After I wrote that article in August, I ported Vectronic to Alien Swarm's branch just to see how much work it would need, and how much I would get out of it. Surprisingly, only few changes here and there, particles needed just to be re-saved, and two model's animations needed to be called differently on code. With all that work done, I did not see much from it as I felt it looked the same it did in the 2013 branch. I also thought about how much harder it would be to publish, and the fact that my current menu was not working correctly. So, I kept it just in-case I wanted to go back to it at some point, and work continued on the 2013 branch.
Around October, I noticed that Valve updated their repository for the engine branch. So, I cloned the latest update, and simply built Vectronic's vpc scripts and all went well with compiling, After the game crashing on load, I learned that I needed to opt back into the beta branch in-order for it to work. After that, it ran fine.
The next step was to rebuild my vbsp to add in that lovely -nocubemaps parameter so I can properly build the cubemaps for the maps in that branch. However, when running the application, I noticed that my compiling tools were acting strange.
My vbsp would run outside the compile window and upon completion, it would recompile or reprint itself in the main compile window. It was the same story using batch. Since it was my vbsp I was using, I assumed I did something wrong. So, I reverted back to Valve's stock vbsp, and I had same issue. Validated the SDK, and it worked properly until I went to use my vbsp again. Not only was the map compiling tools acting strange, but most tools were. studiomdl behaved the same way; same goes for vtex. I don't think it's Valve's eco-system; it must be my PC as some of my basic console based applications (like vmffix) would act the same. Ether way, it was very weird and I could not find an answer for it. I was gonna just deal with this until I went to compile models with animations which took to damn long to compile, only for it to compile again.
Working on Vectronic became very frustrating, very quick. I already had the issues of the cubemaps, This branch's Hammer being Nividia GPU Bias (AMD users experience crippled numbers and missing cursors.) and now the fact that the compile tools would run outside the called windows making compile times longer then they should be. I decided to give my Alien Swarm build another look based on these issues, and I saw a custom GameUI beneficial.
I tested the compile tools to see if the branch's tools did the same thing, but everything ran normal. I updated the Vectronic solution, re-copied the mod over, and within a few hours I had a working build of Vectronic on the ASW engine with slightly better tools with more features.
I noticed that the engine it called a lot of Alien Swarm related convars, textures, and other stuff that was not there anymore. It was hard to tell what was vpk'd and what was easily override-able. So, I made a new folder under the common folder, and rebuilt the game's file structure from scratch to make sure that it's totally independent from Alien Swarm and Valve's updates.
To make a long story short, I made a template mod, got help on updating the branch build to be a bit more like Portal 2, and then ported Vectronic to it. After Vectronic was fully on the new branch, I updated textures, particles, fog settings, and I started to see the branch show more of it's shine. It took two months to do it, but it was totally worth it, and I'm glad I did it. Vectronic can now use instances, vscripts, projected textures, and has it's own SDK launcher!
Focus on "Mod-ability"
After that whole event, I started to think of Vectronic as a whole. I mostly get comments about the project being a Portal clone. While it's sorta like that visually, I did not want the actual game to feel like it. I did not want to do the whole wake-up sequence, AI over loudspeaker, solve puzzles because you're there, etc, etc. I want it a first person puzzler, not a Portal clone. I mentioned before that I was most likely not gonna add a story or anything, and just make it more of a proof of concept thing. I'm still planning on doing that, but If I just did that, the end project would be very bland. What this project needs is what Portal did not have. Although I enjoyed mapping for Portal and Portal 2, there was one thing I did not like, and that was how cumbersome it was to add you're own elements.
Don't get me wrong, it's possible to make you're own crazy elements in the Portal games. But like in Blue Portals, you need a good amount of entities working together, and it might turn out clunky, and not really fail-safe. And when you go into Portal 2, a lot of coded elements are coded in, and modding anything in-general can be chore due to the branch's file system, the fact that the workshop only accepts raw bsps, and no addon vpk support.
One of the reasons why I started PUNT (which became Vectronic) was to get away from those limitations, and to be able to create without any boundaries. While I'm freely able to do this because I have the source code for my own mod, I did not want users to feel limited, or second class if they wanted to make their own maps, and elements. This became the new focus on the project as I think a static, linear puzzle game would not have long life after release. After all, Portal games only still kick because of community maps. You don't see games of the same genre without mod support getting the same love.
The first thing I think people would want to do is make their own vecballs with their own colors, that made the boxes do their own events. This meant the entire vecball system needed to be heavily modified.
The vecball's previously had their own separate sprites and particles (One for each ball: Blue, Green, Purple, etc). And props like the dispenser, launchers, and box have multiple skins for each vecball also. If this system was to be kept in place, modders would need to make their own sprites, particles, hex the models, make new skins, and override the stock models with their custom models with a vscript. I dunno about you, but that seems like a lot of work just for people to add their own vecballs. There had to be a better way.
I first added three more balls on top of what was already there. With a lot of merging, coding, debugging, I've managed to have all balls share particles, sprites, and the models render the vecball's color. Oh, and the cherry on top is that the user can fire their vecball with the weapon and have their box logic be in a vscript! You've read right, there will be no need for hacks or overrides to make your vecball like the main three.
I'm sorry for the book of an update, but I just want to be clear although I do not update a lot, I do work on the project very often. I plan to release a close beta early next year with content creators, followed by an open beta later. An open beta for a Singleplayer game is atypical, but this is not a typical mod. After that, I may open a Greenlight page so the mod can be easily installed with the Steam client, maybe workshop integration if I can.
I started this project just for fun, and I've learned so much from it. I'm eager to have this out so you can play it, and play with it. Thank you all for the interest of this project, and I'll always keep you posted!