Into Beyond goes live on 8bitfunding.com

So, today Into Beyond (v. Aries) got approved and published on 8bitfunding.com. I'm really excited about this, as this will be either the rise or fall of this project. So far the news is being spread pretty slow. But with a preview like that, what can i expect.

I very well realize that the current project doesn't look too promising, or graphically appealing. I could change this, i could beautify it to some degree, but it would be a big amount of work for me, which needs to be redone by a decent artist at some point anyways. I don't have a definite art direction, so every assets i would come up with, regardless of how good they might look, would be for naught if they didn't fit the concept.

For that purpose i will for now keep it pretty much at placeholder graphics, and only make minor tweaks on them in the spare time.
To be honest, it bothers me. A lot. This game is fucking ugly currently, and i'd like it to have a visually pleasing design, but right now it can't be helped.

Instead, i will concentrate on what i can do, and what i know won't go to waste: gameplay. It is, after all, the most important aspect of a game.
So what you can expect in the next version (v. Betelgeuse) is improvements on the ships controls, mission objectives and content, like enemy types, weapons, inventory and a shop system.
The version is due at the December, 31st, same as the 8bit funding deadline.

The continued progression of Into Beyond after that is very heavily dependant on how well the funding turns out, so if you like to see a new shmup, with a classical touch but modern design, head over there, press the big yellow Fund button.

Feedback is very much appreciated and love is given to all of you <3

wzl

Into Beyond

I haven't been updating this blog in a while. Mainly because i was writing journal entries on the Ludum Dare page for progress. So if you're curious what happened the last month, you can head over there and see for yourself, or read this small recap:

The Ludum Dare October Challenge got me quite pumped about my project Into Beyond (formerly titled Space Hunter). I've been busy solving some technical challenges within the engine, and implementing new gameplay features to get a solid proof of concept up and running.

Here are the latest updates:

This is the latest gameplay video i uploaded, showing some basic gameplay. It is already out of date, but my current pc-situation won't allow me to record videos with fraps.

This is a more technical demonstration on how shaders can be edited and recompiled ingame, which is a big help when finetuning them.


So that's mostly what happened last month.
I will now keep updating this blog in favor of the Ludum Dare journal as the challenge is over.

Spacehunter - An introduction

So after cancelling the remake of the ludum dare 21 entry for several reasons, i go back to my previous decision on making a space game for the same reasons i mentioned in that post.

Okay, so what will it be? There's a ton of shmups out there, really good shmups.
For one, a lot of shmups are console games. There's only a handful of well made games for the pc, one of them is the recently released Jamestown. So i think there's still a market there.
Other than the business side, i think it's a good way to gradually progress on a game. Making step by step iterations. It is possible to leave a lot of things out, without having the game feel incomplete (because no one know what the final version will include!)

So what i have in mind is creating this episode wise (Code naming them alpha, beta, gamma...).
Episodes could also be seen as different versions, but i think version numbers wouldn't fit to it, so i am alienating the use of development states for that purpose.
Each episode will radically enhance the gameplay or game features, so it might feel like a whole new or rather bigger and better game with each iteration (although existing features are unlikely to get removed or changed that much).
I have not planned on the actual number of episodes it will include. That is partly due to the concept not being entirely finished at this point, but i think it will be somewhere around 5 to 8. The iterations for each version will be increasing. So for instance i try to get alpha ready for end of october, while beta may be only due by the end of the year. An elaborate feature list of the upcoming episode will be published at some point, so you know what you'll be waiting for.

To be able to work on it on a full-time scale, i need to introduce a prepurchase option, and get all of you chaps to get a copy! Why should you buy an unfished game, that might not even get finished, you ask?
Your concern is valid. Therefore the prepurchase will start at 1€, and will increase by another 1€ with each episode. You won't have to rebuy, once you invested though, you'll get updated just like that! That means, you can buy a cheap (shitty) game now, funding its development, or buy a good game later, but paying a price for it.
Additionally, if you have too much money on your hands, or are a very kind person, you can pay any price you want to further increase the chance that this projects will flourish sooner.
I will set up paypal somewhat later this month so it can begin with the release of alpha!




Stop blabbering about this boring stuff! What is it about?!

Ok, so what you see in the above video is an early prototype of alpha gameplay. In fact this is 3 days into production. So you control your ship in a side scrolling manner, but stages are not just left to right, but you can rather move freely in them. This makes it different from most shmups already, since it results in a nonlinear level design. This will change gameplay from Start Level -> Fight enemies -> Fight Boss -> Next Level to a more purposeful line of actions. Something along the line of Destroy Forcefield generator in the south, and the Flood Gates on the far east, which will drive the enemy off his Underground Base, so you can take him down. This is just a small example what might be possible. There will be different kinds of mission, to not get bored with the same thing repeating over and over again.

Additionally to this play style you will be able browse through the solar system to travel to different locations, or land on stations to resupply or receive contracts. I will be more elaborate on that some time later as this will likely be Beta content.

Also, this is currently inspired to be made for the Ludumdare October Challange, so check out the other games that are getting prepared :D


Regarding the title: Spacehunter sounds kind of not very cool. If you have a suggestion for a better title, you can leave a comment, or say hi, or give me all your money and your first born child.

Adventures with Triangulation

Oooh, blogger has a new interfa.... err getting distracted again.

So, as i mentioned i am currently working on The Collapse, or rather, i am kind of redesigning it. I was brainstorming with Lateman this weekend and he had a nice idea for a graphical design concept. But more on that in another post.

To be able to achieve what we had in mind i had to redesign the leveleditor from scratch. No more boxes, cubes, and spheres.
One technical hurdle was getting convex triangulation with holes to work. I was scrolling through a couple of papers earlier today, and i got a good glimpse of... well i wont be shitting you, i didn't get most of it. I currently don't care much about how it is solved technically, considering that it is quite a complex topic, so i further ventured through the internet looking for resources. Eventually i found this.

I am using the C# version by Erwin Perik, ironically the High performance version by Salvatore Previti, well the sample anyways, was pretty slow. We're talking about ~1 second for around 150vertices slow. Kind of curious since they both are derived from the same base code.

So what am i gonna do with it? I am feeding it a series of vectors in order to receive a generated surface i can texture.

Simply simple

So far so good. The problem is though, i dont have randomly scattered vertices like shown above.
What i am looking for is, after all, a concave polygon with holes. So when feeding it with proper data, it was more looking like this:

Oh, why you be so convex :(

Just then i was remembering a rule to determine if a point is within an arbitrary shape or not, which is: draw a line from a point you chose to a point anywhere within the shape, and make an intersectiontest with every bordering line segment. Is the amount of intersections even, the point is inside the shape. Is it odd, it lies outside.
So what i can do now is simply define an anchor point within the shape, calculate the center of each triangle, and do intersection tests with the border segments, check the amount of intersections and voila:

Concave, with holes, not all that complex after all

So i guess this is kind of cheating, but it works, and quite fast too. I worried that it might take a week to get it working correctly, but thanks to the internets it just took a couple of hours \o/


If you have questions, let me know below

The Collapse - A Ludum Dare Entry

I was participating at the Ludum Dare Game Compo this weekend.
I started on a basic prototype idea on Saturday afternoon, pondering about a concept. After a few lines of code i had a random generated maze out of differently sized cubes, and some enemy entities with a basic homing ai.

Very unspectacular

I kinda liked the physics based movent around the obstacles, but getting decently playable levels out of random generation is quite the effort, and i wasn't sure of success. So my decision was to develop an editor that is capable of designing custom levels.
While i was at it, ideas kept flowing in: different types of geometry properties like bouncyness or stickyness, moving platforms, and some more i didn't want to consider at that point. It is only an 48 hours compo after all.

So i started on the basics, having the ability to move and scale cubes to form a level, and advanced on editing features like rescaling or translating specific objects to not start over on a misplaced object.
Most of the work went into the editor, as the gameplay features were pretty simple and quick to implement.

In the end i am fairly satisfied with the result. I was able to implement all the features i planned for it, got a catchy tune, some ok'ish sound effects, and the graphic effects (apart some minor issues).

However there seem to be a few bugs in the engine, as i received some messages that it won't work, or crash on startup. I need to look into that.

Anyways, heres the gameplay video of the submitted version

While developing this i came to like the concept pretty much and i have a couple of ideas that can be implemented to have a more versatile gameplay; depending on the feedback i will consider making a full game out of it.

So yeah, thats all for now. If you  have questions, or if something doesn't work, please let me know in the comments or on twittor.

Download:
You can download the Ludum Dare release here.

I made a small fix that might cause a crash on startup depending on your systems localization. Also improving the Physics/game update, resulting in a better gameplay performance, and fixing the issue about not loading levels for some, also showing the goal model. I strongly suggest you download it instead the official ludum dare release!
Download the fixed version from Dropbox.

You need the .net 4.0 framework or better to run this.

Getting more interesting

As all so often there's a lot of things on my todo and i can't manage to focus on getting one thing done before starting the next, thus i am jumping around a lot of different construction sites.

So what i'm going to show you today is something i worked on a few weeks ago.
Behold inverse kinematics walking animation:



There are still a bunch of issues, like the elbows being all over the place, and the legs crossing at some points when turning around, but it works fairly stable

This prototype is pretty simple in itself as it only works on a flat surface yet. Eventually the model should be able to climb stairs and slopes similar to how a person would to it.

So why am i doing this?
Obviously because it's pretty darn cool. The other point is having realistic animations which are adjusting to the environment, without the need to have the animator design a bunch of animations for specific cases.
Another reason is the immersive aspect (as much as this word is misused nowadays, i think it fits at this point): Nothing tips me more off in game as terrible animations, starting at simple things like syncronising the movespeed with the walking animation cycle, or a simple waving the hand to interact with objects, instead of grabbing the doorknob to open the door for instance. It just looks like a poor puppetplay.

I realize that in the past it was not easily possible to implement it any differently due to performance restrictions and some other barriers. But we arrived at a time where graphics will only improve slightly, so to increase the realism(for lack of a better word) in games we need to focus on things other than the polygon count. Many studios realized that already and came up with a bunch of nifty features, such as Assassins Creed's climbing and user interaction animations, or LA Noire's captured facial and body animation.

This is currently a work in progress proof of concept. This attempt holds a lot of mathematical barriers to me, implementing restrictions for joints, finding the correct pathes to move for the limbs, reacting to outside forces and a bunch of more stuff. So i take this as an iterative process. I will improve it step by step to get a good approximation of what i have in mind eventually.

Changelog 003

I mostly finished the work necessary for porting to OpenGL >3.
The model class got rewritten to use VBO's instead of immediate mode, and the imported collada vertices were changed to fit into the VBO's vertex structure. In retrospect, it was a straight forward process, even though there were some minor hiccups. There is still much to do, converting the actual existing code that is still using deprecated functions, but the worst part is done.

After mog mentioned he wants to code a 2d rotating ribbon effect, i thought about how i would realise it and today i was playing around with the shader realtime editor and built that oldschool 2d ribbon/twister effect, which is common in older demos.

I ended up playing around with the same code in the shadertoy and it ended up in a textured more dynamically moving twister thing (paste to the default Deform shader code and hit the compile button (or Alt-Enter)). You might need to manually enable WebGL in your FireFox about:config or use Chrome.

Changelog 002

This week i started out improving the shader editor, so it becomes actually useful. It still lacks some kind of selection of what shader currently is being edited, but i added some visual enhancements like fading the top and bottom code lines, adding a line counter, and error handling and parsing the errorlog to highlight the lines which makes the compilation fail.

Failed compilation with highlight on the errornous code line

Further i added tangent calculation from the texture coordinates for normal mapping and texture mapping on the sphere primitive.

Is this normal?!

Once upon a time in a galaxy far far away

In case you're wondering, theres a julia fractal being animated in the corners.

The rest of the week i was trying to port the engine to the OpenGL 3.3 core specs which includes uploading the modelview and projection matrices, and the actual vertex data to the shader, and stop using immediate mode ( i will miss it! ) for the sake of using Vertex Buffer Objects.

So hopefully i will be done porting most of the code by next week so i can focus on the fun stuff again.

Changelog 001

This was a quite successful week. I've learned a lot of things and started implementing them aswell.

The first thing i worked on was finally getting the per pixel lighting shader to work, which i did after numerous talks with several developers both on gamedev.net and irc. Eventually, all that was left to do was transforming the lights position by the camera matrix, so everything is in the same view space, and can be lit accordingly.

Failed lighting

Successful lighting

Currently it is only using diffuse lighting. Adding ambient and specular would be easy but it is not necessary right now, as for now i just like to tinker around with shaders and to get a better understanding of how to work with them.

Another thing i wanted to get done for month is model loading, and thus i started coding a collada importer. For now it is crudely hacked together, and it only supports triangulated models and no quads or other polygons. It took a couple of hours but eventually i got it working pretty good.

Quick and dirty model made in blender

I added another shader for texturing which includes the lightingcode from before and ..wow.. shaders really are awesome to work with!

Lastly, i want to give some credits to iq of rgba for writing this awesome shader live editor.
Something like this would really increase the workflow, and instead of alt-tabbing and recompiling all the time you just hit a button and see the results. So this encouraged me to remake this idea and write my own shader live editor. It took just a few hours, but for now it is more of a proof of concept. The editing capabilities are crude, but at least it is working!

I will keep working on it to make it a useful and fun tool eventually.

Jitter physics

I thought it finally is time to implement some physics into my game engine.

Physics usually require a tedious amount of work and you probably need a degree in computer science and math to implement them nice and smoothly. Because i have neither, i was looking for the alternatives.
There are a handful of libraries available for C# which seem to work quite well.
JigLibX and BulletX are both implemented for Microsoft XNA, so it would require some rewriting, which wouldn't be so bad since they are both opensource.
There is however Jitter Physics which works tremendously well for me. Implementing it and getting it to work was an hours effort. It comes with samples for XNA, XBox360 and Windows Phone. The XNA sample is just that though. Jitter Physics is in no way tied to XNA like the other libraries mentioned. So it could be seamlessly implemented in my engine. It comes with the zlib license which means you can do virtually anything with it. But you should be nice and mention that you're using it. That's the least you could do!

One thing i will have to adjust would be changing the vector and matrix classes to use my own, because they currently need conversion every time. I'm curious how much of a performance gain that will bring.

Hell, thats an ugly box!

Oh yeah, since i haven't mentioned anything about the engine yet; it is in development for around 9 month in my spare time. It is realized in C# using OpenGL rendering through OpenTK.
Currently i am still working on a lot of base features rather than gameplay, even though i have some prototypes i will show off some other time.