Planet Free gaming

At the moment everything beside the forum should be up again and working as expected. That is all subdomains like gettext.wesnoth.org, units.wesnoth.org and the whole lot should be back up and working again. The wiki is working again, too. We hope that no data in the wiki was lost. If you find any pages having problems, please try to fix them. There is a list of files we do know that are broken/missing. If you have a local copy of any of those files or encounter missing images not listed there, please contact us.
Regarding the forums cycholka is still busy with making it work again. No idea if we will lose any data regarding user accounts and forum posts since he is currently fighting the user table. We don't know how many attachments are broken but found a backup for files from before march 2008. So at least some files are secure...
We will post updates every now and then to keep you informed.

_{-- Delivered by Feed43 service}

As you might have noticed we are currently enduring some problems with our main server. That is: about one week ago we had a major harddrive failure resulting in the system not working at all. So far we don't know exactly how much of the data on the system is completely lost since we are working on restoring things. So far the multiplayer servers (stable and development) are back up again and the subdomain redirects like gettext.wesnoth.org are working again. What is not working so far are the forums and the wiki. The problem is that parts of the database seem to be broken. Currently cycholka is trying to fix and restore whatever is possible. Some stuff is completely lost like the screenshots folder we were using including the ancient screenshots. If anyone of you has a backup of those, feel free to contact us. We don't know how many of the forum attachments are broken but it is likely that some will not be restoreable.
We hope to have the wiki and forums usable again in some days but we don't know how long it will take. We will soon migrate the main server to a different machine anyway. This one will offer more network bandwidth and due to this make the website feel smooth again. We are not 100% sure if we will restore the wiki and forum completely before the move, so it might be that you are on the new server when the forum and wiki are up again...
I will try to post updates every now and then and please keep in mind that asking "when will the forum be up again" in our IRC chans won't speed things up at all. So please stay patient and play Wesnoth instead of using the forums. ;) If you are interested in some more info, have a look at the (unofficial) Wesnoth Journals.
Update: Okay, with the data provided by the Internet Archive it was possible to restore many images. The bad news is that basically all post 1.2 images seem to be lost. Have a look at this list of missing images to get an idea about what is missing. If you have the respective images, please contact us.

_{-- Delivered by Feed43 service}

Wesnoth 1.4.4 has been released. This is a bugfix release for the stable 1.4.x branch. In this release several smaller bugs were fixed and many translations were updated. To celebrate the release and comment on it, have a look at this forum thread. There are still two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice (only translation updates this time) and the (rather) complete changelog with (almost) all the details, which is not much more to read either...
At the moment the Debian, Gentoo, Mac OSX and OpenSolaris binaries are ready. Once the others are done you can find them at the download page. We hope there are no bugs left, but if you find any, report them.

_{-- Delivered by Feed43 service}

A new Development release is ready. This is the third release in the 1.5.x tree. A lot was changed since the start of the stable 1.4.x branch and since I am too lazy to list all the great changes in here, better have a look at the forum thread which describes the most important changes. As with the last releases, we continue to offer two versions of changelogs: a rather nice to read players changelog that only includes changes every player will probably notice and the (rather) complete changelog with (almost) all the details, which is likely to cause a serious headache...
Please keep in mind that it is a development release which might include quite many bugs. If you find one, report it.
Update: The Windows binary is now available on the download page.
Update 2: The MacOSX binary is now available on the download page. It is only available for Intel based Macs (x86) until some problems with the new dependencies are fixed.

_{-- Delivered by Feed43 service}

The add-on server is now migrated to our main machine. Beside this I changed the default reference ingame to point to add-ons.wesnoth.org instead of campaigns.wesnoth.org to make clear that stuff on this server does not only include campaigns but basically every kind of add-on that is possible. I also updated the DNS entry for campaigns.wesnoth.org to make it point to the new machine, but it will take time until this takes effect. But you can already use add-ons.wesnoth.org to get add-ons. It does not matter if you use campaigns.wesnoth.org or add-ons.wesnoth.org, it should soon take you to exactly the same machine. On this server add-ons for the stable 1.2 and 1.4 series are available, as well as add-ons for the development series.

_{-- Delivered by Feed43 service}

Finally everything should be back to normal again. That is the forums are up and working, too. In the crash the last two months of forum post were lost. That is even the attachments are likely to be broken and everyone will have to reupload their forum avatars. If you encounter any problems, please report them in this forum thread.
Once we are sure that the new server can handle the load, we will also move the add-on server here. This will result in the add-on server being down for a day. We will probably migrate it some time next week.

_{-- Delivered by Feed43 service}

I've changed some models, added some new textures and models in continental climate area to shape things to the aesthetic level of the jungle probably. Maybe it can suffice the needs of the classic style, some better base bush + small bush texture could be added later, but for now I'm rather content.

The released snapshot is starting to get some attention around the net. Some of you may have tested it, some of you certainly did and even reported me back with suggestions or bugs. This is really nice. We hope to get much feedback - even if you just tried and have something to say or just report success - that would be cool!

Qubodup at freegamer is one of the testers - a thorough tester indeed! :) He even made a video of it and made it public on freegamer blog! Thanks! I will embed it here too. On the suggestion of an anonymous reader I've added jcrpg to the retroremakes.com's list of games and forum.

Now here's the video at gamerstube.com for the ones who want an indirect look at the game:



PS: jClassicRPG has been listed on a recently created good looking Linux game database site LGDB. Check it out, new design and nice features!

jClassicRPG 'Vigilante Eye' is out for us to get. The game engine is nearing completeness, dialogs and a quest system need implementing. Then we'll be able to slay our first 15 foxes for the lazy shepherd Osgar Lindquist. The following features all-ready work:

• Fighting: Bash (monsters) and be bashed (by monsters)!
• Items: Collect gold and pieces of wood from slain foxes!
• Camping: Rest to regenerate health, energy and mana!
• Leveling: Spend hours deciding on what stat to increase!

And this is where you come into play! Get the release. Timong is waiting for your bug reports, patches and feature requests! =D

The visual (and aural) and performance improvements that happened lately are pretty much wow. The terrain now looks very natural compared to earlier versions, there are new animated models, there is a tropical background sound loop. I created a rather long video that shows off some of the new features. (Direct download, 118 MB, recommended)

I'm currently working on a simple categorization of all the stable and or mature game-related projects hosted by SourceForge.net. Not fun. But the results will hopefully be.

I will try to learn from Edwart Tufte's The Visual Display of Quantitative Information (which should have shipped today) to create some nice graphical overviews. If you can recommend me a statistical data visualization application, please do!

I started a theme for the Tetris Attack-clone block attack. The current status can be seen in this video. Criticism is welcome. :)

The LÖVE smiley competition, in which you can win an awesome comic book, will end in two weeks.

PS: our new-found friends at TIGSource are having a remakes competition. This contestant appears to be willing to release her Bootlet Bash's code and media as free code and art!

At last! What Bolsheviks were dreaming about for so long now comes true: after a whole month of work we present a final Battle Tanks 0.8.7656. And even for Mac users! Thanks to all for your bug reports, and please send more!

The full changelog is more than 100 lines long, so we will only mention news after 0.8-RC1.

General:

• The engine is ported to MacOS X 10.5 Leopard. We also think about a port for 10.4 Tiger.
• For linuxoids, an “install” target is added for scons.
• A new Ukrainian localization is added, as well as new diacritic marks for the Cyrillic codepage.
• Thanks to a better algorithm of counting the delays (based on bar chart of errors) and a new method of serialization of floats, the quality of life network game became better.
• A DNS cache is added to eliminate delays on scanning the servers.

Interface:

• Servers in the connection dialog are now colored: live servers are green and dead ones are white. We have also added a progress indicator for the scanning process.
• Buttons are now highlighted on mouse hover. Easy but looks great!
• System messages are now displayed using user’s language, not server’s.
• System icons are re-drawn for WinXP, Vista, and Mac.

Gameplay:

• Damage is increased for tank ammo.
• Shilka now unloads its cargo when it is killed. So if there were troopers or nuclear mines inside–they drop for everyone’s joy and surprise :-) .

Fixes:

• An incorrect work of UDP on BSD systems is corrected.
• Hanging on scanning servers is eliminated.
• Crash on machines that don’t have a sound card is fixed.
• A wrong number of channels in ogg stream is now right.
• Problems with broadcasting UDP are no longer problems.
• A bug is fixed that allowed some objects to be immortal. (Everyone should have seen a non-destructible spaceport on cooperative maps.)
• A swarm of small but nasty errors is fixed.

Warning! The Internet game server is also updated, so please don’t try connecting to it using an old client.

My 30 days 4 hours a day programming challenge is officially a success. It has propel me to new heights in such rapid pace not seen in the 2 years I been programming. I also learned what it meant to be a disciplined programmer and learned a few new tricks as well.

During the 30 days challenge, I worked on the game engine and the map editor for the KRPGE project, Playground Wars, Space Fighter Ace and the Rubygame Tutorial project.

What I Learn:

I have learned through the 28 hours workweek why my game development projects has been so slow to progress in the past. They just took a lot of work. Even with the 28 hours work week, I still felt that progress is very slow. Nonetheless, I managed to finish the KRPGE's engine proportion in about 14 days. The Map Editor is finished in about the same timeframe.

What went right:

Of course, I was able to keep the schedule despite interruption by parents and outside events. Best of all, I was able to progress phenomenally fast in comparsion to my usual pace of development.

What went wrong:

If there is any wrongdoing, it is that I was undisciplined when it come to designing my game engine's codebase. Although it was easy for me to use, for others, with no documentation, cannot use it. There are several releases of KRPGE but nobody use it except me.

What I would do differently:

I would learn unit testing and set up a bugtracker for each projects. I would also package all my games as gem. Also, it would be nice if I know more about optimization technqiues as my games tend to fall below 30.

What I gained from this challenge:

The most improtance gain is productivity, above all. I finally broke the cycle of procrastination and no game development. I tried many schemes but none work as well as the enforced work hours, in which I was driven to develop under pressure. This build upon my experience from the first RubyWeekend contest. I will continue to use this concept to help keep game development going.

I also gained a newfound apperciation of the difficulty of writing games evidenced by the slow development cycle.

Still, all of these sucess would mean nothing if I don't keep on the pressure on myself to continue game development at this kind of level. That's the next challenge.

Yes, we're ascending to the next level of our destiny through the obstacles of the great dev-eater beast of Tiredness and Desperation. We have entered the sanctuary of the miraculous Release again. Here we stand astounded and in silence, holding back breath. We are aware that something great surprising and of elemental effect may happen anytime. As we are there awaiting for some never-ending minutes, a booming sound starts to cite something strange, slowly - pressing each word. Listening carefully you try to memorize what's being told:

"
- Turn based playable Combat phase added
- New animated models (boarmen thug and mage by Zphr)
- New house and town models (by Zphr)
- New static monster model (kobold by Surt)
- Total redesign of jungle plants, new plants for continental,
- New Encounter Ground system that separates the encounter scene
- Inventory enhanced (equip,attach,give,drop)
- New Loot Window after combat
- Character leveling
- New ground tile generation system with smoothed ground
- New 2D elements, some refactored UI images
- Optional support for secondary ground textures
- Optional texture splatted ground tile blends
- New spells, skills, items, artifacts, objects
- Bard instrument concept available with one implemented item
- Particle system with lights for spells added
- Support for continuously playing sound sources like waters, forest ambient
- New environment & humanoid sounds added
- New Body Part system that enables critical impacts
- Optimizations: tree trunk batching, cutting of non-visible interior parts, more locking
- Bug fixes
- Far view mode is disabled till fixing it for the new ground system
"

Right after finishing these words, a glowing globe elevates from out of the darkness of Sanctuary. Yeah, now you know what awaits you, jcrpg next sneak-peek enchantment is in your hands like a crystal ball. It may be that it helps you to look into a distant Future... let the Trial begin!

Great Heroes, come and test your wits - play the game or create your own tormenting beasts! It's high time - because combat is ready to begin NOW!

Candidates for Testing and Modeling - don't hesitate!

PS.: Just this moment I decided to reupload the release with a bugfix - it was a major problem with non disappearing 3D models. The old one I've deleted so from now on the new and only one is the good one.

Zphr and me were working hard to finish the facelifting of jungle. Meanwhile Zphr provided the game with some extra nifty palm and bush models, I've started to look at optimization again. My new idea was to add billboardpartvegetations' trunk part to the ModelGeometryBatch. It is now handled separately of the foliage trimesh geometry batch - the trunk trimeshes are commited to a batch containing several other tree's trunk. This reduces number of meshes - reducing CPU and GPU load.
Also I've found a better way for handling internal Cave parts - there's now Cube's internalLight field which is used for cave entrance only. That part will use a turned off sky, while you move into the cave. This transition part will lead into the cave cubes' part which is now unnecessary to be rendered while you are totally outside (not in an internalLight cube) with the 'three-state' solution of ExternalCube / InternalLight / InternalCube. This whole boosted up performance again so much that I'm a bit happier with it running on my 6200Go.
Bad news is that I had to remove farview option because with the new smooth tiling generation the farview water is not working well just as the welding of farview geo and normal geo is not solved at all.

There were some complaints about the game on freegamer blog and here. About crash on OS X. If someone happen to test, please help out us on jcrpg forum!

Today, I spent time trying to optimize my game's FPS from a pitiful 15-20 FPS to acceptable 30. Though, it still seems to suffer from having too many objects in the game, which may make large scale battles impractical and possibly limit the game to a few fighters and objects.

For practically 90% of the increase in FPS, I merely eliminate most of the 900 map objects, it would still pose a significant problem if a users were to add lot of map tiles though.

It seem that the engine is improving during this iteration of game development. So much, that I decided to port the engine code back to KRPGE sooner rather than later. See the roadmap for details.

However, I soon hit a roadblock on my optimization problem because I don't know how to optimize further and the lack of available immediate help. So I decided to focus my development effort entirely somewhere. For that, I choose to work on my Rubygame Book.

The development work was especially fruitful because I finished part 3 and started work on part 4.

I still hope to return back to game development work because I got a gloomy feeling about Space Fighter Ace's development cycle. I feel it will be a long slog before I finally complete its development goal. For this, I estimated at least a month.

Well, this is the last post of the 30 days challenge log! A postmortem of the 30 days challenge will be written soon.

I think I found the oldest open source game out. It's called Conquest. In development since 1982. That's kinda awesome.

It is a real-time, multi-player space warfare game. Both curses and OpenGL clients are provided. It looks a bit like 2D Star Trek ship battles (not stereotyping there, it just does).

So, want to be brainier? Well, Brain Workshop might just be the answer.

Brain Workshop is a free open-source Python implementation of the Dual N-Back mental exercise. This exercise is the only mental activity that is scientifically proven to improve your short-term memory and fluid intelligence (IQ). The game involves remembering a sequence of spoken letters and a sequence of positions of a square at the same time.

O_o

Remember Portalized? I kicked up a bit of a fuss over it several months ago. Well, it has it's own website and forums now, and seems to be coming on a bit. It's not yet open source :'( but a bit of positive encouragement might make that happen.

Random one: I thought these faces were quite cool (OpenTTD).

There's a new stable release for VDrift. I'm not sure that it's much different in terms of features to the last VDrift release as lately the development effort has been on a refactoring / rewrite of the code (which is progressing well).

Also Simutrans 100.0 aka 1.0 got released. This really snuck under the radar as it's a very good open source game and not very well known in comparison to OpenTTD, but it's totally Free Software - something the OpenTTD guys are trying to fix but have a lot more work to do on.

The Simutrans team lost their previous forum when switching from one host to another. Which means the Simutrans website is a bit broken (most information was kept in the forums, so many of the links now just don't work). The main issue with the stable 1.0 release is that there is no official release of pak128 (the hi-res graphics pack) for it, although you can try your luck with the nightly builds which does have a section for the latest version of pak128. I'll leave you with a video of Simutrans pak128 although watch out for the dodgy music:

Today is Day 29, so tomorrow is the last day of my programming challenge to code 4 hours a day.

With 4 hours a day, I am slowly crafting Space Fighter Ace game mechanic, with some markup in difficulty in comparison to previous projects.

Today, I finally accomplished the death mechanism of spacecraft and bullets collision, although it have no special effects. I believed it took me two hours to accomplish this task. Another hour is spent on trying to futilely finish the movement code to no avail. The rest is spent on miscellaneous task such as trying to debug the mapeditor program, writing FPS display code for the Hud, and improving the game's FPS.

Ludum Dare 12 starts in three hours. There are three lists of hints for python game programmers who are going to join the competition: SolHSA’s, mrfun's and GBGames'. Hints that help you be resourceful, constructive and alive before, during and after the contest.

jClassicRPG is getting bigger, prettier and cooler.

By the way: Orbit-Hopper does work on my machine. Only the 1.16 build creates segfaults. 1.15 works fine. (Though suffers from extreme slowdown when I try to record it.)

Post Scriptum: OpenArena 0.8.0 has arrived in a bigger than 300 MB archive. It contains some new media and "mission packs"

Missionpack is basically the trademarkless codename of Quake III Team Arena game code and since we've completed the minimal essential assets for it in this version it's 'playable' to the extent where you can score points in Harvester, Overload and One Flag CTF nicely. Among the game types is the 'annoying voice system' where you press a key and it says stuff audibly.

I don't really understand, but will check it out in 2.5 minutes.

Post Scriptum 2: The Uzebox will apparently be completely free as in freedom. As this note appeared yesterday on the project's homepage:

Following many requests, all sources and schematics will be published by August 24th '08. That's pretty soon so stay tuned! And everything will be released under fully free, open source licenses...open software, open hardware...hope you enjoy!

It happened to me that the jungle trees are not cool enough, especially the foliage was lacking some perfection. Check the shots for the new version. Meanwhile some bugs were resolved. One more bug till we're ready! PS.:Don't miss the texture based new vegetation shots either - I've added some.. :)

For today, I mostly focused on writing gameplay features such as the capability to shoot projectiles and then destruction.

Though, I mostly got stuck trying to figure out why the projectile have collision problem. It took me a while that the rect size is too big for that image. I promptly fixed it.

After that, shooting finally work. I then code a feature to allow the projectile to go faster than the player at a given speed.

I also added an enemy object and remove all its unnecessary legacy code.

I cleaned up Characters Law and then started work on a new feature that will ignore certain objects for collision detection purpose. I also did refactoring that allow player, projectiles, and enemies to share common characteristics.

Although, I been practically gone all afternoon and all morning, I was able to start coding by 16:00 and finish the session for 20:00.

I got a little lecture from Beoran on trig so I can figure out what the heck I am doing with the movement code. Thus, I learned enough to figure out the angle for moving left. The lesson and movement code were incomplete though.

Since I probably didn't have much to do for movement code, I worked on other part of the game instead. I worked on the weapon, rewriting and cleaning up. Due to what the weapon system require and how I need the game to work, I extended the engine to allow for adjustable camera movement and then add an easy way to add characters. I also did the usual cleanup such as eliminating obsolete source code and data files.

I've been working a bit on adding looped environment sounds and their sources. Now mostly all kinds of places have a gentle background sound - town, waters, jungle, forest. A lot of other new single time played sounds were collected and added - walking in snow, dog barking, crickets in the grass. It's pretty nice now walking around and listening to changing sounds. I love it! :D The new sounds are from freesound.org with no exception. A great place indeed! Zphr's been working a while to make his wooden house model even better! Now it's less polygon and the same good look. He's done a great job again! This is all in SVN. There are only a few bugs on my list now that separates us from releasing... Hurray! :)

Welcome to yet another FIFE update :-) We'll keep things short today as I just got rather few time on my hands.

A new name for FIFE

As announced in one of the recent news updates: FIFE is currently searching for a new name or at least a new meaning for the acronym to underline that we've moved away from our Fallout roots.

We want to thank everyone who took part in the process by bringing up suggestions. Here is a list of the proposed new names and acronym meanings:

New names

• BirdEye
• HawkEngine
• HawkEye2D
• Hawk2D
• KNIFE (e.g. Kool New Isometric Flexible Engine)
• Quest2D
• Raptor2D

New acronym meanings

• Fast Insanely Flexible Engine
• FIFE Is (a) Flexible Engine
• FIFE is Isometric, Flexible and Extendable
• FIFE Isometric Flexible Engine
• Flexible and Integrated Free Engine
• Flexible Impressive Free Engine
• Flexible Insanely Fast Engine
• Flexible Isometric FIFE Engine
• Flexible Isometric Free Engine
• Free Isometric FIFE Engine
• Friendly Isometric Flexible Engine

Other proposals

• Get rid of the acronym meaning completely but stick to the name FIFE

Roadmap

• You got 3.5 weeks to vote for two proposals of your choice. The poll will end at 31st of August.
• Every user who is registered at the FIFE forums can take part in the poll. It can be found here: http://forums.fifengine.de/index.php?topic=176.0
• After the poll has ended, the developers will sit together and try to agree on one proposal. The proposal which got the majority of the votes will be con sidered first. In case we can't agree on it, we'll go through the list of proposal from the one which with the most votes to the one with the least ones.
• As it's likely that we won't be able to agree on one proposal unanimously, the final decision will be left to four key developers in this case (jasoka, jwt, mvbarracuda & phoku).
• We should have a new name for the project at our third project birthday.

Project birthday

As just mentioned above: FIFE turns three in early September. The project was founded at 2005/09/11 and we plan to celebrate the birthday party together with the community on our IRC channel. The plan is to meet at the IRC channel in the evening hours (GMT) of 09/11 and to have a chat. In case you wanted to get to know the developers anyway, this is a good chance.

We recently added a link to the mibbit IRC client that runs in a normal webbrowser to our wiki. In case you want to visit the channel without installing a separate IRC client, just follow this link.

I'll post a final reminder 3-4 days before the project birthday nevertheless to ensure that nobody forgots about it.

New graphics tutorials

Our graphics artist Lamoot was hardworking lately and wrote two tutorials that should help other graphics artists to bring their isometric art into FIFE. One tutorial covers how to create a suited rendering setup for your FIFE-based game while the other one explains how to create isometric tiles. Both of them are still work in progress but hopefully they already serve a purpose nevertheless :-)

Searching for testers with ATI graphics card

Last but not we would like to ask the community for their help. We discovered a rather strange bug some months ago and we had a hard time to narrow it down. We recently found out that it just seems to affect users who use an ATI graphics card on Linux in combination with the proprietery ATI drivers.

The issue

The issue seems to be caused by a combination of:

• ATI graphics card
• Proprietery ATI driver
• Linux
• libstdc++
• Building C++ code as dynamic library and importing it into Python (with the help of SWIG)
• OpenGL

FIFE segfaults for a number of users who own an ATI graphics card whenever FIFE tries to throw an exception. The mistery is that it only happens if FIFE is built with OpenGL support (is linked against the OpenGL libraries). Even if you build FIFE with OpenGL support but use the SDL renderer, it will still segfault. We tried to track down the problem but Valgrind only led us to libstdc++ and glibc. We were not able to debug the problem further but it looks like it's related to thread local storage; besides that we're still puzzled about the problem.

Therefore we would like to ask the community to help us tracking down the problem. You can help us via two ways:

Testing FIFE on your system

In case you're running Linux and got an ATI graphics card you can help us by testing FIFE on your system. A tutorial how to reproduce the problem can be found at the wiki: http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception#How_to_reproduce

After you tested FIFE on your system, please fill out this template: http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception#Template

After filling out the template, add the information about your system to the wiki. In case you don't want to register at the wiki for this sole purpose, please drop into our irc channel, paste the filled out template at rafb and post the rafb link on the IRC channel.

Investigating the bug

If Valgrind is your tool of choice and you can actually reproduce the bug on your system, please consider to help us tracking it further down. Every helping hand is appreciated! In case you would like to give it a try, join our IRC channel and get in contact with one of the developers.

Next steps

Once we've collected enough information about affected systems or some Valgrind magician helped us to track down the issue, we plan to get in contac with whoever might be able to fix the problem. We guess that it's either a problem with gcc or an issue with the proprietery ATI drivers. So in case you got an idea whom to contact best in these cases, let us know! Thanks for your help in advance.

Additional links

I don't have the time to explain the whole bug in detail here. Everyone who's interested in the problem should check out these links:

• Bug report at the forums: http://forums.fifengine.de/index.php?topic=30.0
• Bug report at trac: http://mirror1.cvsdude.com/trac/fife/engine/ticket/297
• Wiki article about the bug: http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception

That's from my side for today. Next news announcement will be the IRC birthday party reminder. Don't expect much activity from my side until then :-)

Posted in: exception, FIFE, acronym

Today, I started to delve into an unknown terrority, forcing me to use geometry that I never used before in game programming. Progress is slow as I struggle with the challenge.

Right now, I am trying to implement angle based movement so that my space craft has a more realistic movement. I think I got the up angle movement right.

I also accomplish other task. For example, I decided to expand the resolution to allow for UI. Then, I implement a HUD class to give me information on velocity for debugging purpose.

It’s time to announce the winners of the RubyWeekend #2 Contest!

Third Place: Mizutoka by jlnr!

Second Place: Cheese Master by elcugo!

First Place: Opposite Islands by ippa!

Congratulations to our winners, and thanks to everyone who competed or voted! It’s no easy task to create a game in 48 hours, but I hope everybody had fun and learned something new!

Here are the full rankings, with a breakdown of the points each game received.

1. Opposite Islands by ippa: 34 points (10 + 7 + 7 + 5 + 5)
2. Cheese Master by elcugo: 28 points (10 + 7 + 4 + 4 + 3)
3. Mizutoka by jlnr: 24 points (10 + 5 + 5 + 2 + 2)
4. DungeonFarmer by Yahivin: 23 points (10 + 10 + 2 + 1 + 0*)
5. Cyber Deathmatch by Venut: 19 points (5 + 4 + 4 + 3 + 3)
6. Solunaria by jacius: 19 points (7 + 7 + 3 + 1 + 1)
7. Playground Wars by kiba and qubodup: 12 points (4 + 3 + 2 + 2 + 1)

* 0 = the voter did not rank the game at all

See you next time!

Just a few minutes ago I finished MacOSX port of Battle Tanks. Proofpic:

The second day of development is all focused on getting the movement code for the player right.

So I spent much of my morning hours writing movement code and rotation code, although I still have to take care of fixing crash bugs because I forgot to include a few files in the mapeditor program.

The rotation code is pretty much complete. You can rotate counterclockwise and clockwise as well stop. The movement code, is on the other hand, have incomplete physics. Although you will go faster with accelerating and then you will continue to move even after you stop, it doesn't take into account the angle of movement.

This will be rectified the next day, I am sure.

5 more days to go!

Uzebox is a retro and minimal game console, which supposedly will have an open architecture, driver and game soon. It is built for NES controllers and it's driver is written for NTSC. Take a look at this video to witness it's capabilities!

It's now possible to play PURITY with pre-compiled maps! See this thread for instructions. Currently there is half a dozen of maps, on which you can roll around and figure out what the different attacks do. I found experimenting with the weapons very interesting and already developed some techniques for "get as fast as possible from this part of the map to that other part of the map."

Also, if you're into minimalistic art, you'll find PURITY to be a tool for creating some sexy screenshots. Hm... three dee canvas...

Radakan's team decided to use the Creative Commons Attribution-ShareAlike license for all of it's content. What joy! I'm still waiting for WorldTool's next release. Impatiently.

I just red that Nosslak, who contributed to OpenFrag before, offered his skill to the Radakan project. His motivation seems to be the slow progression of OpenFrag.

Did you know you can learn to create a game showing a picture of cheese in under five minutes? It's true! True, I tell you!

Also, I'm trying to create a snake-like game in Lua. I've been thinking about the concept in the last four days, but I have some kind of mental blockade which keeps me from sitting down and keep on writing these less than a hundred lines of code.

PS: Commander Stalin is a Bos Wars-based RTS with a ww2 theme. The music in the game is screaming "copyright infringement" - I wonder about the artwork.

KRPGE is finished in two days! That was quick. Then, I started work on the development of SpaceFighterAce.

First, I had to import svn into git before I can push it, which took me about an hour to figure it out. Then I pushed it to github and use the newly released KRPGE for this project.

At last, I spent time coding and finding graphic for the game. I decided to use a NASA picture as terrain.

This game is going to be awesome!

KRPGE-0.0.3 is out!

This release now support terrains. It also got a bit of code cleanup too.

As for the map editor, the README documentation for it was improved. It also got FPS boost.

A long time ago, I written a tutorial series on rubygame, in which I written part 1 and part 2 respectively as some of my earliest article here at this blog. This tutorial series became a great hit for people googling for rubygame tutorials, which seem to happen quite often. Unfortunately, it has become outdated and it no longer reflect the knowledge and experiences that I gained since then.

But recently, the tutorial series is being rebooted at a new site with a new name, The Rubygame Book. It is completed with all new content and is licensed under Creative Common Attribution(Someday, I will probably license it under a more copyleft license).

I already completed part 1 and part 2 and more to come. In the mean time please give them a read and tell me what you think!

Also, please vote for this post on FSDaily!

Though I didn't do game development in the morning as I usually do, I still managed to do 4 hours of development.

The main objective for KRPGE 0.0.3 was achieved surprisingly fast and with a few improvement and slight modification over Playground Wars's code. Terrain support, though it suprisngly requires more code than I expected, was completed in the span of two hours. Huzzah!

I also began work on eliminating the redundancy found in EditEngine and GameEngine found in the KRPGE's two program as a neccessary unplanned project along the way to the secondary objective, which is to clean up the Camera's redundant codebase.

Than I began work on the camera itself, writing a method that can be used in all 4 directions and then getting the horzontial movement methods to use the new all purpose method.


Today is fantastic.

7 more days until I achevie my goal!

These are a solution for not generating town blocks (street, houses) where a given geography part is not suitable for that. I've added some nice architecture for this: Economics (streets, houses, bridges) can provide a list of Checkers which are used upon generating the town structure in the AbstractInfrastructure class. The Population type also provides a list of checkers that should be scanning the geography at the creation of the Population at the given geography. Those results are stored and upon generating a given size level for the population the unavailable blocks for the given checker types of the Economic are checked and so it wont generate the Economic to unsuitable blocks. Now Rivers and Ocean is no longer overwritten by Residences and EconomicGrounds. But the nice is that Bridges will be able to be built upon the water - later, when we'll have them. :D

Now only a few other bugs till the release...

The next version of KRPGE is out!

Version 0.0.2 features a map editor. It even come with more documentation than the engine itself.

You can download it here.

Well, I finished MapEditor's rendering bug and made it ready to be released. For that, I spent 1 hours getting nowhere and the finishing it relatively quickly the next hour after being confused for 10 minutes.

Since I have nothing to do, I decided to work on my tutorial. I completed part 1 and even managed to start working on part 2.

Tommorow, I will start work on KRPGE 0.0.3. For now, I must release my mapeditor in the form of KRPGE 0.0.2

I finally managed to compile and play Be The Wumpus (using the CVS version). I had some trouble finding out how the controls work, but then found out that you don't turn in 90-degree steps and that you have to attack (space) to make the humans squeak in fear. I immediately started hunting down and consuming those two-legged pieces of meat.

I am amazed by how this game appeals to your hunting instincts. It's also a game which will give you a break from ruining your eyes, as keeping them closed while playing makes it easier (and more fun). Now I just have to wait untill it's night, so I can go hunting at full darkness!

I tried playing Orbit-Hopper, but it appears that my outdated GeForce 5200 isn't enough. Which is a shame, I'd love to try a pretty and improved version of Skyroads. And Orbit-Hopper is supposed to be just that. It even has split-screen support and a level editor and I imagine both might be impressive.

Bughunter2 and Tranberry are working on Burning Dust, which will become a 2D RTS engine and then a game, using Hard Vacuum graphics. There's also a game design/brain storm document in the works.

Project Alexandria is a 2D gravity arcade space shooter containing some plot. I find the gravity part somewhat hard, but the overall game rather entertaining.

Justinnichol's sci-fi art, fonts and drawings are available under the Creative Commons Attribution license.

PURITY is a minimalistic ioq3-based shooter and looks very interesting to me [video]. I was unable to try it, as there are no GNU/Linux binaries and the required GTKRadiant is not easy to compile.

A very resourceful discussion on managing free game projects was started by Brendan on the Dungeon Hack forums.

He explains that the most important rules for a game developing community are:

• Showing off progress
• Being nice and friendly
• Using shared code & content repositories
• Documenting code

It also appears that Anna Kournikova is the biggest enemy of volunteer game projects because she will start dating your best coder, making him unavailable for the project.

Since I have started giving reading recommendations: this blog will knock your socks off! It's a news blog for the being-developed, non-free* MMO game "love".

You will be either impressed by the fresh ideas or by how nifty the author introduces his views, so that you are tricked into thinking he is so right, which at the same time makes you love his game, as it's design follows his views.

*I'm talking about this kind of free by the way.

Vote for your favorite games before it’s too late!

Rank the games according to your favorites, then send me a forum PM or email! Voting closes tonight, August 1 at 23:59 UTC!

See the voting forum thread for details and a list of the entries.

We got Solar Eclipse right now here in Russia, Novosibirsk.

Today, I finished both the map stamping option scroller and the editing system as well. So you can edit maps and cycle through the options that you want to stamp.

The only thing left is writing messages for the logger and fixing typing rendering bug, as well writing the README for the map editor.

It will be released as KRPGE-0.0.2 instead of a standalone application. After that, I'll be working on the next version of KRPGE, incorporating any useful stuff leftover from the playground project.

9 more days left! :D

Here we go again! :) WoodenHouse class is born to add some variety...you'll be able to spot a boarmen town based on the rooftype. :P Now only a bunch of things to fix on the to do list and we'll bombard you with the heavy weight release...

Welcome to the second issue of the FIFE community spotlight series :-)

The purpose of the community spotlight series

The idea behind these community spotlight articles is to have a closer look at the projects which are utilizing FIFE for their games. There are still just a small number of early adopters at the moment so we might not see more than 2-3 community updates per year.

Community newsflash

Zero-Projekt, the game that was featured in our first community spotlight issue still makes good progress and they're currently working on a first public playable demo. As announcing any release dates creates quite some pressure and they're a hobbyist team, I won't spoil the surprise and simply let them finish the demo and announce it when it's done :-)

There are unfortunately some bad news to report as well :-/ The FIFE-based projects Keys of Naand and TK-Remix seem to be on halt at the moment. TK-Remix was officially abandoned by its author AKIRA_SAN and he would appreciate if anyone would pick the up the project again. Code and assets can be found in the TK-Remix SVN repository.

The latest commit in Keys of Naand's SVN repository happened over three months ago so it looks like the project is on ice at the moment. If anyone wants to help the KoN team out of misery, grab their files from SVN and consider to either get in contact with the original team to join team or even take over the project.

Fortunately there is at least one new promising FIFE-based project in the works now: OpenAnno. And this community spotlight issue is dedicated to this very project :-)

What is OpenAnno?

A quick and dirty copy and paste from their mission statement: "The OpenAnno project aims at creating a free and open source realtime economy simulation with strategy elements in an isometric 2D engine loosely oriented towards Sunflower's Anno series."

Sunflower's Anno series is still pretty popular in Germany as well as in a few other European countries while it seems to be rather unknown outside of the Europe. Most inspiration is prolly drawn from the first part of the series: Anno1602, which was released as 1602 A.D. in the United States and Canada.

History of the project

• 2005: project was founded and a first version written in C was in the works.
• 2006: new team takes the project over and starts from the scratch with C++.
• End of 2007: playing around with Ogre and plans to work on a 3d version of OpenAnno.
• Beginning of 2008: decision to switch to FIFE and write the game in Python.
• July 2008: SVN commit #1000 and first internal milestone OA 2008.0 completed.

Key gameplay elements

• Urban development
• Commodities managment
• Trading goods
• Exploration
• Diplomacy
• Strategic realtime combat

How OpenAnno utilizes FIFE

The OpenAnno team utilizes FIFE as engine for their game but they're adding functionality on top of the engine that is currently not supported by FIFE itself:

• An sqlite database for storing gamedata instead of using FIFE's XML-based file formats.
• Custom pathfinding implementation written in Python.
• GenericRenderer plugin to draw geometric shapes. The author of the code spq has joined FIFE development and brought this code into FIFE as well so every FIFE-based game got access to it now.
• Selecting and grouping multiple units and hotkey access to these groups. Again code was contributed from OpenAnno back to FIFE to give everyone access to this feature.
• Modified editor tool to load maps from and save them back to the sqlite database.

The team behind the project

These developers are currently working on OpenAnno (sorted in alphabetic order):

Project management

• LinuxDonald

Programmers

• JanMalte
• Lynxis
• Nihathrael
• phiker
• spq
• totycro
• Yonibear

Gameplay designers

• Andre_Re
• dauerflucher

Graphics artists

• dauerflucher
• egore

Content designers

• GreyGhost

Screenshots

• Tent render
• Early ingame screenshot after switching to FIFE
• Main menu
• Revision 945 ingame
• Latest revision ingame

Dusmania 10

The OpenAnno team took part in the German independent game developer meeting Dusmania 10, which took place two weekends ago near Frankfurt am Main. They held a short representation about the project and showed the game to a bigger audience for the first time. Looks like the Dusmania people liked what they saw and OpenAnno scored a good second place, only beaten by the open source Ultima Online 3d client Iris2. Congratulations to the OpenAnno team!

They actually took some photos of the event and you can see Lynxis, yonibear, phiker, nihathrael and spq (from left to right) with their trophy.

Help wanted

The OpenAnno team is still looking for help so if you've got experience in the following fields and would like to support them, just hop into their IRC channel or get in contact with them at their forums:

• Programmers: experience with either Python, C++ or sql databases.
• Graphics artists: experience with Blender or similar 3d modeling software, GIMP, Inkscape or ImageMagick. Some knowledge of history is quite useful to catch the visual style of the portrayed historic era.
• Gameplay designers: being creative, coming up innovative and unconvential ideas. Good communication skills to mediate those ideas to others and the ambitions to write them down.

If you think you could lend them a hand, don't hesitate to get in contact with them!

More information

That's it from my side for today. See you at the next FIFE blog update, prolly coming to you at Sunday when we'll present you a list of possible new names and acronym meanings for the project :-)

As my Latin exams are coming up, I plan to take another semi-break from FIFE until I've hopefully passed them. But remember: I'll be back!

Posted in: openanno, spotlight, community

It is now possible to delete stuff in your mapeditor! It took me a good two hours to code out the functionality and then debug and fix it. Along the way, I made an improvement to the map engine's camera. You can save it and then reload it to see if it work.

I also learned that integers are immutable. Bumber!

Then the rest of my time are spent on figuring a way to display these characters and items graphics on the object chooser so I can get started on adding support for modifying the map. They don't work quite the same way as the map engine do. By the end of my 4 hours effort, I think I was quite close to finishing the mechanism for drawing these images.

Slowly but surely, I’m working towards Rubygame 2.4.

As a reminder, 2.4 is going to be about events. In particular, a new Events module with a suite of SDL-based event classes to replace the old event classes.

The reason for this is to clean up the API; all the events are tucked away in their own cozy little module instead of cluttering up the Rubygame namespace, and they’ve got nicer class names. The documentation and code are also nice and clean, and all the event classes are thoroughly specced. The class interfaces are also more tightly controlled, for example freezing attributes to prevent modification.

The new event classes also do away with the massive list of integer constants (K_ESCAPE, MOUSE_BUTTON_LEFT, etc.) that were cluttering up the code. Instead, they use symbols for key names, mouse buttons, etc. This also makes the code you write a lot nicer to read.

Another nice improvement is that the KeyPressed event now has an attribute with a Unicode string containing the glyph (if any) that was generated by the keypress. This is very nice for text input, for example if you’re programming a GUI.

All the new event classes are finished, written in Ruby. I’m currently implementing the C-side event conversion. The code is much cleaner and nicer to read this time around, let me tell you! (One would hope so, given the years of extra C experience I have under by belt.) After the new classes are in place, I’ll mark the old event classes as deprecated; they’ll be removed entirely in Rubygame 3.

The new event classes are only half of 2.4, though. The other half is the new hook-based event handler system, including the much-anticipated “magic hooks”. The code for that stuff has been complete for a while, but it still needs to be cleaned up, documented, and specced. Once that rolls out, you can kiss your huge case-when blocks goodbye, my friends.

Given how often and suddenly I get swamped with work, predicting a release date for 2.4 is futile. But, I’d say it would take only 3 or 4 more afternoon/evening sessions to get it polished off. Whether that will take a week or two months is impossible to say.

In order to keep the development of various projects from stagnating for a long period of time as well having a fresh release every so often, I devised a roadmap at the KibaBase wiki to follow.

The roadmap assumed that 28 hours are needed to complete each projects' goal. Thus a week is needed to achieve these goals, which is intentionally chosen for the purpose of having a release every week. Also it alternate between game tool development and game development to balance the need to create games and the need to create tools that will help create games.

This will hopefully achevie a sense of direction and progress as well keep me focused on what I need to do in order to achevie the goal of self employment by writing free games.

Walls and such have been replaced by Zphr's models. The roof is still the old, because that's the hardest part to replace - it has some 3 different models in the old version which should be carefully replaced later. :)

I kept getting interrupted by my parents for task that they want me to get done. This mean I had to restart the hour I am in before it is an hour to me for sure. Nonetheless, I managed to get the 4 hours done and lot of commits in.

Here is the stuff that I accomplished and work on:

The typing system work now and you can use it to save your file. It even send a message to LoggerUI about the fact that the file has been written to disk.

The object of choice you want to stamp are now displayed. You can even change the object that you want to stamp. I still need to add support for characters and items though.

While August may be synonymous with “vacation” in many parts of the world, in my particular academic discipline, August is currently one of a number of months synonymous with “conference submission deadlines” (my field of computer architecture being one in which conferences, rather than journals, are the primary paper targets).

As some of you may have noticed, I’ve been (mostly) incommunicado for the last few weeks, and I’ll continue to be out for at least the next couple of weeks (until after the HPCA deadline). However, if anyone does need to reach me, I’m still checking my VS-related e-mail, just not keeping up on forums at the moment.

Graduate school has been particularly demanding of my time in 2008 (thesis proposal and related prep taking up much of the first quarter of the year, and then much of the next several months trying to make up time lost working on the proposal rather than paper-oriented research :-P), but, with any luck, I’ll both have some new publications to show for it in the not too horribly distant future, and some breathing room in which to commit larger time blocks to VS. With luck or without, there are no deadlines in September, so I’ll at least be much more involved than in August :).

For those of you who get to take some time off - enjoy yourselves

For those of you poor fellows who’re  slaving away at conference deadlines - if you hurry, you can still make ASPLOS instead of HPCA ;-).

The RubyWeekend #2 contest period is over, and now it’s time to vote for the winners!

We had seven official entries this time:

• Mizutoka by jlnr
• Cyber Deathmatch by Venut
• Playground Wars by kiba and qubodup
• Opposite Islands by ippa
• DungeonFarmer by Yahivin
• Solunaria by jacius
• Cheese Master by elcugo

We also had a late entry, which you are encouraged to play (even though you can’t vote for it):

• Super StarHawks Gaiden by misspledd

Check out the entries thread for info, screenshots, and downloads, then rank and vote for your favorites!

Early Monday. Pioneer rays of light touched my face like golden hair. It was then that the second Ruby weekend game programming competition came to an end.

The results are not impressive, but much more than I had anticipated. The previous Rubyweekend took place only 1.5 months ago, and the weather motivates to spend time outside the reach of game-creation-suitable input devices. Also my humble opinion is that the topic "opposites" was way too liberal.

Many games weren't finished, though are playable to some degree. Two of the submitted games had incorrect-case directories/filenames!!!! /me rages !!!!11!! Well, let's blame the weather, shall we? :D

Me and kiba wanted to create a simple rts called Playground Wars and we failed. No problem, lesson learned (don't try to make an rts in little time.) No regrets but if I'm to participate in a game creation compo this summer again, I will work for it at night so I can sleep in the sun at daytime!

I like Opposite Islands [video]. Here are all the games. You can take a look at the videos of the other contesting games. You can vote too.

DungeonFarmer is pretty freaky because it has to do with farming in a dungeon! O_o Super StarHawks Gaiden is awesomely neo-retro [video], but was submitted too late. o_O

Regarding other short-time game programming challenges: The next Ludum Dare will happen in 2 weeks and 2 days. It's more than a month until PyWeek #7.

I can't find any official PyDay site any more :(

In other news: I recorded another video of TORCS (slightly better synchronized), after finding out that there is at least one map that looks rather pretty (by my standards.)

Blood Frontier recently started interesting me very much, because it is fun to play. It has great maps and a fine, small weapon selection and it's movement style is definitely something fresh. Give the new alpha a try, it's worth it! [video] The fact that most maps are not just very, but too dark, is something I consider a problem for deathmatch games.

I'm currently reading Learn to Program, it teaches via Ruby. I like it because it takes me by the hand without making me feel stupid. Next up will be the Lua Reference Manual. When I'm done with that, hopefully Python 3000 will be ready for use and learning.

I just checked if I covered in this post everything I have to share and realized that this is about 10%. Next post soon I guess.

Check the screenshot, it tells the story! :) Soon, I'll add more parts of the already complete town model set done by Zphr. Texture blended with alphamasks is working now. So the town, steep mountain sides and climate edges look way cooler now. :)

Here is my postmortem for Playground Wars for the RubyWeekend #2 contest. I hope it will be useful for future RubyWeekend newbies and veterans alike as well present day RubyWeekend pioneers.

What went right:

1. Getting an art partner is a very smart choice, especially if he/she is good. Qubodup is good and he free up my time so I can program. Division of labors kick butt!

2. Prior to the contest, I spent at least 30 hours on the KRPGE engine for the purpose of writing RPG games. Nonetheless, it was quite adaptable to RTS format. Plus, most of the map stuff has been done for me. I had to modify it so it can support terrain images. This free up my time to work on gameplay features. Code reuse ROCK!

What went wrong:

1. Choosing the wrong ideas can be fatal, even if the idea is a good idea. It need to be implementable in a short period of time. I think the lesson is clear here: DO NOT! I REPEAT! DO NOT attempt RTS games in a 48 hours contest. There is no way you're going to implement all the units, the tech tree, the whole 9 yards of features and test, blanace them all, let alone a stripped down RTS game.

2. Do not jeapodrize your contest entry with a bad sleep schelude. 4 hours of sleep each is not enough. Please make sure you get plenty of sleep before the contest start. It might not hurt(Actually it probably does) but you need every bit of energy and focus you can get. I was very tired so I stop coding several hours before the contest end.

3. Communication is hard. Time and time again, I learned that the communication of ideas is rather faulty. For example, Qubodup told me about a bug and I didn't realize what the bug is about after the contest. Qubodup and I had to explain our ideas to each other repeatly or correct misinformation each other have. For example, I didn't realize that Qubodup was asking about the whole map resolution, not the indiviual resolution of map terrain images.

What I Would Do Differently:

1. Write more engine code. Having more code that you can use to create games is a good thing, as well let you focus on writing games instead of writing an engine.

2. Complete the map editor or any other tools that you will need first. It does you no good to have a very difficult map to edit when you got better things to do.

3. Try to choose a less amibitious game so you can actually complete it and have a better chance of rocking everyone's boat.

General Thought About the Compos:

We need a RubyWeekend site, seriously. And advertising. Lot more advertising. We advertise quite a bit more this time around, but apparently that is not enough. We got the same amount of entries as last time(7 of them).

That is all.

I am out!

For Day 18, I divided my effort among several features of the mapeditor.

First, I worked on displaying the map. Then I wrote the code that eliminate drawing the majority of maps on the object, making sure that it only got drawn on the proportion of the screen. This has lead to engine code cleanup.

Next, I worked on integrating the map stamp into the engine's camera. There I have to fix a few bugs relating to the synchronization of the objects. I also have to write code for objects that does not inherit the Character class so that the map stamp can work.

Lastly, I worked on implementing the frame rate for debugging and performance analysis purpose.

12 more days to go than my 4 hours experiment will be completed.

Today, I resume my work on the mapeditor part of my KRPGE framework.

It now load the map for editing and the editing stamp has been implemented.
Beyond that, I reused the engine code in preparation for display. There is some cleanup work on LoggerUI and the EditMode class.

That conclude Day 17 of the productivity experiment.

I expect to display the maps for tomorrow and start implementing the editing system.

Hi, you can download Qubodup and me's RubyWeekend contest entry from the Kibabase wiki.

It is a very incomplete first version of the Playground Wars real time strategy game. I gave up finishing the game for the contest, but I submitted it nonetheless.

Description: The opposite sexes has decided to go to war over the ownership of the playground!

I gave up.

Apparently, I couldn't achieve what I did last time. This contest is a major disappointment for me.

There is probably a lot of reason why I couldn't finish it. Lack of sleep, lack of willpower, too ambitious, etc.

Whatever the case, qubodup and I are too crazy. Maybe someday, I'll be able to code a whole RTS game within 48 hours.

At this point, I am just an angry programmer. I don't want to code more.

Now, I am almost finished with the resupply mechanism. I just got a few bug to iron out. Once that's done, it is also done for the girl resupply units as well. I will be adding the resupply girl unit after this.

Today is the last day and I still haven't finished all the gameplay work, never mind pathfinding, AI, state of being, etc. And I got about 12 hours left to finish this game. I think it is time to PANIC!(Code frantically)

With a mindslicing TerrainBlock tricky extension the tiles are now using the normals as if it were a big normal TerrainBlock, not several ones - one per ground tile exactly.

In our cube based architecture the tiles have to be generated one by one, so normals were missing from the ground tiles because the separated TerrainBlock meshes cannot calculate with the vertex positions of the neighbouring tiles. Now the trick is - use the full RenderedArea's cube elements to get neighbor opposite/adjacent Cube's already present height data, create a one size bigger (9 points 3x3) heightmap and build vertices/normals from that heightmap for the original 4 cornered (2x2) heightmap's normal buffer. Uh, crazy to write down, but it's working. The shot shows how gooood. :) And it's not slow either luckily! :)

I got point and click system almost done. It is just that it needs to notify the player whether if someone is selected or not. I am working on providing that indicator.

I also worked quite a bit on the energy system and the resupply game mechanic that goes with it. The SupplyBoy just needs to know how to retrieve energy source and then deliver it to the intended destination.

Qubodup worked to get all the units done as well upgrade the map. He is currently working on adding the state of units(KO and asleep).

Qubodup finished his terrain map. It got too much water though. I also have to fix rendering and camera issue with my map engine.

Meanwhile, I finished moving around the map with the mouse functionality. It can even invoke a character to respond to the mouse click.

Now, I am working on point and click s