Updated tech demo and made SlideDB profile

I've finally uploaded an up to date version of the Kuba engine and released a newer video of gameplay.

Link on google play:
Kuba FPS test on GooglePlay

(The above video is used as an advertisement on the google play page).

And I've also just started making a profile on SlideDB so that I can create development journals for my games... I'm hoping to bring some attention to my projects and also motivate myself to get more work done.

My SlideDB page can be found here:
Kalisme on SlideDB

I've also added the game I'm making with my Kuba engine, which I've decided to call "Blam blam Damnation"... but it's awaiting aproval... So hopefully it'll be aproved soon and maybe it will generate some interest.

Slowly chipping away

I haven't posted anything for a while, too much uni, looking for work and other stuff...
But I've been coding here and there... Lots of little touch ups to the Kuba engine...
Many times I've felt like just rewriting the whole thing would be quicker then
just dealing with my horribly written old code (As I've said, Kuba started out
as myself trying to learn Java and how to code a game for the Android OS).

But anywho, I didn't rewrite the whole thing and I've just tried to rewrite
sections of code... I really do think it has made things slower, but I also
think it has taught me some interesting things about coding for Android
that I mightn't of learnt if I just scrapped and rewrote.

One of the biggest hassles I've faced (And I think I've finally sorted),
is trying to keep it looking okay but playable on low spec devices....
I've been testing it on my LG-p500, my Amicroe Touchtab II and my
partners LG optimus L5... Kuba definitely runs fine on my tabler and
my partners phone, but keeping it running at a playable rate on my
LG-p500 has been a bit of a hassle... Currently it is "playable", but
not smooth... It runs fine if you disable dynamic lighting, though a
little jittery at times with the lighting.

Here's a tip for anyone using openGL 1.x for android...
openg GL lighting is sssslllllloooooo-ow!
As soon as I finish this game, I'm gonna go learn ES 2.0.

But anywho, before I made my recent updates, I was feeling that maybe
getting my engine running on anything like a LG-p500 was unrealistic...

The problem with how I wrote Kuba is that it's overly simple...
it builds a map from a 2d array, it stores a mesh, it has a view
range, collision detection, touch input, sounds and state machines...
Not much else... Not very good culling, so a lot of unneeded things
were drawn.... A lot of GL state changes can happen...

For quite a while I had the 50x50 map divided into smaller 10x10
chunks because I though it might speed up rendering and make
the lighting faster... I was wrong... I recently switched to using
one mesh for the map and there are less state changes for the
lighting now... So there is still a slow down for the lighting,
but less of a slow down.

I've also fixed the FOV and LOS code... before every frame
is drawn, a 2d array the size of the map containing booleans has a
quick visibility check drawn onto it.... It switches all tiles that are
visible from the cameras location to true. I've ended up using the
same algorithm that I used to calculate the vertex lightmaps and
it seems to run fast enough to function each frame and really sped
up the engine on my LG-p500... So that's pretty cool.

So the overall check for each 3d model is that it checks if it
fits within some simple dot product checks, then if it does,
it quickly checks if the tile it is on is visible.

The problem with this is unfortunately sometimes an object
is clipped when it is meant to be poking around a corner...
But when I think about the speed increase, I think it's a worthwhile
sacrifice... But who knows... maybe people will be turned off
by this.

Hopefully things will settle down soon and I'll have enough time
to finish the assets needed for the first version of the actual game...

I might post my lighting/visibility code some time soon...
it's pretty simple... not brilliant, but it is faster and more accurate
then some of the other algorithms I've seen for it.
It might be useful if anyone is wanting to create a roguelike...
Which is something I want to do with the Kuba engine after this
upcoming game and before I write a new engine... Wrote myself
a quick dungeon generator which works fine... fits right into the
Kuba engine too... So that could be fun.

Well, I'm off to do some more homework... *sigh*

Working with touch screen FPS controls

Hopefully this'll be a very short post since this is just an update on the Kuba engine. I have recieved some very helpful feedback about the controls so I have been trying to rewrite them.

I found the problem came from the "turn and look" controls on the right side of the screen. Originally I was using the same sort of control settings as I did for the left "move and strafe" invisable virtual joystick, but it really just made moving around very confusing...

In short I ended up going with the swipe based control that a lot of other android FPS games use, but before that I was trying a weird mix between swipe controls and a virtual joystick... sort of a dynamically located joystick the sets its new location when you change directions... (eg: if you start turning left by dragging your thumb left, when the thumb first touches it grabs the X location and measures the distance from that point to figure out how fast you will turn, but if you swivel right, it sets the new X location to measure from at the point where you switched directions on screen)... It was better then the original code... but felt very weird.

Well, I'll be posting a new update later on today with the controls I've just written.

Thanks to everyone that tested it for me so far, and thanks to anyone who tests it in the future.

Kuba engine demo released on google play

 

After a lot of breaks, returning to code, breaks from coding, returning to coding and learning about how to get things done (sometimes successfully) on an android device I have finally released a demo of my Kuba Engine onto google play. (Kuba engine = [K]alisme's c[u]be [b]ased [A]ndroid engine.)

Kuba FPS test can be found here: Kuba FPS test on Google play

The demo it self is a never ending First Person Shooter, meaning there is no way of "winning", you just keep getting a higher score and the monsters keep respawning.

There is unlimited ammo and only one life before your score is reset. In the demo you can't save your score, it's really just to test text overlays.

My next project is going to be building this into a full game. Most of the textures and models in this demo will be used in the final game, but with more monsters, more weapons, ammo, items,  scoreboard and just a lot more fun and gameplay than what is seen in this test.

Currently I brushing up on my C++ so I can rewrite my map editor for the Kuba Engine because it turns out I've forgotten some important stuff about C++ while teaching myself JAVA... Turns out it's not like riding a bike... who'da thunk-it?

The new map editor will have both a 3d and 3d layout on screen (old version only had 3d), more control over entities and map objects, loading as well as saving (the last one could only save) and a bit of angelscript in there so that I can easily modify the editor for new games with newer versions of Kuba. The end result will hopefully be more interesting levels in my game.

The engine itself is quite simple (and probably needs a bit of a rewrite)... All collisions are (currently) handled by simple AABB checks, most behavior is coded with state machines and interface based functions. The biggest slow down in the engine is the real time lighting... turns out multiple opengl lights are just slow on Android... It still runs smoothly on a lot of phones, but will become a bit choppy on lower end phones... which is a shame because I was aiming this at lower end phones.

After I make one or two full games with the engine, I'm probably going to rewrite it and make a KubA 2 or 1.0+ which will still use cube based maps, but will slopes which will allow terrains and more interesting level design. This will mean that I will have to switch over to a more standard line to polygon intersection approach, but hopefully it won't cause too much of a slowdown. Currently the engine is using OpenGL ES 1.1... so I should probably learn more about GLSL and switch to OpenGL ES 2.0 because I've heard this might actually help the engine run faster... and make allow it to look a bit nicer (in theory).

Quick update on stuff

Volumetric stencil shadows in C++ (openGL + SDL)

Finally returning to android coding after a large break from it...

I moved house and didn't have the internet for a while so I ended up doing some C++ coding... Nothing amazing, but I did learn real time volumetric shadows through opengl (which I can't currently use in Android... But maybe I can when I FINALLY shift over to OpenGL ES 2.0).



I also finally have a elipsoid -> polygon & elipsoid -> elipsoid collision library up and coded (In C++... but will convert to Android after my current project).

If anyone else is finding a pain to get their head around 3d collisions, you can get the paper I learned from here:  collision.pdf . It's very useful... though you'll have to add to it and rewrite some of it if you want it to be used for something specific (like a game engine). My advice is to add an "isStuck" variable and to save a safe location to jump back to if the elipsoid is ever "stuck". I also think there is a point where the tutorial might set the distance from intersection point to Zero... Which can cause a division by zero... But it's not a big thing... In the CollideWithWorld function, there is a point where is checks if the "collision Package"'s "nearest Distance" is equal or lower then "very Close Distance", I just changed the ">=" to ">" from what I remember.

I recently got a message from someone asking if I could give them the code I used for exporting 3d models from Blender to a custom format (Written in Python) and loading them into an Android game (written in Java) to which I WAS going to write a tutorial about both sides, but I couldn't respond to the persons message because of there privacy settings... But I still might write the tutorial at a later date... Currently my exporter and loader use ASCII which I think may be causing some slow downs when importing them into my Android engine... So I'm currently on a mission to understand binary exporting and loading... I've heard this is faster so I hope this information is correct.

When I have the binary exporter/loading code written I'm going to write a tutorial on both ASCII and binary custom 3d models which will include all the source code and explanations.

Started Android games development

Late last year I purchased an Android phone (just an Optimus p500),
I purchased the phone because my last phone (a cheap thing I've had
for quite a few years); died... I figured if I got an Android phone I
could teach myself how to code for it.

Not coming from a Java background made it a bit confusing at first...
Not really the Java part... but I eventually got it... Multithreading was
a bit confusing for me... but I eventually got that too...

I started with a simple "touch the smiley faces to make them pop"-app,
but then moved onto OpenGL ES 1.1... Being the impatient kinda guy
that I am... I decided to port my flash gFPS engine to android.

Unfortunately OpenGL ES doesn't like dynamic creation of meshes...
And the entire map was drawn from the ground up for every render in
the flash engine... I originally wanted real-time editing in game (for
rocket blasts and such), but this just wasn't working... So I ended up
dividing the 50x50 maps into 10x10 models to display when on screen.

Over time I added 3d model imports for static and animated meshes
(the animation is just vertex based), dynamic lighting (very simple tile
based lighting) and some other stuff....

If you go to my youTube page you can look through my development
videos... My youTube page

I've been finding it hard to find time to finish this project, but I'm hoping
to write in a Finite State Machine and handle all non-engine code through
it... if it's succesful, I'm hoping it will speed up the development and
if it works well, I'll probably write a short horror adventure using a slightly
modified version of the engine after this project using more complicated
FSM connections.

I'll probably post an *.APK file link for testing reasons soon (my internet
connection is being slow right now).

I'm hoping to be a bit more active from now on, so expect more updates...
Maybe people might actually start reading this so that I'm not just writing
to myself.... YAY! :D

New project: Short tales of a tall man

This is a screenshot of a graphics test I just did... I'm considering using a heavily modified version of my GFPS engine for this new game; "Shorts tales of a tall man"... well... that's not the title of the new project, but I am hoping to make a series of games based around the "slender man mythos" (quite interesting stuff, look it up)... This screenshot was just of me raising the resolutions for entity displays and wall testures... it seems to still run fine. The game itself WILL NOT be a first-person-shooter... It will remain first person, but be more like a first person adventure mixed with a visual novel... No guns will be in the game.

The graphics here are also no representation of the game in its final state.... I'm going to be trying to add 3d model loading to the 3d engine so rooms will be decorated with furnature, outside there will be trees and so on... The basis of the engine will be still tile based, but with some additions to make it seem less "boxes and sprites"... Mouse looking will probably be switchable so the mouse can also be used to interact with the world.

This was just a quick concept sketch of "the slender man" I did... I'm still not sure what look I'm going for yet though... My girlfriend is going to also be contributing to the project in a design and probably story context, so hopefully this will make it more interesting that what I'd probably do by myself...

I've just decided on starting the project today, so it will be quite a while to any of the games are finished... engine rewrites will probably take a while... but there should be updates soon.