Weeks Unknown – Scaling Troubles
After many disruptions, holidays and general laziness i finally got around to doing some more work on Saga of Sol. To start off the term i had begun setting up the framework and basics of the local planet view. This is the view that when you are playing the game you are going to spend the most time in, building your armies and crushing your foes, and so on and so forth.
However not long into the programming i hit the barrier of software surface transformations. The simple effect being that when zoomed out a long way or scrolling quickly. Looking around at getting pygame to correctly take advantage of hardware surfaces, i quickly found that the general consensus is, dont bother and i got redirected to pyglet.
Pyglet is another python graphics library based around opengl and makes good use of hardware surfaces by default. In learning pylet i stumbled upon some basic guides on game desgin and another guide that provides a basic camera class for me to base my scrolling and zooming upon.
After lots of modification i have got to a point where one is able to zoom in and out towards a point on a map and scroll around in general RTS style. More difficult was trying to convert between screen and opengl (world) coordinates so you are able to identify whereabouts in game space your cursor is.
A screen-cap of the running trial, the scribble is made by moving the mouse to show correct conversion between screen and opengl coordinates
I will hopefully have some code up soon for those that are interested, as soon as it is tidied up and commented
And So Ends NCSS 2010
The past weekend has been a large on in programming for me, having both the finals for Progcomp (Run by the university of NSW) and the last week of the NCSS programming challenge.
In Progcomp my team managed to soar up the ladder from last in the finals to second last (that's still 6th place out of 13o teams or so overall) and was utterly flattened by James Ruse who finished all the challenges in an amazing 1:40. We Still had an awesome time going up to Sydney and having a look around the university on its open day and we look forwards to hopefully being back next year.
Last week was also the final week of the NCSS challenge where you are given 5 problems to solve for 5 weeks. The beginners division of this competition is a great way it get into learning programming/python if you are interested. This year i entered the advanced division and managed to place 11th on 188 points solving all the questions except for the last and rather evil Peg Solitaire question (worth 20 points instead of the usual 10) . I am reasonably happy with this and hopefully i am able to move up the board a bit more next year and so ends NCSS 2010.
openTrack V1
I wrote up a small tracker server for a friend on the NCSS challenge forums. Its intended use is for connecting users in simple P2P applications such as chat programs, games ect.
It can be accessed with brief instructions HERE
Also as part of the project i learned how to use GIT so the source of the project can be found on Git-hub HERE for those interested, so if you have any ideas or find any bugs that would be the place to leave them.
I hope somebody finds this useful, and if not i think i may have some uses for it in future projects (such as super multiplayer multilayer networked pong)
The problems with pathfinders
Path finding can be an important part of many computer games. Unfortunately generating the nodes (points) used to find paths can often be very resource intensive.
Path finding in games can fall into two categories:
- Nodes are created when the level is created, usually manually and then saved into the level file
- Nodes are generated by the computer on level load, and possibly saved for the next time the level is loaded.
Recently i have been working on creating a program with python (using A* path finding) that can find the shortest possible route though a picture (.bmp or .gif) traveling only on white.
Some of my first versions of the program were extremely inefficient, generating many nodes that were inefficient and un-needed. It is not creating the nodes themselves that slows the program down but creating the links between them.
- Red dots are nodes
- Blue dots are nodes it has considered important
- Green lines are links between nodes
- The blue line is the final path
Version one of the program, it created all possible links between nodes, generating the path itself may not have taken long but to generate all the node links took over 2 minutes
My second version of the program attempted to select important nodes, the picture below shows the nodes it thinks are important
Success, it works much quicker than before with this maze being solved in about a minute
However it doesn't work for mazes that have allot of straight lines where the program ends up doing more tidying than it should, therefore making the maze unsolvable
The next version of the program tidys the nodes more quickly and also had a smaller grid size i found that for the program to run fastest, grid size should be less than a third of the width of the corridors, this new version managed to solve both the straight edged maze and the curvy maze, however it did a much better job at tidying the straight edged maze which took about 30 seconds to solve as opposed to just under a minute for the curvy one.
This was the most complex maze that i tested my program on and i got widely differing times depending on the grid size, by far the fastest was setting it to be the same as the corridor/wall thickness, however if it is slightly out it would probably fail, Solved as in the picture below it took about 30 seconds, or with a smaller grid size (less than a third of the corridor size) taking about 45 seconds
The program still has a few more tweaks to go before it is finished and then i plan on making some kind of demo game out of it.
If anybody has any ideas on node generation or a good way to tell witch nodes are important and which ones aren't leave a comment or send me an email