Several development videos can be found on my Project Universe Playlist on YouTube
After coming up with the test framework that auto-generated points and connected them with lines, I realized that there might be times when more control was needed over the placement of points.
One example of why someone might need this is from an earlier attempt I made to create a web game. This was going to be in an actual web page, no plug-ins needed. The conceit was that you’d be in a city, and you’d have to move between different locations for different reasons. One location might be a bar, another might be a drug den, and another might be a corporate HQ. The player would have a map of the city (or at least a part of the city) and could click on an area to have that area “load” whatever the heck is going on or whatever the player can do at that location.
This kind of situation would require two things: a map, and a way to define the points. I had at one time actually created a pretty slick prototype which allowed the admin to draw “roads” on an image of a map, and those drawn regions could be clicked to add meta-data. But it was a lot of work for little benefit: there’s no reason to have the whole street defined that way because you’re ultimately only interested in the places on that street.
So the idea here is to allow the user to upload a map, which is added to the canvas. The canvas then has a grid generated (like in the previous example) in memory. This allows the user to click an area on the map and have that grid square defined as something the user can click (once the definition is applied to the mechanics of the game itself). When the player clicks on a “hotspot” they will get the info or interaction opportunities built into that click. (As a note to self, I need to allow for the conjoined placement of hotspots that both link to the same meta-data ID, so a player can click on one square or the other can get the same results. Good for large doors, or possibly even an entire room. Also, different doors on a building that lead to the same interior).
While out walking the dog this morning, I thought about how to link these, and whether it was worthwhile to actually link them at all. One possible mechanic is to slow the player’s movement by forcing them to travel through nodes to get to a destination rather than having them click a node on the absolute opposite side of the map and travel there instantly. Not only does it force the player to deal with situations that arise while in transit (as this was envisioned as a cyberpunk game, which means loads of street-level mayhem), but it also provides an opportunity for other gotchas. In TradeWars, for example, you had 100 turns per day. The same could be used here. You only have so many moves per day, and moving between nodes takes one move. Old school.
To handle links this time, nodes would need to not only be placed to represent doors and other “endpoints”, but also at places like intersections where several node paths connect, forming “hubs” that allow the player to take all kinds of different routes. Because the maps provide the visual cues, we wouldn’t need any kind of route calculation mechanism. We’d leave that up to the player. So a node at the intersection of Main and Archer would lead to nodes along the “Main Street” route — a bar, gym, and police station — and also “Archer Street” — weapons shop, drug den. The intersection node would also lead to other intersection nodes where Main meets High St, or Archer meets Rt 89.
To make this happen, the system would need to switch over to node selection mode. This time, instead of clicking the canvas to add a node, clicking on an existing node would set the start point for a route. Clicking on a different node would set the end point for the route. When you click on a node that has a route endpoint assigned, you’d see which other nodes it’d be connected to, and could delete that route from the sidebar if needed.
I’m not sure which method I’m going to continue with. The random generation method is good for a space trading game because I can generate a lot of points and random routes, allowing for the creation of new games (what TW calls “Big Bang” or just “Banging”). But I’ve got a whole lot of cool ideas for a city based cyberpunk game that would benefit from a place-your-own system. I need to figure out the how of the node linking on the place-your-own method before I decide.
“No matter where you go, there you are” – Buckaroo Banzai
I can place locations as one-off bits of data. That’s fairly simple, made simpler if you construct a grid, and then select a random sample of grid squares to hold stations, solar systems, or whatever thing you want to create.
But getting from place to place? That was harder for me.
In TradeWars, you would travel between sectors that were known only by their numeric ID. If you checked your computer, you’d see that you could jump to sectors 62, 187, 14, and 90. In order for those digits to mean something, you would have had to have visited them and written down what’s there, if there was anything at all. Making things weirder (or worse) was that those sectors were reachable from your current location — sector 652 — meaning that there was no linearity in the universe.
If TW used a grid system, then traveling from sector 652 to sector 14 would shoot you across almost the entire virtual map. Not only did you need to know what was in sector 14, but you had to understand that unless you’re a savant and memorized all the entrances and exits from each and ever sector, the link between sectors 14 and 652 had no intrinsic logic whatsoever.
I wanted to model something like this, but visually.
This is an HTML5 canvas showing the data points listed on the right (sadly the randomizer didn’t create convenient data for the screenshot). The first column is the X,Y coordinates of the virtual grid square. The second column is the center point in pixels of the grid square. The last row in the shot shows two other sets of coordinates which represent the destinations of the “gates” between “zones”. Here, the point at 16,48 has lanes that lead to center points of the grid squares at 656,176 and 752, 112. Although you can’t see it, it works in reverse as well (so you don’t get trapped in a one way dimension!)
The basic plan of attack is this:
Overall, nothing fancy. My original attempt had issues, though, in generating the destination zones for some reason I cannot understand. I stripped the code out and re-wrote it (keeping the math that worked) and using a much truncated version was able to almost instantly get everything to work as desired. I hate when that happens.
This is really just an exercise, although with a proper fortification I was thinking of using this kind of system for a simple web game.
After having recovered some work I lost on Friday, I opted to put the programming aside for the weekend. By Sunday, however, I was thinking about what I could do that wasn’t programming. While I’m an OK developer, I absolutely suck at the art that I’m going to eventually need for this project. I have a few options, though. I could scour the Unity Asset Store and buy stuff. I have done that to a degree already, with Space for Unity and a few packages for particle effects, but the downside to that is that what’s available to me is available to everyone, and that runs the risk of making the project look like it came from a starter kit. I could hire an artist to make stuff for me. When it comes to hobbyist game development, there’s no shortage of developers, but there’s a black hole where artists should be. It’s easier for artists to make stuff and sell it through the Asset Store, and with so few bodies on-call, I’m sure they can pick and choose their work and charge what they need. I don’t know what that would cost, but considering I have a budget of $0, I don’t think I could find anyone in my price range.
I’m not a terrible artist, mind you, but doodling stuff as a past-time doesn’t come anywhere near the skills needed to create 3D art for a video game. But nothing ventured, nothing gained, so I downloaded Blender again (because free) and signed up for the subscription to BlenderCookie.com again (sadly, I had a sub before, but didn’t even use it). I went through their Intro to Blender tutorial (also free), and then engaged a two part tutorial on making a fuzzy burlap elephant. At the hands of a professional, it wasn’t all that difficult. However, that’s a specific case; nothing is difficult when your hand is being held throughout the proceedings. The real challenges are legion:
Everything is daunting when you approach it with little to no knowledge of it. There’s so much to learn, including the most basic baby steps (i.e. the tedious parts), even before you can think about making anything interesting or useful. Meanwhile, there’s a world of professional output out there that serves both as an inspiration and a trap: work hard and some day you’ll be able to render like the pros. Try jumping the gun to render like that, and you’ll get tangled up in frustration, miss a lot of the foundation needed to be able to work independent of tutorials, and end up quitting the entire process.
The last step, then, is to stick with it. I keep up with my development skills because it’s also my day job (not game development, sadly), but why the heck would I need to render a fuzzy elephant on command? It has to be something that I end up doing just for the sake of doing, which I can totally do…but like anything else in adult life, I have to make time to do it.
Filed under “From Left Field”:
UnityVS is an app that allows Unity developers who use Visual Studio to live-debug Unity scripts. Right now, developers can attach Monodevelop to the Unity.exe process, but Monodevelop lags behind VS in features and stability.
I’m very excited about this, as I prefer to use VS when working with Unity. I’ve had to jump back and forth between VS and Monodevelop for general development and debugging abilities, and have then had to grump my way through the weird and sometimes unresponsive break point system in Monodevelop.
UnityVS is going to be released for free from Microsoft once they get the branding and licensing agreements re-worked.
I really like Playmaker for Unity. It can shave off a lot of time when developing, but I’ve recently found that it’s not omnipresent.
Due to a — confusing mishap — I’ve gone back in time to a previous code base in which I’ve scrapped my scenes except for the initial main menu screen (new game, load game, load base data). That means I’ve had to re-create the initial post-menu scene from scratch, including player motion and the station trigger system.
I wanted to replicate my earlier design, but because of previous refactoring, I found that Playmaker was having a hard time getting references to scripts on !=Enabled objects when the Playmaker script was placed on an object in a prefab. I wanted to make the docking trigger a prefab so I could just drop it in there, but it wouldn’t see the UIManager script I needed in order to display the docking prompt (the docking prompt was !=Enabled).
So I decided to put Playmaker aside for the moment and get back to scripting. The triggering isn’t difficult. There’s events for Enter, Exit, and Stay, and I need all of them: Enter to display the prompt, Exit to hide it, and Stay to listen for the “F” key to dock. I put this script on the sphere trigger, set the collider to Is Trigger, hide the mesh, and it’s all done.
I think this is going to end up being more powerful, because now I can make special cases for NPCs that will be entering the trigger sphere. Should an NPC path take them into a sphere, they are considered to be docking as well. They should “vanish” to show that they’ve docked, and should “reappear” when it’s time for them to leave. I should be able to handle that with the trigger script, whereas with Playmaker that functionality would be more obfuscated and difficult to keep track of.