Build an interstellar financial empire and prove your worth.

Project Universe is a game of interstellar exploration and commerce. Begin the game with a hand-me-down hauler and trade goods, freelance for powerful factions, and make a name for yourself by battling pirates and exploring the galaxy. Project Universe is a single player game currently in development for the PC using Unity.

YouTube Channel

Several development videos can be found on my Project Universe Playlist on YouTube

Read More

Unity and Tools

Project Universe is being developed using Unity and several other tools.

Read More

About The Project

Want to know more about the background behind Project Universe?

Read More

More On HTML5 Map Making

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.

Read More

Visualizing Connections

“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:

  1. Define the grid. Using an 800×600 canvas and a 32×32 grid square size, divide the grid into equal squares, tossing out the remainder of the calculations. This ends up with something like 18 rows and 24 columns or something like that. We store this in an array.
  2. Determine where the systems are. Using a RNG, pick some items from the array by index. Those guys get an object property HasSystem set to “true”.
  3. Link em. Using LINQ, I pulled just the HasSystem objects from the array. Looping through them, another RNG number pulled out random indexes from the same subset (but omitting the current zone from linking to itself). The destination zone was stored in an array property of the current zone. I opted for an array property because one system could link to multiple systems. It made sense, and would give a player opportunity to recognize a “hub” system that would lead to different corners of the map.
  4. The resulting set was serialized to disk as JSON, which could be loaded into the canvas and plotted.

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.

Read More


The Fuzzy Elephant In The Room: Re-starting Blender

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 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:

  1.  Modeling is something that can be learned. Art is the…art…of observation and translation. You need to be able to see objects and understand their shapes, and be able to replicate those shapes. And everything starts from shapes. 3D modeling (at least the type I am familiar with) is all about taking a primitive shape and warping it to look like what you want to make. Considering how many people have taken a box of LEGO bricks and have made cars, houses, and thousands of other recognizable analogues, I firmly believe that this part is the “easy part” of 3D modeling.
  2. The tools can be learned, but takes some academic understanding. Blender is a complex mess. I haven’t tried using 3DSM or Maya in years, but considering the complexity of 3D modeling, I can only imagine. There’s a lot of tools, options, and operations available to make things quote easier unquote for the artist, but the artist needs to know how to use those tools, and how to use them effectively.
  3. Terminology is difficult. Like any technical discipline, 3D modeling comes with it’s own suite of terms, jargon, and concepts. Like a lot of disciplines in general, the ability to learn the terms hinges on an understanding of the concepts, and understanding the concepts usually involves understanding the expected outcome, and the potential pitfalls of doing it wrong. This actually loops back to being competent with item #1, and understanding item #2.
  4. Learning modeling is one thing, but learning modeling for game development is another. Maybe I can render a space ship that I like, but then I need to ensure that it’s fit for import into Unity. That means it needs to be structured correctly (tris over quads, correct texturing constraints, etc), needs to have animation for ambiance (blinking lights, thruster fire, other moving parts), and then it needs to work its way through the proper pipeline into the development application, with textures and materials and models all properly imported. Oh, and it needs to be of the correct scale, so the player ship isn’t pin-head sized, or the size of Jupiter.

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.

Read More

UnityVS Bought By Microsoft

Filed under “From Left Field”:

SyntaxTree, maker of UnityVS, announced today that they have been acquired by Microsoft.

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.

Read More


Foundations #Playmaker #Unity #Gamedev

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.

Read More