Sunday, November 16, 2014

Super Hairpiece, Infinity Ward.

Hey bros and anti-bros, I've got some news. This might be the last post for a while. Or at least the last post that is video games related. More on that later, but first!

Super Hairpiece

I made this game along with some friends at the PurpleMonkey Gamejam some time last month.


The game is about throwing a toupee on to a procedurally generated bald spot on a guys head. You should try it out.
Here are the links:

It's also got a nifty screenshot mode so you can take hair-larious (im so sorry) pictures of your styled dude.


Woooo super hairpiece! What else?

That job thing

I got a job at Infinity Ward, the guys who make some Calls of Duty (or is it Call of Duties?) making their video game programs work! That means I'm actually posting this right now from an apartment in Woodland Hills, CA. Yeah, I moved to the west coast. Sorry boston dudes! We had fun though, there's no way I could have gotten to where I am today without the filthybrutal Boston indie games scene, including the Boston Unity Group, Boston Post-Mortem, Boston VR, Boston FIG, and of course the Boston Indies meetup itself. So sentimental! Hopefully there are about a thousand equally cool meetups in LA.

Oh yeah, and there's a non-compete agreement that comes with the job. That means I can't work on any games in my free time or they automatically become the property of Activision. Super unilateral and fair! That means no more work on weird indie games, incredible virtual reality experiences, or Unity plugins. I'm not sure about gamejams, but we'll find out. I start work in a couple days, and I probably won't be able to say much about what I'm doing (hint: it's probably call of duty). I guess this is the price we pay for unimaginable heaps of money.

Woodland Hills

yeah this place is ok, though I kind of hate saying the name of the city. It sounds a little pretentious. "woodlizard hills" or maybe "woodlazer hills." only time will tell.
I'm within walking distance of TWO malls. I didn't need two... but if you do the math, that's equivalent to like seven chipotles. Which is basically the only metric that matters. It's all grids and six-lane murder roads. Nothing is small. Everything is a chain or a franchise or an apartment complex or a mall or a huge office building. I'm in temporary corporate housing right now and I dislike it, though that's mostly just the low ceilings and the cookie-cutter way everything fits together. And my last complaint is that having a car is somewhat mandatory.

Well, that's it I guess.

BLOG: DESTROYED.

Tuesday, September 2, 2014

BOSSMODE FIVE WAY VIDEO

Hey guys, BOSSMODE is coming along. Here's a video of me playing five instances of BOSSMODE at the same time against the first boss.


Pretty cooooool huh?

Saturday, August 30, 2014

BOSSMODE and Particle Shadow Maps

Hello brothers and sisters, I bring you news of video games. BUT FIRST! The particle shadow maps must be seen.

VIEW THEM. VIEW THEIR SPLENDOR.

This video is long, but it is not required to watch the whole thing.

ok. time for 

BOSSMODE



BOSSMODE is a game that is all boss fights. It's also networked multiplayer. I'm trying to make a game that is a cross between raiding in WoW and Shadow of the Colossus. You move around by applying a torque to a cube. And when you shoot microcube death primitives, it also applies a force back to you. Use this to your advantage. The engine is basically done so now it's on to ~content~. Which is boss fights. Which is allllll self contained game design. isn't this great?

is this awesome y/n?

Tuesday, August 19, 2014

Who wants to see some shadowed particle systems?

Awww yeah, I made some neat particle systems with volumetric shadowing!

This first one uses the technique here: http://docs.nvidia.com/cuda/samples/5_Simulations/smokeParticles/doc/smokeParticles.pdf


The hardest part of this was definitely implementing a GPU radix sort. My recommendation: don't. The hard parts are always, always in the details (calculating those local offsets, I know right).


Particle Shadow Mapping

Because the technique above is kind of bad with multiple viewing angles (note that I don't pan all the way around the particle system here), I ended up implementing a different technique: https://developer.nvidia.com/sites/default/files/akamai/BAVOIL_ParticleShadowsAndCacheEfficientPost.pdf

Particle shadow mapping is rendering the particle system into a 3D texture and then using a compute shader to propagate the light transmittance though that 3D texture. This one is a lot more stable and also probably faster. It still requires sorting for the final rendering, but doesn't require sorting for the shadowing information.


The performance is kind of bad but that's just because of Unity not being able to cope with sorting 50k particles. I'm going to get the GPU radix sort working with this one too, but it's not currently in that video. If only CUDA worked on both AMD and nvidia, I'd just be able to use their library to do this sorting stuff, but NO. This is why we can't have nice things.


Bonus

Guess who owns shitty.fish? Yeah. I bet you didn't even know that .fish was a top level domain.

Friday, June 13, 2014

Shitty Fish, Smoking Photoshop, z0ne (formerly Rift Wars), Fire Hose office, NPLB

I've done many things since we've last spoken, old friend. Let me regale you with a story of days long since passed.

Most recently,

Shitty Fish

During the ~Great Boston VR Bender And Game Jam~ I worked with the talented Mark Stock and Jim Susino of the Boston VR meetup. We produced a game called Shitty Fish. The goal of the VR jam was to produce games that used Valve's prototype head mounted displays. The prototype HMDs are something like 1200x1k in each eye? I'm certain those numbers are wrong. Oh and they're also low persistence at 90 Hz. The Valve guys said that making the desired frame rate is of great importance, and suggested that we target a graphical fidelity reminiscent of Quake 3. With these guidelines in place, we three set out to build a video game in which you are a sea snake.

In Shitty Fish, the game is entirely controlled by the rotation and translation of your head. The idea is to slither. By displacing your head in a slithering motion, a snake body model is simulated (thanks to Mark for this math) and forces are applied to the snake body based on this model. It turns out, this is really really fun. One of the Valve guys said that it was probably the most innovative use of head tracking he's seen so far. Oh and also playing the game for 2 days straight can result in a sore neck. Relatedly, we had a man with chronic neck pain who tried Shitty Fish during the demo night and said that his neck felt much better after playing it. Shitty Fish is basically neck exercises: the video game.



This is my friend Joe trying out the shitty fish demo with a Rift DK1

This is Mark, playing Shitty Fish on Valve's prototype HMD with positional tracking.


Here's the download link:
Hope that my google drive doesn't throttle this.

Some other notes:
  • This game would be pretty cool if you could actually play it while being underwater. Some of the limitations of having to deal with gravity make it difficult to reach every neck/head position you'd like while still having to stand up.
  • The game is made with the SteamVR plugin, which abstracts the specifics of the HMD's respective SDKs. That means that using the SteamVR plugin, you can make your game work somewhat seamlessly with both the Oculus Rift, and Valve's prototype hardware. It may even be the case that the game will work with the DK2 without modification. How cool would that be? The disadvantage is that you probably don't get some of the Oculus proprietary goodness like timewarp and other things??
  • The Valve hardware is amazing. Positional tracking, ultra high resolution, high refresh, low persistence all together make a very compelling VR experience. There were a few quirks, namely that the black-to-white refresh was two frames, so if your game has a placeholder black-and-white checkers texture, you will see some pretty weird artifacts as you move your head quickly. Also there were some disorienting tracking discontinuities around where the HMD lost positional tracking from going out of line of sight. Maybe there's no way to fix this, but it would be nice if the system handled it more gracefully. Lastly, sub-90 frame rate in low persistence is perceived very differently than in a full persistence display. A low frame rate is much more jarring and teleporty. It's like a ton of tiny jump cuts. They were right about how important it was to reach the desired frame rate.

11:11, Smoke Photoshop Everyday

I've been trying to draw something every day! Here are a couple of things I have drawn in photoshop:


I think some of these drawings are pretttttty cool. Yay, sunk cost!
Here's the rest of the album if you're interested:

z0ne


We changed the name of Rift Wars. The name had to go for a few reasons. z0ne is all right, but putting a number in your name is sort of a faux pas. I don't really care that much. There's a lot of exciting stuff going on with z0ne, and we're hopefully going to show it off at the Boston Festival of Indie Games. James has been leading the development for the majority of the levels, and I've been sort of less involved in the last month or so, but I've been giving my feedback where I think it's important. There's a lot of cool new content in the pipeline. Here's an example:  


Here's a video. https://www.youtube.com/watch?v=epmJjPrNDXo (I'm not sure how to embed an unlisted video)

The Chamber of Silence

Also known as the desk I am renting at the office of Fire Hose games. Seth and I are renting adjacent desks to better facilitate our collaboration. So far, it has been a huge increase in productivity. There are difficulties in getting to the office on time (whatever that means), and it is a little bit out of the way (20 minute walk from the train station) but otherwise the office has been a pretty huge win. Also it totally makes me a hundred times more official. And the Fire Hose guys are super cool. And I ate some rose flavored ice cream at a cool local ice cream place.

NPLB

No Pineapple Left Behind is getting pretty crazy. We've got a ton of cool arts to show off:



And there's this totally sick Cantaloupian text book page example:
Cantaloupian is a constructed language we had made for students to learn as a foreign language. It is designed specifically to be difficult for english speakers to pronounce.

Aside from the awesome art, we are getting pretty crazy crunching this week so that we can make the Boston FIG deadline for a playable build of the game.

BONUS

Here's a hyper realistic video of a particle based fluid simulation that I've been working on.

Monday, April 21, 2014

Game A Week Challenge week 2: Riftwars Arena. Also PAX East.

So I didn't do a game last last week because of PAX East, which was crazy and I'll get to that in a moment.
The game for this week is Riftwars Arena!

Riftwars Arena is an online multiplayer 6 degrees of freedom deathmatch game. You fly around in your spaceship and shoot other dudes. You can fly down in the lower part to be near obstacles so that you're harder to hit. You can fly around upside down (what does that even mean?) and you can flip and roll and do all sorts of cool aerial maneuvers.
You can probably tell that this is heavily inspired by Descent, which is probably one of the best old games ever.

How do I play this?

Well, here's the thing. You can't. 

wtf man?

Ok, so I know that the whole point of the game a week thing is to make a game that people can play every week, but this time, James, the other half of PixelRouter VR (btw, I am the other other half now, and will be releasing all future collaborative titles with James under that name) has recommended to not release this demo because of strategy. During the week we were developing this, our original collaborative project Riftwars kind of got some attention.

Here's a list of medias regarding Riftwars that occurred last week:
The summary of events is something like this: James went to PAX on sunday with his rig, and without buying any booth space managed to setup and demo Riftwars to a pretty full crowd for most of the day. He posted this on reddit and people started talking about it.

James advised me not to release a demo of Riftwars Arena because we didn't want to distract from the Riftwars demo release. I know that putting a download link to Riftwars Arena on my shitty blog that no one reads will probably generate zero interest from zero people, but I'd rather not rock the boat this time.

Fine

so there you go. I wound up demoing my game at PAX and now you can't play Riftwars Arena. Too bad. You'll probably get a demo in a little while, though I won't make any promises (like my promises mean anything). Also, we might be going full steam ahead on trying to make Riftwars into a real video game that people can buy someday. Isn't the world a weird place?

Riftwars Arena pre-post-mortem

Because I haven't technically released it, but I am pretty much done with it for now, I will write about what went right and what went wrong.

Good:
  • The six degrees of freedom controller is actually really fun to fly around with
  • The networking actually works! I'm getting better at writing networked code.

Bad:
  • Ship model isn't very polished, no textures or interior ship model.
  • Shooting feels kind of weak.
  • Whatever you do, don't shoot the gravity mines.
  • No menus or instructions.
  • Some people have trouble with the controls.
  • uh, didn't actually add in Rift support...

Terrible:
  • It's really hard to actually shoot fast small ships in such a big space. There are a lot of scale problems in general.
  • I spent way too long on the netcode (~8 hours), trying to fix up interpolation issues, which still aren't perfect. Things get pretty bad under packet loss conditions.
  • You can't actually die or respawn yet.
I guess that's it! I guess I'll be doing a game this week? Though, there's 3 events (boston indies, boston unity group, boston vr meetup), so it might be kind of short or bad or maybe it won't even happen.

Tuesday, April 8, 2014

CUBE DEATH PRISON


Here it is: https://drive.google.com/folderview?id=0B209xEE7EEixbHk4XzNfMUdzeDg&usp=sharing

This is my first game a week game! You should know, you'll probably need an 360 controller, or something that fakes your computer into thinking that your controller or keyboard is a 360 controller to play this. Also, it's probably only going to work at full screen at 1920x 1080 or higher, though you can test your luck with this.


CUBE DEATH PRISON is a four player cooperative (or not) twin stick shooting game! Murder cubes in the CUBE DEATH PRISON. Collect microcubes to bolster your Numerical Cube Murder Indicator. Avoid cubes to sustain your cubelust! Circle strafe to morph your true einherjar form!


CONTROLS:

LEFT STICK TO APPLY TORQUE
LONELY RIGHT STICK TO PERPETRATE CUBE VIOLENCE
RIGHT TRIGGER TO CHARGE ADVANCED CUBE ARTILLERY
LEFT TRIGGER TO EXTEND LASER APPENDAGE
RIGHT SHOULDER TO CALCULATE GRAVITY
LEFT SHOULDER TO UNCALCULATE UNGRAVITY
START TO HALT THE FLOW OF TIME

Post mortem

Well, it doesn't work in VR, and it doesn't work in a webplayer (maybe this will be fixed in a while, as this is a Unity beta problem). Also, I was two days late, the game should have been done on Sunday. I will therefore, do a truncated video game week this week. Something simple like a text adventure or a puzzle match three thing, or maybe something else?? Overall, I am pretty pleased with how CUBE DEATH PRISON turned out. It has fun mechanics, compelling progression or at least difficulty. And you can play it with your friends if you have enough controllers. I like that I get to make up fun stories for the menu text.

Things I don't think went the best are the sound effects. The sound effects are kind of bad and also repetitive. And there's no music. Another part that is bad is the compatibility. Only Xbox controllers, and that means only windows and then there's the problem with the UI not scaling exactly right for every resolution.

OVERALL SCORE: 92 REINDEER CUBES.

[escape this fate]

Monday, March 31, 2014

Game A Week Challenge: Week One

If you follow my tweet or face machines then you probably already know that I am going to be embarking on a video game making challenge. If you haven't heard: I am going to be embarking on a video game making challenge! The goal is to make one game each week, from start to finish. Included in that are menus, win and loss conditions, assets, and game mechanics. The point is to become experienced with making all the parts of a game, which is something I have failed to do thus far. In fact, (with the exception of game jam games) I have failed to actually make anything someone can play from start to finish in the past year and half of this weird game dev experience.

Btw, I'm still working on Seth's secret game, and Bad Things Happen in Space has been put on hold, but is not cancelled. When Bad Things reawaken, it might take a different shape, but I still have the dream of making a multiplayer-space-panic-intrigue-simulator. Also I applied for a Unity dev job somewhere in Boston, but who knows if that will actually happen.

Beeminder

Here it is! https://www.beeminder.com/pyromuffin/goals/game 24 hours a week, or four hours six times a week. At least. I expect I will probably exceed this.

Things that I will probably do

I will probably make all of these games in Unity. That's what I'm familiar with, that's what I feel most competent in. It may be interesting to later try to make a game in UE4, but that is not something I am going to do just yet.

I would like each game to be able to be played in VR and RR (regular reality).

Reusing assets, frameworks, tech is allowed. Reusing games is not. 

I'd like to put all these games on my wobsite with Unity webplayers.

I'd like to make all of these games open source (though, they might be missing proprietary plugins).

I would like to make all these games weird.

Phases

I plan to split the time into these buckets:

Game design and concept
Programming!
UI
Asset creation
Juice
Testing and release

Ideas

Here is some stuff that's been floating around in my head. I will likely choose one of these ideas and begin working on it today!

QWIP: control your mouth in great detail. Try to say a word. Uses echobox for sound propagation and calculation.

Bad Things Happen in Plane: Flatland the video game.

Vlambeer game clone mashup! Super Nuclear Ridiculous Crate Fishing Thronerausers.

Intrigue: multiplayer sandbox where every player has a different goal.

Some game that makes fun of the fact that the way that most people interact with most things in video games is through killing.

Some kind of third person action clicker.

Puzzle game?

Thursday, March 13, 2014

[REDACTED], Riftwars, and Bad Things

Tonight, I will discuss the status of the three projects I am currently working on: [REDACTED], Riftwars, and Bad Things Happen in Space.

[OMITTED]

This game is a [REDACTED] simulator with some interesting twists. I'm currently working on getting [BLEEP] to navigate the [NOPE] and do [BLEEPY] AI things, like wander around, avoid nearby [BLANK] and find [REMOVED] and sit down. For navigation, I'm currently using Unity's built in navmesh, but I've run into a few annoying limitations on how much it can be scripted... like you can't specify a certain set of obstacles for a certain agent, and you can't have an agent be something that's not a cylinder (not everything in the world is a cylinder, I know). So, I'm thinking about using Aron's A* project, because it seems to be much more configurable. Don't get me wrong, unity's navmesh is powerful and easy to use, but I'm not sure I can get it to do everything I'll need down the line.

To facilitate designing complex AIs for the [BLEEP], I've been looking into behavior trees. A behavior tree is essentially a hierarchical finite state machine with a fixed set of return states. That's probably over simplifying it. Check out the link if you want a better explanation. I've looked into two packages on the Unity asset store for dealing with behavior trees in Unity: Behave and Behavior Designer. Behave seems to be more sophisticated that BD in the sense that it compiles its own assembly and allows you to do anything you can imagine with that. Behavior Designer is a little bit more limited because you've got to work with their behavior manager, but it's also got a lot more documentation. I ultimately went with Behavior Designer because it was cheaper and it seems like there's more support for it.

Riftwars

We've got a lot of cool stuff going on in Riftwars, which is the current name of the VR Starfox meets Geometry Wars prototype thing I'm working on with James. We're using two tools along with Unity, which I am finding to be really great for collaboration and source control. Basecamp and Plastic SCM. Basecamp is an online collaboration tool where you can list tasks, discussions and deadlines. Plastic is a task based distributed version control system, which can even use github as a backend if you configure it correctly. It's much easier to use than git and has some features that are pretty useful for working with Unity projects.

Gameplay wise, we've got a ship flying through a trench and shooting and reticules and exploding cubes and cockpits and image based lighting and scattering and multiplayer. We're hoping to have a real game that is something with winning and losing and scores by time the next VR meetup rolls around. Here are some screen shots:



Bad Things Happen in Space

Ok! Well, I've got a power system working (badly) and the space ship is made of wood (because it came from the wooden planet). The current story goes something like this: Space is a bad place. Don't go there. Don't go to space. Space was invented to kill humans. Your punishment is space. You're in space because no one would go there on purpose, and you're being punished for doing something bad, down there on the wooden planet (Lumbria? Xulon?) and now you have to go to space.

Mechanically, I'm actually modeling radiative cooling of heatsinks with the Stefan-Boltzmann law and the specific heat of stuff with heatsink surface area and thickness, and density. It's probably waaaay more complicated than it needs to be, but I wanted to see if I could get it to work with physics before I hacked in something more video gamey. Power is generated according to the load which is needed by the ship. The power that is generated has an associated efficiency which splits the actual power into heat and useful energy. The heat goes to the heatsink, which heats it up, and the heatsink then radiates that energy away at some fourth power function of temperature. This isn't very fun, but it's a decent starting place. Here are some screen shots:

The beautiful wooden decor.

Wooden power system. 
Turn out the lights.

Thursday, February 27, 2014

I am bad at writing blog posts regularly.

It is clear that I am unable to ever actually write about anything that I say I will follow up on, and also that I am bad at writing blog posts regularly, and probably in general.

Tonight, I will talk about the stuff I have been working on since the last blog post, and also things that I am doing.

Network Code

Yeah, I ended up going with an authority scheme as hinted in Glenn Fielder's post: http://gafferongames.com/game-physics/networked-physics/ and his presentation on authority schemes here. The authority scheme specifies who acts as the sever for an object as they are interacting with it. This is incredibly not cheat resistant. Anyone will be able to pretend they own an object at any time and teleport around and I hope that my game doesn't become player vs player at any point because then it will be a real problem, or I'll have to switch to a different network architecture.

Interpolation wise, I wrote up my own ~Hermite Spline Interpolation~ class, which takes the player's velocity as tangents for the interpolation, which makes everything look really smooth as it interpolates between network updates. Here's some bad multiplayer robots doing bad things in space:




The Fire

After getting networked wrenches to work, it was time to get the fire system synchronized. I was not particularly satisfied with the way fire was implemented in the game already, a basic 'this tile is on fire' kind of thing. I had a brilliant idea: use physics to simulate fire in a realistic way. That's easy... right?

Diagram courtesy of these guys

Yeah! Super easy. Just implement a fluid solver. So I implemented a fluid solver.
Two weeks later, here are some videos of my fluid thing in action:



It looks like a fluid, especially in that last one. Writing a fluid simulation is hard. I drew this to illustrate:


And also, here are some more images I captured from the fluid development process:

Some kind of debug art.

This velocity field looks rather tasty.

Yep, this is definitely a fluid.

And a mountain of blood sludge.
Is it any good? Well, there's probably some kind of problem with floating point error in the diffusion process. When I try to heat up a volume, it kind of just heats up the center and the diffusion causes the overall temperature/density/whatever to dissipate over time. I'm not sure why this is; it could be floating point error, or that the diffusion is not inherently mass conserving (I need to look into this). And lastly, it probably won't be deterministic over the network, so I can't use it for mechanics anyways. BUT! I can probably use it for visualization of fire, and I also learned how fire works, so I can implement a much more realistic fire mechanic on the CPU. 

Cool GUI bro.

I made a cool GUI for my game. It's broken, so here's some alien text:




It actually works fine in the editor, so I hope unity fixes this bug eventually. Not much of an update here because of secrets? Whatever.

Collaborations

I'm working on two projects with some people right now aside from Bad Things. First off is Seth Alter's No Pineapple Left Behind. It's a charter school management game where one day, an evil wizard turns all the kids into pineapples. If you leave the pineapples alone long enough, they turn into children, which are much worse than pineapples. I'll be helping Seth do all the hard programming things. Development on NPLB should really start to kick off in the next week or so, because CONTRACTS ARE BEING FINALIZED.

I'm also working on some VR stuff with James Andrew. James is a brilliant guy who knows all about all the stuff, and his ambition and enthusiasm are infectious. So far, we are putting together a multiplayer Rift game that we hope to have ready for the next Boston VR meetup. He's got some sick world generation stuff going on, and Image Based Lighting and Starfox meets Geometry Wars.

Last but not least, I leave you with voyeur cube.
Voyeur cube is watching you wield that wrench. No, don't stop.

Tuesday, February 4, 2014

What is The BUTT?

Hi! Long time, no post. Sorry I'm bad. I've been doing a lot of stuff, ok? The game is coming along. You can check out some more up-to-date-ish stuff by following my tweeter. I post things on there sometimes. I know I always promise I'll write follow up posts about things, but TOO BAD. I mean, I still might write a follow up post for the networking stuff. It's really complicated. Butt that's not what I'm here to talk about right now.

The Bad Update Things Thing

The BUTT is now active. The BUTT is your gateway to secret Bad Things Things. Careful, hand-picked data will be transmitted to you at the appropriate intervals. Do you wish to sign up for the Ever Eventual Bad Things Alpha, now known as the Bad Things Happen in Space Network Accelerate Climax? By being one of the first 2,000 home-brothers to activate The BUTT, you will be enrolled in my consideration for the Network Accelerate Climax. 2,000 is optimistic, it's more like two-zero for the upper limit on how much my cloud demon can tolerate before toppling under the great mass of your collective internets. However, these are good problems to have.

How can I interface with The BUTT?

You can activate The BUTT by using your typomatic technotronic key-press-machine to insert your internet email address into The BUTT SUBSCRIPTION INTERFACE located on the right side, above all my stupid social media stuff.

Ok, ok, here's some Bad stuff to sate your unending hunger:

Aliens made my GUI

But at least they provided helpful instructions

Quantifiably superior to super ship 2,999,999

Laserkill is in trouble.

Sunday, January 5, 2014

Status Update: 2016 Edition

Yeah! ~2014~ My new year's resolution is the same as last year's: 1920x1080.

What's Bad in 2015?

Space, duh. Space is a bad place, don't go there. At least not if you can help it. In these last two weeks I have done things! Bad Things! I have spent the last two weeks refactoring the item system and getting basic network synchronization working. And I spent some time fixing Unity's terrible RPC thing. And I registered for nvidia's cool Registered Developer Network, and got access to some stuff (that I can't use yet).

ITEM SYSTEM ENGAGE

The item system now uses inheritance instead of interfaces (because interfaces can't have virtual methods, for some reason (I mean, otherwise it would just be multiple inheritance (what I really want are mixins)). So, now all things that are items inherit from some super Item class, which also has a custom inspector that shows all sorts of cool, context sensitive stuff based on what stuff you selected.

The details (deets)  for a grabable and highlighted Item.

A lookable canister. There's a bug here. Parent should only be drawn for grabable items.

A boring canister with no deets.


In the inspector, I don't want it to draw all of Item's properties, so I call DrawEverythingExcept() and then you pass it a list of all the properties in Item, but not its derived classes. Then you use (chorus of angels) System.Reflection to spit out a list of property names and pass them in to DrawEverythingExcept. And then I do the "draw a serialized thing" for the stuff that I want. .NET reflector has been really useful here to figure out how Unity handles GUI drawing internally.

Bad Things Happen Synchronously

Networking things is hard. So far, I've got people moving around, oxygen working reliably (and also pretty much super efficiently, and in a scalable way), and also you can pick up items and drop them! Most physics based stuff is out. Basically, I only use physics for putting things places, and where it's not that important. And even that is pretty sketchy (I've probably got to set up owner switching, or some smarter prediction stuff). After doing much research, I have come to the conclusion that getting a good multiplayer experience is too much work for one person. Thusly, I will only be implementing some of valve's super informative muliplayer techniques. Namely, I will be forgoing lag compensation, because that one seems like the most difficult to implement. Also, I need to figure out some decent prediction algorithms, but that might come from inspecting the actual Source-source.

update: I have spent a lot of time in the last couple of days extensively researching networking architectures, and I will certainly (yeah...) make a post about my crazy quest involving this. (secret future bonus: this presentation)

Bad Remote Procedure Calls

So the Unity convention for remote procedure calls is to call RPC(String methodName, some, other, stuff). The big problem here is having to use a string for calling a method. If you're using a string, then you're unable to keep track of references and also you can't refactor and it's a nightmare. Thus begins the long journey of figuring out how to pull a string out of a C# method-group. A method-group is not a run-time type. It is something the compiler keeps track of so that it can either turn it into a delegate or a function call. Repeat: a method-group is not a run-time type, to pass it into a function is an error. Except in the case where it is implicitly cast into a delegate from the function call's arguments. Incredibly, this means that I can make passing a method-group work, if I create an overload for RPC that each takes the correct kind of delegate corresponding to the method-group that I'm passing in.

for example:

You can see that I only really need to create a few overloads because my RPCs only really take a few kinds of parameters. It kind of sucks but it's still better than passing strings all the time. And yes, I've tried to use covariance to create a delegate that just accepts object but that isn't allowed for reasons. Do you think my RPC syntax is a reasonable compromise? I can imagine it getting very burdensome if I have to create a lot of new overloads for all the kinds of RPCs I might want to call, but for now, there are only a few serializable types, so the number of overloads can remain small.

So, that's it for 2014.
2014 STATUS: COMPLETE.
Bring on 2015.