Fixed the bug that prevented new players from playing :s (and upgraded graphics again). I hope people can give it a second try.

OK so
-fixed the firefox image upload issue, so draw should work on both now.
-everything is https by default.
-Tutorial overlay is flashing instead of "OK" dialogs, a lot of people got annoyed by them so hopefully its less intrusive now.
-There is a growing list of bugs for "draw", but not everything is fixed yet.

Tom

Your feedback is awesome. Its appreciated a ton.

"Yeah, I miss a corrector or something. I can't select the white color, to erease my lines, even if my life depended on it."
Undo has suddenly stopped working properly. If you hammer under several times it kicks in (?!)

 * "Interact with the universe in missions" - IT WONT GO AWAY ! (I kinda find it funny by now)
That's the meta tutorial trying to get you to play the tutorial? Or you played the tutorial (and won) and it came back again? The overlay tutorial was kinda hard so that could be a bug.

You should be able to use https. Yeah I should migrate everything automatically. It cost $9 a month! (but a necessity for Facebook listing)

All the other stuff we will get onto pronto

-User's art is put into missions so the missions are pretty
-Some really good mission campaigns have been developed (A New King).
-A tutorial starts *as soon as you login*
-Sound
-Cards are split into factions, you can only have a few off deck faction cards
-lots of new cards
-existing player base has drawn a fair number of cards now.

My anecdote:
After one batch of new user testing, 78 out of 78 users tried to play the site without logging in or signing up, and left frustrated when none of the buttons worked. People were ignoring the sign in button and heading straight to battle. Doh!

Hopefully people won't get lost on the first interaction now, lol! www.runesketch.com live and learn

pic by one of players:-


Tom

I just found a bug in Goblin Warrior that halted the missions. Could that have been it?

Indeed. The developer I am working with also made this user submitted pixel art site: http://piq.codeus.net/ And can attest that 20% of all images is penis's. However, he just vets all images. So we are also having verification step. Not in the current alpha version but the plumbing is there for moderation. The important thing I think is to make sure people who submit inappropriate images get a warning and some kind of penalty, so you nip bad behaviour in the bud early. That gets your penis count down from probably 50% to 5%. Haha.
It really doesn't take very long to verify images with the right interface. We are gonna ban text of any kind

Yeah, I have had that a few times. The request gets corrupt sometimes and the client gets in a weird state. A refresh of the browser should get you free. I noticed today if you lose it doesn;t really tell you that either so double check you havn;t jsut lost too.

The middle column has special status. Cards can only move forward if their is a card horizontally adjacent (or its the centre column). This was to fix and issue in earlier versions where cards jsut wandered about unconstrained. But this feature has tripped people up alot, I think we should alter the background image to try and reflect all spaces are not equal.


What changed? We are finding uploading difficult due to browser compatability issue over scraping a HTML5 canvas for an image. We put in a 3rd party canvas -> blob converter yesterday.

Totally agree. However, we want to avoid users uploading copyrighted material. So we made that annoying restriction deliberately.

Yeah the game features are evolving faster than the documentation. Classic :p

a.k.a. rally. Increases the attack of a card. Doesn't stack (used to stack until we found it overpowered). Still pretty powerful.

Try multiplayer though. Its really fun. I am gonna give everyone 5,000 because the other major complaint is its hard to get money.

 

Like me! Haha.

You can buy art off other players in their shops. Or just send cards into battle blank.

The art does not actually affect gameplay. We are thinking that cards with good art are rewarded with better stats, but even then, you can still buy good art off other players to get that bonus.

The point of the art is to look bling, but also to make money which will buy you better cards (so there are multiple routes to wealth which leads to power)

Been a while since I been on these forums (since orphaning JOODE). I am now a Dr. of robotics! Now I am a post doc earning wages, I realise I desperately need to find a way out of academia :p Hence my first serious game attempt after 10 years of tinkering 


Its a CCG but each card has a kind of grammar to describe the rules they follow in battle. It makes the expression of interesting cards easier than a list of stats to describe a card. The aim of a battle is to kill the other players commander (standard). That's the core game concept, but we wanted to go further than just interesting game mechanics.

Your cards are bought as blank cards and you draw your own art on them. You can then sell your art to other players (if its good). So we want creative players to get rich, as well as the good card strategists  We want a game that people can play for different reason. Not sure if we have quite nailed it yet, but that's what feedback is for!

Built on Google App Engine. Turn latency is 300ms, which is pretty good for a http only communication method I think. After serious optimization we hardly scratch our free quota. So its definately sometihng to think about if you want to make an MMO on the cheap. Front end is HTML5/JS (angular TBP). JS is not so bad once you get into it!
 
Anyway, I would really welcome some feedback, you don't need to install anything, its in the browser. Firefox and Chrome should work. I think safari and iphone doesn't, but I have managed to play it on my nexus too (albiet the screen size is not great, work to do on that)
 
Buy my card art! (or just login)
 
http://www.runesketch.com/static/main.html#/art/467001

(I assume its still considered Java game technology even if the front end is written in something else)

if A goes to B. Draw straight line between A and B. If that line intersects an object, split the line at C and move C until A-C and C-B miss original object (move C normal to line A-B). Recurse on A-C route and C-B route. I think this might only work for concave objects.

If its low numbers of portals you can do hacks like Riven said.

E.g. calculate shortest path via each possible portal and take smallest of the options (although if using several portals in an individual path, the combinations grow FAST).

You can hack this a little further by pre-computing the distance of each location to the nearest portal . The when computing a distance, you can calculate the shortest path, and then ignore portal usage if this distance is smaller than the nearest portal at either end of the path.

To really nail this problem, you pre-process, e.g. run something like Brandes inbetween centrality algorithm. But presumably you want to stick to whatever you have coded currently.

@princec

A* state space evaluation can be quite subtle. Its best to try and mentally compare Greedy search (ignore the distance you have traveled so far) to A*.

Consider moving from A at the top of a map, to B at the bottom in these two case.
1. with a round obstacle in the middle
2. with a bucket (concave) shaped object (with the opening aiming a A) in the middle

With greedy search,
1. the states expanded go straight toward B, hit the obstacle and slide over the round surface until in LOS of B.
2. the states expanded go straight toward B, enter the opening of the bucket, hit the bottom of the bucket, and then fill the bucket, until pouring out over the side into LOS of B.

With A*
1. the states expanded go straight toward B, and hit the obstacle. So we now have a line of explored states from A to the obstacle. Then, every state adjacent to that line is expanded as the heuristic is compromised. So the line fattens at the rate of the surface area of the explored state until the end part of it is in LOS of B. It becomes a bit like a breadth first search at that point (Argh! the complexity!).
2. Like 1. but much worse

So greedy search is always my default position over A*. Heuristic compromises can be quite subtle. So if you are on a grid world with diagonal moves and you use the Euclidean distance, bam! you got problems because the path exploration can't follow such a direct route as the heuristic expects.

Yeah direct LOS paths are best, that's equivalent to greedy search in a discretized world. It doesn't have problems with using euclidean distance on grid worlds either.

I dunno if people do this in games, but we use it in robotics.

A* is rubbish because it enumerates way too many states. We use sampling base planners that return sub-optimal solutions but majorly faster by skipping alot of states. Instead of exploring a complete square, you explore just the frame of the square.

A one shot planner of this style is rapidly exploring random trees.

However, in a map with alot of static objects its better to precompute stuff, like the track you are on. So the multi shot version of that planner is probabilistic road-map planning (PRM).
1. Randomly generate waypoints
2. Joint each way-point to its X number of spatially nearest neighbors using some other search (e.g. A*) (maybe try searching for 6 paths, but terminate when you find 4). Now you have generated a course roadmap of the state space.

Now when you get a query for a point to point position, you plan to the (spatially) nearest way-point on the roadmap (or try a few and go with the first one that returns a result) to the start and goal. This find a path onto and off the roadmap. Now you just do a graph search on the low complexity roadmap between the two waypoints you just planned to (e.g. Dijkstra). Concatenate the three paths together (1. start to roadmap vertex A path, 2. vertex A to vertex B roadmap path, 3. the inverted end to vertex B path) Now you have a sub optimal path between start and goal, where 95% has come out the roadmap. HOWEVER, you will find the roadmap path a little jerky when it changes between waypoints (they *were* randomly generated), so its normal to smooth the final path (http://theory.stanford.edu/~amitp/GameProgramming/MapRepresentations.html) which is relatively easy to do albiet a slightly tedious exercise.

If the map is a little dynamic, leave the PRM roadmap as it is, but double check its validity when a specific path is found. You can then just discount whatever edges are problematic temporarily and use the other edges of the map (called lazy PRM). Superfast and can deal with really complicated non-euclidean state spaces.

PS got my doctarate in robotics path planning two weeks ago :p back to games programming now! Here is an example of a hard planning problem : https://sites.google.com/site/tomlarkworthy/

Thanks for the feedback guys. I do believe there is a path toward helping with those other tasks. The reason why I want an early product to be optical scanning is because you can build upon the algorithm to get to visual mapping for navigation, with the bonus that you can use the same tech to do giant 3D scanners for rooms and buildings. 

An advantage of a modular scanner is that you can upgrade the kit with lasers, directional light recorders and flash guns fairly gracefully. I believe that by flashing colored lights at an object in different directions, you can recover an aesthetically convincing depth map and specular reflection information relatively easily.

Yeah the kinect is an awesome sensor, we have 2! (no xbox though  ) It took about 2 seconds for the robot community to integrate the kinect with everything. 1D laser range finder are ~£100, 2D ~£1000, 3D ~£10000, so the kinect is a total no brainer.

@CommanderKeith that video is awesome.

Hello JGO guys,

For the noobs, I am Tom of JOODE unfame. Before I get to my point, I'll give my quick background since I was active. JOODE (the java physics engine) was a tool for me to do robotics research in modular robotics, started as an undergrad some 6 years ago. Since my last commits, I did a PhD in robotics, in particular, motion planning for self-reconfiguring robots i.e. transformers. Now thats finished (phew! 5 years), I am spinning out a company which will build self-reconfiguring modular robotics hardware (if we get investment etc. etc. lots of unknowns so don't get too excited yet). Building this robotics kits is pretty hard, so we are trying to come up with a plan that incrementally builds the vision, one robotics application at a time (see http://www.youtube.com/watch?v=fsCKs31QB8Y*). I would like to pitch one idea to you, to get feedback, to see if you like it. One of the simplest applications I can think of that is a robotic building block to greater things and is modular and that might have targeted appeal is: a 3D optical scanner.

The optical scanner would be 2 modules. One camera module, and one module that has a 360 degree rotating plate. The rotating plate is placed somewhere with an object upon it. The camera is placed elsewhere but with the rotating plate and object in view. The software then spins the object, and translates the information into a CAD model. These kind of system exists in the professional world, but I don't think their is really a hobby level one (http://www.david-laserscanner.com/ is software only). I thought this might be useful for indie game devs. because 3D artwork is hard to come by, and its probably quicker scanning objects than drawing them. Indie devs seem to prefer 2D, but maybe this is because 3D art takes too long??

I would love to hear if you would think this might be an item you would watch with interest, or whether it is totally inappropriate for the things you do. I truly welcome negative and positive feedback, and conflicting opinions. The better I can judge the appeal at this stage, the better I can allocate my time.

Tom

PS Minecraft is awesome, hooray for Java, hooray for JGO and hooray Markus! *351 views as of posting. If any of you are journalists then this is not a story as yet.

I am saying we can get bogged down in abstract math details which is not that important when implementing a car driving game. The difference between the types is nice to know, but doesn't really help point you in the right practical direction (tan2  <- not a mathematicians invention or naming convention).

hehe, math pedantry.

You can go into alot of detail about what-is-what. Vectors, scalars, pseudo-scalars, bivectors etc. are analogous to types in the math world. So a scalar and a pseudo-scalar can be written as a real number, but mean subtly different things. So some functions accept certain types, even though the number of reals are the same. For our purposes, the difference is how the value is interpreted in a geometric context.

Vectors are sometimes used just like arrays to collect math variables up (general use). In a geometric context a Euclidean vector denotes simultaneously a direction and a magnitude in a Euclidean vector space (what we are dealing with, 'normal' geometry).


Rotation is the classic example of where the subtleties creep in (in a Euclidean vector space).  So the angle between two vectors is a firm concept for a Euclidean vector space (in all dims), it always considered positive. The problem starts when you want a polarity attached. E.g. in 2D, what is the angle clockwise between vector A and B? The clockwise bit is an additional property of the vector space, which needs to be defined. So when you have angles against a global handedness of the space, your new signed angular quantity is something (subtly) different to the old one (even though both can be represented as reals).  So the signed version is a pseudo scalar whereas the first is a plain scalar.

So rotation is not really a vector quantity, in 2D is a pseudo scalar. In 3D it has three components, but they are related in a weird way and have their own type SO(3). You can't really call them vectors or psuedo vectors because they won't go into any function that normally accepts vectors and compute anything that makes sense.

All of this is not that important to know. We all have our own internal heuristics when we want to practically apply coding in geometric space. Mine is "rotation is a pain in the butt", and its the reason why we have to have the tan2 function in 2D (the quadrant aware version of tan), and quaternions in 3D. Whenever I find my rotation code is buggy or bloaty (like lots of ifs to determine an angle polarity), I start checking where I can use the tan2 function.

e.g. http://www.euclideanspace.com/maths/algebra/vectors/angleBetween/index.htm

I like rule based systems because they are easy to hand craft. Decision trees are difficult to hand code in my opinion. That said, I *love* decision trees for learning. Stuff like neural nets (NNs) and genetic algorithms are easy to screw up if you don't know what you are doing (e.g. regularization and over fitting). Decision trees are reasonably easy to read by eye compared to NN. As a result, if I need a system that can learn, I fit a decision tree. If the results seem funny you can work debug manually pretty easy. I also think they are quite a natural fit to computer execution because they are jsut a big ball of if/elses (as opposed to a fan out of floating point arithmetic a la NN). Your link is pretty old skool stuff, you can get some modern decision tree stuff like the C4.5 algorithm *in java* at:-

http://www.cs.waikato.ac.nz/ml/weka/

enjoy!

1st4ck is close. If monsters spawn at A and try to get to B you can double check there is always a path from A to B but that does not include the case that the player encloses a completely different area of the battlefield.

You want to ensure that *all* space is connected in one connected blob. Invoke a minimum spanning tree at A or B and check that the number of areas of space encountered = the total number of space tiles.  If you have A* coded, then spawn an A* with no goal, and terminate it when the queue is empty (count the unique empty spaces encounter and should equal the number of spaces on the field iff empty space is fully connected)

It does not matter if the branching is constant or not. At the end of the day if you have taken out 1000 node from the queue and you have 10000 nodes still in the queue, with a binary heap you had to sort all 1000 + 10000, and with a fibbonacci you only sorted the first 1000 took out the list.

FibbonacciHeap does have a slight overhead compared to a good BanaryHeap implementation, so for tiny searches its better. This is the same argument of why bubblesort is better than XYZ sort for small lists. If you need A* (i.e. a guide heuristic), then your searches are probably big enough to feel the gain of a FibonacciHeap. There is a good paper that suggests in practical instantiations a pairing heap is better than a FibbonacciHeap (lower overhead but still lazy), but I can't find an implementation of that type of heap.

It should be quicker, it sorts lazily. You will only notice the difference if your searches created big heaps. It does not make an intractable search tractable, it just lops off one level of node expansions worth. Searches are generally exponential in nature. Using a lazy heap like FH is like the difference between one city in a travelling salesman problem i.e. it can be a significant difference, but it does not fundamentally change the complexity.

consolidate is protected and not recursive (I think). So maybe you could subclass it and use a dynamically resized cached array instead of allocating a new one every time. I would have thought the main allocation blues would be the creation and destruction of FibbonacciHeapNodes though whenever things are put in or pulled out. Again, I am sure there is a cached way out, but its not a use case the creators of that package probably deal with. The maintainers of that library are pretty open with source contributions, I have submitted stuff for it without much hassle.

Tom

http://www.jgrapht.org/ for DFS, BFS etc. Also has a Fibonacci heap implementation if you want to build a fast A*.

Update: JStackalloc dependency removed. I have not really replaced like functionality with like, so most (but not all) of the previous stack calls are falling back to garbage collection which I defiantly don't want to happen. But the system runs now without having to go via an annoying ant script. I'll finish the job off on the weekend at some point, which will give me time to think of a clever way of doing it .

@moogie

if sending rays out from pixels that ultimately hit the back ground cost near nothing to compute then there will be little gain in predicting a large set of rays that will miss.

No not frustum culling (although that is clearly necessary), I was trying to flesh out what Simon meant by:-


In space what you mostly view is background. you only need to shoot rays for the areas of the screen where the ray's may hit something. I dunno if you take this into account or shoot a ray for every pixel.


We do know the objects AABB. So you reverse shoot rays from the corners of the AABB's in order to find approximate bounds of the objects in screen ordinates and shoot rays only in those regions.

If the space is not cluttered, then you can work out where the AABB are roughly located in screen ordinates, so only raytrace in those regions. e.g. work out the line between the 8 AABB corners, the camera's pinhole and determine where the each AABB corner interesects the screen plane (8 2D ordinates) and ray trace only inside the minimum rectangle necessary to enclose all of those 8 2D points.

It would save loads of time when other ships are not occluding the screen much, but will not save much time when you are coming into dock/colliding with another ship, or viewing your ship in third person. On the other hand, by interpolating your 4x4 box, near polygons are optimized in a different way, so who can guess the performance of the combined approach?

Whats your frame rate at the moment moogie?

(back to work)

Great moogie, I am interested to see where you get this.
Its better doing something slow and getting it done than producing broken code in a few hours. Right... back to work

Tom

Sorry I should have said this a couple  of days ago, I have to get a peice of work together by Wed. So I have had to work this weekend. I'll do what I was going to do this Sunday on Wed after I have done that. Then perhaps I will be able to work again on Sunday next weekend (but perhaps not because its all related to a tight deadline on March the 1st, but it is my target).

Tom 

hehe,

Yeah I'm UK. God save The Queen etc.

Yeah the code is pretty messy. It comes from several facts.

JOODE is tied to its collision model. You add joode.Geom's to Bodies. Obviously JBullet  classes don't implement Geom, and nor would they suit doing so (because JBullet doesn't have a hierarchical Space model).

So JBulletBodyInterface wraps a Body and allows CollisionObjects to be associated. (and at the same time instanciates various listeners to track body changes that occur after a world step). I might just subclass Body to create a JBullet body which probably will probably be simpler. (...yeah I will)

JBullet's CollisionWorld doesn't have an event model so it is adapted in with I can't rememeber the name but JBulletCollisionWorldAdapter or some such. I am using the adapter pattern heavily at the moment till I can intergrate deeper.

So everything JBullet related is adapted to try and make it behave like JOODE does. Which results in huge names and messy code. Further complications arise because high level JOODE functionality is event driven which is fine when you understand the events but terrible to read.

Anyway, yeah. We can exchange phone numbers. I only work on this project on the weekend though.

Tom

 

Mouse click thrusting is fine for a space trader game. But it all ends up a bit generic. The best idea I think I have had for this game was special moves for combat. But that implies decent combat which I don't think you can do via ultima underworld controls. I think maybe the best comprimise would be to permit mouse click turning at the perifery of the UI, but also have the keyboard shortcuts for turning at ADWS FPS on the lefthand. That not saying let the user configure his controls on startup which is what I meant by non-casual friendly (its the configuring part, not the actual controls I was objecting too).

The means the mouse can still be used for targeting and other UI tasks on the HUD, and the space trading fan can control the whole ship from the mouse, but the combat maniac will have familiar FPS controls.

Possibly... left click I would of thought meant shoot, but if its used for thruster or select target or click buttonl then what? Maybe if a click on the crosshairs means shoot, and the keyboard player has space bar or something?

Thrust 1-9 is classic elite. I was actions could be bound to those keys though but probably there won't be enough actions to warrant that. Mouse players could have scroll wheel as well? Does everyone have a scroll wheel now?

Tom