Sunday, November 16, 2014

Void Skimmer update

Just another update on the progress of my tiny game that I'm working on.


It's coming along pretty nicely. One thing I would like to do is have a repeating background instead of just clamping the edges. If you were on the bottom of the play area shooting down, and somebody was on the top of the play area, the person on top would get obliterated hands down, because they wouldn't see the enemy or the shots coming. I think this is what I will work on adding next.

I may need to switch how I am doing the drawing though. Right now I am drawing everything twice. I am drawing the ship, the background, and all the active game objects to a reserve render target. This gives me resolution independence and the ability to do some post effects on the game screen. Sepia when paused, shake the screen when a player dies, scale the camera to encompass two players, etc.

But the problem is when things go outside the play area. The default behavior is to clamp, but I need it to repeat. 

The next thing I would like to work on is adding black hole gravity wells for your ship to encounter.

Saturday, November 15, 2014

Void Skimmer Video 1



A small demo of just some simple movement mechanics that I've been working on, and getting familiar with Monogame.

It's a great library, and I'll definitely write some more about it when I have more to say about it :p

Playing around with monogame



Been playing around with monogame a little bit. Have to say, pretty impressed with how easy it is to get something on the screen.

Coincidentally, been having a lot of fun playing luftrausers on PS3 this weekend too.

Wednesday, November 12, 2014

Tuesday, November 11, 2014

Catching up

Wow, it's been a while since I have posted anything cool to my blog. Right around a year actually. I think it's time to fix that. I have been doing some neat stuff like building my own software renderer and building some quake levels. Those videos are on youtube, so I will have to cross post them here.

Another cool project that I have dabbled with is creating a play-station as a service setup. Using a TV tuner card, NGinx, and a few other pieces of software, I can effectively play playstation from any device in the house (as long as I bring my controller with).

I think between that and cataloguing what I have been learning about Linux and web programming lately, there will be some pretty neat stuff coming in the year 2015.


So, the most recent thing I've done is convert my PC from running windows 7/8 to running Ubuntu full time. What a transition! I'm not sure I will stick with it, but Gnome throwback is making it a lot easier, and so is having almost half my steam library available.

Being able to play TF2 and Civ V makes me a very happy panda. In the future I may add a 3rd hdd for dual booting, but for right now, things are great.


Wednesday, December 4, 2013

game markup language experiment - Part 1

Going off my last post, where I described a theoretical game markup language, mixed with JavaScript and a type of CSS, I've decided to go ahead and perform a theoretical experiment.

You can follow my progress here: https://github.com/longjoel/gml-experiment

For a project base, I am using C# and .NET to primarily develop this in. Because this is going to involve a lot of dynamic language processing, and XML processing, it just makes sense to use this instead of C or C++.

Processing the DOM: 

* This is easy enough to do, because C# handily supports XML Serialization and deserialization.

Handling the Javascript: 

I am trying to decide between several projects at the moment for the JS implementation. 

* IronJS - based on ecma script 3, looks stable but no longer maintained.

* V8.NET - actively maintained, based on google's V8 javascript engine, should be robust and fast.

* Clearscript - looks ridiculously easy to get started with, can use chakra or v8 JS engines, actively developed


Handling the CSS:

CSS parsing will be a custom solution.

Display layer:

There are quite a few options available. There is DirectX with SlimDX. There is OpenGL via OpenTK. SDL 2.0 bindings exist as well, and that's all before we begin to look at MonoGame, XNA, or using Webkit. A decision on this does not have to be made right away. For now we can just use GDI + and a debug console.

Physics API:

Physics is another piece which will come further down the pipe. But will probably just use farseer for the time being. 



So the first step will be to gather all the necessary dependencies together in a folder of DLLs.

Part 2 will be designing the kernel.

Monday, December 2, 2013

Crazy thought of the day.

So I've been playing with a lot of JavaScript lately. Perhaps even too much. But sometimes, thinking too hard can lead to some interesting ideas.

JavaScript is designed primarily to manipulate the DOM of an HTML web page. JavaScript + HTML + CSS is a great combination.

* HTML describes the layout of the document.

* CSS defines the attributes of the elements in the HTML document

* JavaScript can be used to manipulate both the document layout and the elements themselves.


So why can't we treat games the same way that we treat HTML documents?

What if instead of describing elements of a web page, we were instead describing the play-field of a game?

HTML -> gamedoc:

<gamedoc>
<head>
<script source='level1.js'></script>
<script source='enemies.js'></script>
</head>
<level>
<entity class='spawn'  x = '0.0' y = '1.1'/>
<entity class='enemy' />
<brush>
____ <bpoint x = '0' y = '1'/>
____ <bpoint x = '0' y = '1'/>
____ <bpoint x = '0' y = '1'/>
</brush>
</level>
</gamedoc>

CSS -> GSS:

brush{
____ texture:url(img/background.png);
____ visability:visible;
}

JavaScript:

$(gamedoc).onready( function () {

____ $('entity').think( function(t){
____ ____ $(this).x = $(this).x + $(this).vx * t;
____ });

});

So, I'm not super clever, but I think that if I were working on a game engine, I would rather have something declarative like this to work on, instead of something like Unity3d. But maybe i'm just weird like that.