Case Study: TCG in React

I work on projects through a process where I am constantly tearing down walls, but I leave talking about it to the hypothetical "finished point". That's a mistake.

I'm currently working on two projects, Lanarts and a game I will tentatively call Ciribots, a card game. I have talked enough about Lanarts for now, let's talk some about Ciribots. I'm still lagging on open sourcing it, but that's as much due to shy privacy as any vague hopes of monetization.

"Ciribots" new prototype, with animated React glory.

Work on Ciribots currently falls under 3 categories:

• Initial game design: While I've been mulling over the rules of the game for a long time now as the game was played in paper play. Currently the firmly decided rules are, roughly:
• Cards make or interact with pieces on the board.
• Pieces move like chess queens, but only up the their movement value in squares away.
• Pieces can attack whoever a queen could attack, up their range value in squares away. Pieces don't move to the enemy square ever, unlike chess.
• Cards have a health value that resets each turn. It must be brought to 0 in a single turn for the unit to die.
• You must move a unit to one of the two centre squares on the other side of the board to win.
• You can move with 2 distinct units in a turn. All units have energy to do one action each turn (like MTG tapping), which is used to attack, deal damage back when attacked, or to do a special action printed on the card. 
• Board game engine that lends to easy card changes: This is probably the most interesting part of the implementation too me, although also a part I wish could be magically written. Writing in C++ for performance, compiling with emscripten for use on front end. The board game engine is the backbone of the rules enforcement, and also any AI players. It is being written with both absolute performance (e.g. roll back states in AI to avoid any full state copies, keep exactly one state object) and extensibiliy (incorporate any new cards) in mind. It's my favourite kind of tricky challenge - designing a performant system that might be extended to do *anything*.
• UI in React: The game is a react app. I'm on the JSX bandwagon. Probably to the point that I'm not really interested in non-React front end stuff. Too many goodies for language nerds like me with TypeScript+React being both static and declarative. My most recent rewrite in React-as-of-May-2018 focused on using CSS animations + React animations, which mostly work amazingly other than some jankiness. 

And this I shall publish, because I have to remember partial results are worthy to talk about.

-Adam

Lanarts Update October 15th, 2017

Download here!

Boy has it been a long time since I released. Releasing can be a very hard mindset - Lanarts always has some features that are more experimental than they should be. My friend Pat reminded me how sorely needed Lanarts releases are, so here goes (the last time I regularly released was in 2012!).

Greatly improved random world generation:

As I alluded in my last Lanarts development blog (it wasn't even a release), a major addition a while back was the random generation of the overworld that connects dungeons. This has been greatly enhanced to the point that the map has arguably more interesting features than when the map was hand-made. Notably, as with other rogue-likes such as Dungeon Crawl Stone Soup, hand-designed 'vaults' can be blended into otherwise procedurally generated rooms. In addition, many additional dungeons and bosses have been added to the game.

Lives mode:

Non-hardcore mode now has 100 lives per player, shared by all players in a lives pool. This makes death still relevant - you want to save the players who keep dying - but make the game feel much lower stakes, as a casual mode should. A previous iteration had the game only end when everyone died. This was exciting - however, it discouraged everyone working together. 

Split screen:

Play with a controller plugged in and automatically play with your friends! Currently the only way to set the classes of other players is by setting the L2, L3, etc environment variables, eg L2="White Mage". If you want the first player to play with a controller, use LANARTS_CONTROLLER=1. I understand this is a brutal interface, more work to follow!

Pixel lock is banished:
Pixel lock was the name given to a 'feature' of Lanarts where, due to enemies being considered solid objects, and the 'pushing' mechanism that the game provides you being quite limited, that some times you would get completely stuck and have to fight your way out. This created some of the tensest moments in the game - a seasoned player would fear corners greatly. However, it greatly limited design space! Suddenly the biggest worry about a group of enemies was not their combat power, but the fact that they would physically pin you as a fundamental part of the game. Now, you simply move half speed through enemies. The resulting game play feels intuitive, you don't notice the weird aspects of pushing enemies anymore, and there is much more room for big groups of enemies.

New game advancement structure:

Key items that unlock areas is a major theme going forward. Currently in the game, you must first get a blue key, then a yellow key, and then three 'Lanart's to progress through the game. Lanarts (which obviously exist to give the game's name a concrete reference) are currently objects with no effect other than being collectable, and found in major areas / when bosses die. Collect 3 lanarts, enter the final area, beat the final boss Pixulloch, and you win the game.

Missteps and not-missteps:
Why does Lanarts take so long to make? First and foremost, Lanarts is a learning project. I'm really not afraid to take my time and make mistakes. However, I should take more time to talk about my mistakes.

One mistake was trying to rewrite Lanarts in a new engine. I learned a lot about MOAI, hacked a lot to make it work how I wanted it to, but at the end of the day questioned whether I was really better off using a large engine that I don't understand. This isn't to say using MOAI wouldn't have immense benefit - but rewriting is such a costly task that you better be getting serious metaphorical cash for your endeavour. I saw potential but a lot of hard work ahead.

Now let's get into something I did right - the most crucial thing I did for Lanarts development I believe was to abandon the MOAI version. The key insight was that I started afresh with the MOAI version and did some really cool things because I had a fresh slate - but that didn't mean I couldn't do those things in the old code base! So, while the previous development blog promised a procedural overworld and a new stat system, these features were actually tied to what was essentially a mock-up of Lanarts.

Porting over the procedural overworld was a very important task - especially for my motivation. Before, my most exciting feature (greatly more sophisticated world/level generation) was tied with a version of my code that needed monumental work. When I ported over the code, I gained a newfound appreciation for my old code and I felt like working with it was well worth it. Some rounds of cleanup later and, while not ideal, I am very satisfied with the state of things. I can truly do a lot of things really nicely.

What about the stat system which I was excited about last blog? Turns out I was thinking about stat systems all wrong. When you see a stat system with a lot of distinctions, it can be exciting - but only as exciting as those distinctions actually mean in gameplay. One thing I've learned about Lanarts is that it doesn't work well as a subtle game. Stats need to be very clear in their impact. As such, I took a key component of the stat reformulation - damage types, and kept only that. To increase the clarity of damage types it was important to simplify the stat system. Now in Lanarts you have to worry about your power, which adds 5% of your base damage for every point, and their resistance, which subtracts 5% of base damage for every point, and what types are relevant. Previously, stats would also interact with your base damage and complex solutions were used to avoid degenerate cases. Overall a big win, and that leads me into my other feature.

Damage types, new classes:

Play as the Red Mage with strong spells of fire or the White Mage with lightning power! Necromancers largely pay with their own life for their devastating magic, and summon shadow creatures to aid them. Use ultimate spells to clear out large areas.

One-file C++ Utilties

Summary:

Here I show off self-contained utilties I have accumulated for C++ over time. Included are small functions for:

1. Directory manipulation and searching
2. Creating a timer
3. Simple performance stats
4. Printing the type of an object.
5. printf-like string manipulation

The name is slightly dishonest, but few-file C++ utilities didn't have the same ring.

Overview:

While working on lanarts I frequently had to write code that was simply an #ifdef between UNIX land and Windows land. I made sure to minimize the amount of #ifdef's inside the actual game engine, pushing it into small C++ classes or one-file modules

Time has passed and they have remained useful to me; I publish them here for anyone to use. I figure stand-alone C++ utilities, where you can simply paste one or two small files into your code are worth releasing. You can incorporate them into namespaces if the need is felt; I usually go global for convenience.

Note 1: If you find yourself hungering endlessly for classes like these, I heartily recommend Boost. Personally though, I like to make due if I can with smaller dependencies.

Note 2: Most of these are from C++03 usage, so if there's a better way to do it in C++11 I may have missed it.

1. Simple directory access

directory.h
directory.cpp

It uses tinydir.h:

tinydir.h

This works on Linux/Mac/UNIX-like systems and Windows.

Don't expect much options here, but it is quite complete. 'search_directory' provides recursive directory searching, retrieving a filename list. The name pattern takes wildcards.

'ensure_directory' can create a directory if one does not already exist, returning false on failure.

See the header file for details.

2. Simple timer utility

Timer.cpp
Timer.h

Ever messed about trying to have a simple timing class in C++?
This one relies on using gettimeofday on Linux/Mac/UNIX-like systems, and emulating it on Windows. The Windows code was from Stack Overflow.

Provides these member functions:

Timer():
   Sets a timer, get_microseconds() == 0 at this point.
void start():
   Resets a timer, makes get_microseconds() == 0 again
unsigned long get_microseconds():
   Time in microseconds, multiply by 10e-6 to get seconds. May want to change signature to 'long long' by editing the source.

Example usage:

Timer timer;
... stuff occurs ...
cout << "Seconds have passed: " << timer.get_microseconds() * 1e-6;


3. Simple performance stats

PerfTimer.h
PerfTimer.cpp
perf_timer.h

Simply, PerfTimer uses the above Timer class to create timers suitable for use with long-running methods (a map to the type name is used for convenience, but isn't super-fast).

Example usage:

Simply include perf_timer.h, and have:
PERF_TIMER();

at the start of your function. It will record simple statistics such as average time, max, standard deviation, etc.

Then, when you want to see the results, simply run:

perf_print_results();

And you will get fairly nicely formatted results. The advantage is this approach is enough to see obvious bottlenecks (ie, this function is taking 75% of the time) and does not require the use of external tools. 

Example Output:

func bool analyzer_follow_entity(AnalysisState&, int, double):
        >> total 3797.9561ms
        calls 2801
        average 1.3559ms
        max 23.2120ms
        std.dev +-1.8125ms, +-133.67%

4. Simple typename printing utility
typename.h
typename.cpp

Useful for templated functions, when you want to pretty-print an object's type. Note that proper use of a debugger may or may not be more appropriate; littering print statements still has its place, though.

Example usage:

template <typename T>
void my_template(const T& obj) {
       cout << "got object of type: " << cpp_type_name_no_namespace(obj);
}

5. 'sprintf' into an std::string

strformat.h
strformat.cpp

This provides a global function called 'format' (again, edit to your needs!) that takes printf-style arguments and returns an std::string. To me, this clears a pain-point where I prefer printf-style syntax for output, but cannot use it to make temporary strings in output functions.

Note that the code is not designed for efficiency for strings > 512 bytes, but it does guarantee correctness.

Example usage:

std::string my_str = format("(%d, %d)", 1, 2); // -> Goes to "(1, 2)"


What else?

I have a Lua wrapping library (C++03 compatible) very similar to luabind but with no dependencies, and quite small size. It may be worth talking about in a follow-up.

A Parameterized Attack on Programming

2018 EDIT: One of those posts you look back on and wonder what you were thinking. I think I know?

I will be frank; I don't like the programming language L. If I could stop people from using it directly I would, forcing them to first formulate their problem in a better language.

Practitioners are subtly but profoundly swayed to take shortcuts with correctness because of a lack of simple or idiomatic expression in L -- after which, of course, they are encouraged to compromise performance for some measure of the correctness gained back. Double-of-course -- correctness is everything!

Truthfully, there is little wrong with L, but more the culture surrounding it. By refusing to use anything but L, a mono-culture forms, and L is forced to handle more and more concept mappings that bring L to the very limits of (and, sometimes, off the charts of) its intended cost/benefit trade-off.

The economic viability of programming has given it a very dense and awe-inspiring history -- but correct language is essential -- all industries are doing what will inevitably be called 'early programming'.

Consider the culture of programming as a whole:

Money drives programming hours in a series of chaotic directions. Man-millenia become spent on redundant interfaces to obsolete versions of redundant programs by obsolete and redundant companies. Those observing these practices identify similar but frustratingly hard to generalize flaws over and over. It is discouragingly hard to incrementally improve something for which your system has no intelligence.

And of course, why bother with thinking about a gradual path of improvement when you face costly ad-hoc reformulation, creeping obsolescence, changing requirements, no market demand, et al staring at you. You can almost feel the boulder rolling back as you reach to push it up the hill. Individuals in these situations sometimes find solace in the delusion that since they are avoiding changes they are avoiding the problem of programming -- only to be pulled back in for one last 'hit' by the winds of change. And this describes our dense landscape of opportunity, where history is not only doomed to repeat itself but to synchronize at many points as industries struggle to solve problems in excitingly identical ways.

And that's precisely what's wrong with the programming language L, and it has almost nothing to do with the programming language L.

When our most fundamental set of tools are thought of, therefore spoken of, therefore implemented as constraints not strictly the minimum of our problem domain, we create (at least slightly) divergent paths of progress. As long as we continue to rely on competing ad-hoc imperative logic models to handle conceptually non-imperative tasks we have literally no hope for normalization (viz Halting Problem).

Only when we leave 'early programming' can the very confused non-software-oriented industries return to business as usual. Producing correct software is a minefield compared to ensuring correct manual labour. Once the designer for even a non-technical discipline can manipulate a set of sufficiently expressive symbols that appeal to their intuition without fear of being forced to reason about arbitrarily-imperative behaviour or any other ad-hoc idiosyncrasies, then we can say we are observing modern programming.

Lanarts, Devblog for Release 13Alpha

I keep wanting to make grand long blogs describing Lanarts development in-depth. That doesn't seem to be working; I'll try shorter blogs.

Lately, there's some exciting stuff happening with Lanarts, and it'd be a shame not to share -- especially because I don't know how long it will take to stabilize all the new features!

Randomly Generated Overworld:

This happened much sooner than I thought! For those of you following, Release 12 introduced an overworld -- however, it was not randomly generated.

I really didn't know how I'd approach the overworld -- connectivity is tricky with non-grid layouts. The approach taken was fairly simple. The algorithm is basically just a bunch of random polygons, and lines connect nearby polygons. I used libxmi to draw the polygons efficiently, and baked it into my map generation library. From there, Lua code controls the map generation, and it it is quite well-performing, even for large maps.

New Stat System:

From a gameplay perspective, this is huge (and criminally overdue). This replaces the previous simplistic stat system (Melee/magic damage types, and resistance/effectiveness/damage/defence for each). Now possible are elemental damage types, bonuses against specific monsters, easily-definable custom status-types, equipment that can grant virtually any ability, etc.

I could probably write a whole blog about the nuances of the stat system, but essentially it was rewritten in clean Lua with many interesting possibilities. The stat system comprises of base stats, and components of these base stats, eg the inventory, result in bonuses to the derived stats. This way eg you can have a spell that is granted only when wielding an item, since it can be added to the derived copy of the stats. This derived copy is computed whenever needed.

Roadmap:Finally, the goals I laid out for Lanarts Release 1.0 have started to take shape. The two issues being tackled by this release plagued me for a long time, and I'm happy to have found elegant solutions to both of them (thanks to the expressiveness of Lua!)

Another, relatively unseen, issue that I have gone a long way to fulfilling is the ad-hoc nature of the Lua API. Recently, a lot of effort has been taken to clean-up and modularize the Lua part of the code. The Lua API continues to become more lower-level and general to take full advantage of Lua's expressiveness.

While development for release 13 is well underway, there is still lots to do. Unfortunately, there is a lot of balancing work ahead with the new stat system, but I have some promising ideas for automating this task.

Feedback:

Please direct any bugs, comments, or inquiries either as a github issue, a comment on this blog, or through IRC or email:

IRC Channel: #lanarts at freenode
Contact Email: domuradical@gmail.com

Feedback very welcome !

Lanarts release 12, now with overworld!

New release, here is the download for Windows!
Source-code for this release: Source

This one was pretty delayed. It's about time I released a version with some of the large recent changes.

READ BEFORE PLAYING:

The game does not provide much instruction (the README is woefully outdated), but your mission currently is to clear the dungeon that has warning skulls near it. You begin near the first of two dungeons.

It is recommended you move with WASD, melee with H, fire spells with YUIOP, mouse controls for everything else. Mouse controls for spells are fairly suboptimal at the moment.

Additionally, 1 to 9 for inventory slots 1 through 9.
Right click is needed to drop items, however.

Screenshots and Changes

Major changes:

• There is now an overworld with multiple dungeons!
• As a result, almost all the areas in the game have been majorly revamped. The red dragon is now on the overworld, a different boss resides in the first dungeon.
• There is now a new logo, courtesy of Kevin Siapno.
• Two new spells - Minor Missile, a mana-conserving Mage spell, and Expedite, an archer spell that causes them to move much faster for a short time. 
• Poison Cloud has been moved from the Mage to the Archer. 
• Magic Blast is now a 3rd-level Mage spell.
• Minimap is much more visible. You can click to adjust zoom level, right click to look around.
• [Code-only] The Lua code has been refactored to be much more modular, and has grown significantly. The area generation code has been rewritten (and improved, in the process) in Lua.

Too many minor changes to list. If curious, you can always check the commit logs.

Special thanks to Matt Simon, Steven Trumble, putterson, and the 2013 Toronto Red Hat interns, for their help testing the game. Thanks as well to Kevin Siapno for the original logo.

Downloads and Discussion

Windows:
Download!

Linux:
Compiling on Linux is very easy!
Download the source here: Source
-or- if you want the very latest updates:
git clone http://github.com/ludamad/lanarts --depth 1

Then from the folder you extracted or cloned to:
./run.sh

This will build and then run the game. If you are missing dependencies on Linux (probably the case) please run either fedora-deps.sh for Fedora, or debian-deps.sh for Debian or Ubuntu.

I do not yet provide linux packages, please do kick me if they'd be useful for you.

Other systems:
The game has been written to be very cross-platform; however it has not yet been tried on Mac or other systems. Anyone willing to help try Lanarts on a different platform is asked graciously to email domuradical@gmail.com.

Feedback:

Please direct any bugs, comments, or inquiries either as a github issue, a comment on this blog, or through IRC or email:

IRC Channel: #lanarts at freenode
Contact Email: domuradical@gmail.com

Feedback very welcome !

A 'fork & exec' surprise

See my gist for a self-contained C++ example of the problem code:
https://gist.github.com/ludamad/5579602

So recently during my work at Red Hat I was looking into an issue with Java on Linux (with IcedTea7+ and Oracle's JDK).

The straight-forward seeming code

FileWriter writer = new FileWriter(someScriptName);
writer.write( ... some contents ...);
writer.close();
giveFileExecPrivileges(someScriptName); // eg, using UnixFilePermissions
Runtime.getRuntime().exec(someScriptName);

This code snippet creates a new text file, sets executable permissions, and then tries to execute it.

This code runs just fine when executed in a single thread. Introduce multiple threads (also running this spawning code) and every-so-often you will get an IOException with the message 'error=26 Text file busy'. This IOException means that Linux is refusing to execute the file because it is open for writing.

However, this is clearly the only place we ever open the file - and we promptly close it. So what's going on ?

An aside about executable text files

On Linux (and originally, UNIX), we can execute a text file by looking up the 'shebang' line, eg at the start of the file:

    #!/bin/bash

This tells the kernel which program to use to execute the file. You get 'text file busy' basically if you try to execute a file that is being written to. Normally this would be a text file (you can get this error with binary files as well, though).

Digging deeper

Unfortunately, you can stare at the Java code endlessly; it won't tell you anything. Luckily, we have OpenJDK. A quick foray into UNIXProcess_md.c shows the native implementation of Java's Runtime#exec method. It is implemented using the system calls 'fork' and 'exec'. (Actually, it uses 'vfork', in OpenJDK7, but it's not important.)

Fork, if you're not familiar, essentially creates a new copy of the process, with enough copy-on-write magic to do it efficiently. Worth noting, this child process gets a copy of all the file descriptors opened by the program.

To spawn the program we actually want, we then use 'exec'. This replaces the current process with the specified executable. However, we continue to inherit whatever file descriptors were already open in the new process.

Don't copy my file descriptors, please

Normal programs will take care that the file descriptors copies are closed upon 'exec'. This prevents unwanted information from leaking. Indeed, this is the case in Java-land, where all open file descriptors are marked with FD_CLOEXEC.

This solves a very important problem -- that file descriptors can leak into the child process. However, this does not prevent the copy from occurring in the first place!

Back to the code

Is this knowledge enough to pose an explanation of what's going on ? In fact, it is.

FileWriter writer = new FileWriter(someScriptName);
writer.write( ... some contents ...);
// Say another thread executes 'Runtime.getRuntime().exec(someOtherScriptName);'
// this forked process will have a copy of the file descriptor we are about to close!
writer.close();
giveFileExecPrivileges(someScriptName); // eg, using UnixFilePermissions
// It is very possible that the forked process has not released the copy here!
Runtime.getRuntime().exec(someScriptName);

Unfortunately, the fork from another thread can copy the file-descriptor, suddenly be set aside to let other threads execute, and the file will remain open!

See my gist for a self contained example: https://gist.github.com/ludamad/5579602

Avoiding problems

So what's the takeaway ? If you're going to fork & exec in a multi-threaded program, you cannot do any operations that require file-descriptors to be closed predictably. This is true even if only one of the threads does the process spawning!

icedtea-web 1.4 Released!

icedtea-web 1.4 is here! Lots of fixes and enhancements in this release. This release also fixes known regressions that occurred from 1.2->1.3.

Release announcement by Jiri Vanek:

Hi all!

After long and furious development, I'm finally proud to announce release of icedtea-web 1.4.

http://icedtea.wildebeest.org/download/source/icedtea-web-1.4.tar.gz
97c1d5f02f9a4ab19812a216f39e401a  icedtea-web-1.4.tar.gz

How we were dealing and what we plan to do, can be  checked on wiki:

http://icedtea.classpath.org/wiki/IcedTea-Web#IcedTea-Web_1.4
http://icedtea.classpath.org/wiki/IcedTea-Web#IcedTea-Web_1.5

New in IcedTea-Web 1.4

* Numerous improvements and enhancements in core and system of classloaders
* Added cs localization
* Added de localization
* Added pl localization
* Splash screen for javaws and plugin
* Better error reporting for plugin via Error-splash-screen
* All IcedTea-Web dialogues are centered to middle of active screen
* Download indicator made compact for more then one jar
* User can select its own JVM via itw-settings and deploy.properties.
* Added extended applets security settings and dialogue
* Security updates
  - CVE-2013-1926, RH916774: Class-loader incorrectly shared for applets with same relative-path.
  - CVE-2013-1927, RH884705: fixed gifar vulnerabilit
  - CVE-2012-3422, RH840592: Potential read from an uninitialized memory location
  - CVE-2012-3423, RH841345: Incorrect handling of not 0-terminated strings
* NetX
  - PR1027: DownloadService is not supported by IcedTea-Web
  - PR725: JNLP applications will prompt for creating desktop shortcuts every time they are run
  - PR1292: Javaws does not resolve versioned jar names with periods correctly
* Plugin
  - PR1106: Buffer overflow in plugin table-
  - PR1166: Embedded JNLP File is not supported in applet tag
  - PR1217: Add command line arguments for plugins
  - PR1189: Icedtea-plugin requires code attribute when using jnlp_href
  - PR1198: JSObject is not passed to javascript correctly
  - PR1260: IcedTea-Web should not rely on GTK
  - PR1157: Applets can hang browser after fatal exception
  - PR580: http://www.horaoficial.cl/ loads improperly
* Common
  - PR1049: Extension jnlp's signed jar with the content of only META-INF/* is considered
  - PR955: regression: SweetHome3D fails to run
  - PR1145: IcedTea-Web can cause ClassCircularityError
  - PR1161: X509VariableTrustManager does not work correctly with OpenJDK7
  - PR822: Applets fail to load if jars have different signers
  - PR1186: System.getProperty("deployment.user.security.trusted.cacerts") is null
  - PR909: The Java applet at http://de.gosupermodel.com/games/wardrobegame.jsp fails
  - PR1299: WebStart doesn't read socket proxy settings from firefox correctly



People who helped with this release (If I forgot somebody, please let me know!):


Deepak Bhole <dbhole@redhat.com>
Danesh Dadachanji <ddadacha@redhat.com>
Adam Domurad <adomurad@redhat.com>
Jana Fabrikova <jfabriko@redhat.co>
Peter Hatina <phatina@redhat.com>
Andrew John Hughes <ahughes@redhat.com>
Matthias Klose <doko@ubuntu.com>
Alexandr Kolouch <skolnag@gmail.com>
Jan Kmetko <jan.kmetko.ml@gmail.com>
Omair Majid <omajid@redhat.com>
Thomas Meyer <thomas@m3y3r.de>
Saad Mohammad <smohammad@redhat.com>
Martin Olsson  <martin@minimum.se>
Pavel Tisnovsky <ptisnov@redhat.com>
Jiri Vanek <jvanek@redhat.com>
Jacob Wisor  <gitne@excite.co.jp>


Special thanks to:

 * Adam Domurad - for deep investigations and  fixes in core, and in numerous classloaders or otherwise complicated bugs
 * Jan Kmetko - for initial design of splashscreen
 * Deepak Bhole and Omair Majid - for ever keeping an watchful eye on patches
 * to community - namely:
   -  Jacob Wisor and Alexandr Kolouch  - who voluntary offered and delivered Pl+De and Cz translation

And not finally to all who tested the pre and final versions for regressions


Best regards
  J.

Happy hacking,
-Adam

icedtea-web 1.2.3, 1.3.2 Released!

Newest incremental releases in 1.2.x & 1.3.x series for icedtea-web were released! Stay tuned for the much-improved icedtea-web 1.4, in about a month.

From the release announcement by Jiri Vanek (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-April/022790.html)

The changes well... are as they are. Not much, but at least something - as development was strongly 
focused to HEAD.
 From this point of view, I strongly encourage every user to move to 1.4 as smoothly and quickly as 
possible (will be based on future head anyway).
Also please note that 1.2 is getting close to end of its life.

http://icedtea.wildebeest.org/download/source/icedtea-web-1.3.2.tar.gz
http://icedtea.wildebeest.org/download/source/icedtea-web-1.2.3.tar.gz

md5sums:
ab56d94251975a9bb5359ea85136ea79  icedtea-web-1.2.3.tar.gz
94ce02c42c1e4d1411357fb3c1014f67  icedtea-web-1.3.2.tar.gz

New in release 1.3.2 (2013-04-17):
* Security Updates
   - CVE-2013-1927, RH884705: fixed gifar vulnerability
   - CVE-2013-1926, RH916774: Class-loader incorrectly shared for applets with same relative-path.
* Common
   - Added new option in itw-settings which allows users to set JVM arguments when plugin is 
initialized.
* NetX
   - PR580: http://www.horaoficial.cl/ loads improperly
* Plugin
    PR1260: IcedTea-Web should not rely on GTK
    PR1157: Applets can hang browser after fatal exception

For details you can see changesets:
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/2d76719a5e4d
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/88fb945c9397
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/25dd7c7ac39c
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/25dd7c7ac39c
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/19f5282f53e8
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/ca8b00cca4c3
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/f63bdf513e9d
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/b619cda99360

New in release 1.2.3 (2013-04-17):
* Security Updates
   - CVE-2013-1927, RH884705: fixed gifar vulnerability
   - CVE-2013-1926, RH916774: Class-loader incorrectly shared for applets with same relative-path.
* Common
   - PR1161: X509VariableTrustManager does not work correctly with OpenJDK7
* Plugin
   - PR1157: Applets can hang browser after fatal exception

For details you can see changesets:
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.2/rev/34b6f60ae586
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.2/rev/cb58b31c450e
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.2/rev/cd4a9f25808e

Please consider for next few hours HEAD as frozen (until you see similar commits;)

Thanks to everyone who helped with this releases:
   Deepak Bhole
   Adam Domurad
   Jana Fabrikova
   Tomas Hoger
   Omair Majid
   Jiri Vanek

Direct all bug reports to:
  http://icedtea.classpath.org/bugzilla/
Direct all inquiries/comments/patches to the distro-pkg-dev mailing list:
  http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev

Happy hacking.

Lanarts Goals

So I decided to write up a post about my hopes for when I finally release 'Lanarts 1.0'. I hope outlining where the game is going encourages people to contribute.

The design philosophy:
To create a fun, dangerous, procedurally generated, co-op RPG which allows for continual character advancement without repetitive elements. The game will be very light on plot, and feature critical decisions, such as choosing between different challenges. The game will be best played end-to-end with a team of around 4-6 friends. The game will be designed with a loss-condition in mind, but one that can be made more lenient to players' liking.
 
Guiding points:
Any tedious aspects should be as streamlined and automated as possible.

The character advancement should introduce more interesting and nuanced features rather than just stat-gain. Character races and other game bonuses should be versatile enough to provide benefit to a large number of play-styles.

The game should be as data-driven as possible, allowing for easy content creation. The game should lend easily to hosting modified game content. Modified game content will happily be considered for integration into the base game.

The V1.0 goals:

• Stable Lua API that allows for developing/customizing the game as much as possible. V1.0 will introduce a (loose) API freeze and best-effort backwards compatibility measures.
• Well-performing game-play with at least 4 players (more is ideal).
• A lobby server for easy match-making.
• A flexible stat system based on character traits and abilities. This includes items with interesting effects, and a variety of 'tech-tree' style advancement options.
• An overworld with towns, thematic dungeons, and a final boss.

What aren't my goals:

• I'm not sure if V1.0 will have original graphics. While nice, I do not consider this a version-number assignable goal (primarily because I do not have the talent to decide when it happens.
• I don't intend to make Lanarts a generic RPG engine. I will move towards this as much as possible, but only where it enables smooth growth of the game.

7Day Roguelike Challenge Complete!

OK time to release.
Download: http://7drl.org/wp-content/uploads/2013/03/bughack.zip

I'm a bit exhausted from working on it so I'll just paste the README.

Welcome to BUGHACK.

The idea for the game was to include roguelike mechanics based on how ants find food through scents.

You are a leader ant who must lead worker ants to delicious harvest. Every sector you must gather a certain amount of harvest. Keep your ants safe, or you'll take damage! You must call ants out of an ant hole and then lead them to to fruit.

Press C in-game to see controls.

THE GAME IS TOO SMALL:
To fullscreen, hit F in game.
Alternatively, replace the occurrence tiles12x12_gs_ro.png in bughack.py with tiles18x18_gs_ro.png

Dependencies:
Python 2.X (32 bit is needed on windows)
SDL (included in Windows, needed on Linux)

RUNNING:
python main.py
(Or on windows, right click main.py and run with python 2)

Created by:
 Programming by ludamad (Adam Domurad), art by REZ (Clay Bullard)

7DayRL Competition!

OK, this will look silly in case I don't complete, but I will be joining the 7day roguelike competition!

I will be teaming up with putterson (who does occasional work on lanarts with me) and REZ (who I previously did a Halloween competition with, resulting in Carny Death Peddlers). The hope is to have a tiles-mode with ASCII.

I'll say at this point to save myself from potential foolishness that any potential failing of the competition will be due to being too ambitious with too little free time, and not because of lack of interest!

Anyway, cautiously optimistic.

I'd discuss the game idea but they're going to change a buttload -- and we'll find out soon enough, ain't it ?

So plans are to use libtcod & Python. It won't be my first game in Python but it'll be my first graphical one. So far just learning libtcod and going through the tutorials, but I find it straight-forward. It's funny how well suited libtcod is for this competition.

Lanarts Update March 4th, 2013

New release, ready for download!

It is recommended you move with WASD, melee with H, fire spells with YUIOP, mouse controls for everything else. Mouse controls for spells are fairly suboptimal at the moment.

Additionally, 1 to 9 for inventory slots 1 through 9.
Right click is needed to drop items, however.

So it's been 2 months since I felt like compiling this thing on Windows ... damn. About time for another lanarts release !
I hope sincerely to go back to a biweekly release schedule.

Major changes:

• Enemies now do not regen health a bit after hit. This makes enemy packs a lot less annoying. [Credit for idea goes to serprex]
• Floating point strictness flags turned out to help a lot with the remaining syncing issues.
• Saving the game is much more streamlined -- now you simply need to exit (via shift+escape) and the game will automatically save. Reload the game and hit Continue (or enter), and your game is loaded. I feel comfortable having this the default now since I haven't run into any save-file bugs in a good amount of time.
• Victory screen added, you can win the game now !
• Scoreboard added, with stats for your previous characters, whether you won, etc. Navigate it with arrow keys/pageup&down if you have a lot of entries.

Minor changes:

• Made it easier to distinguish walls and floor in the brick&hive tileset
• A lot more code was brought to the lua side, including the menu implementation. The scripting is becoming quite mature, and the game much more engine-like. Documentation to come !
• Unit tests moved fully to use UnitTest++
• Network debug mode was fixed, logging was made more verbose. Diff'ing logs proved to be very effective rooting out syncing issues.
• Game pausing and the steps_per_draw setting work again.
• Minor balancing to spells
• Added key display overlay for spells, and FPS counter in corner
• Moved the wide-open and difficult floor 4 layout to floor 7
• More options for hosting games, and the server's options now override client options (whereas before they could be weirdly out of sync)

Special thanks to putterson for all the online & LAN testing.

Windows:
Download!

Linux:
I do not yet provide linux packages, please do kick me if they'd be useful for you.

git clone http://github.com/ludamad/lanarts --depth 1
./run.sh

If you are missing dependencies on Linux (probably the case) please run either fedora-deps.sh for Fedora, or debian-deps.sh for Debian or Ubuntu.

Feedback

Please direct any bugs and inqueries either as a github issue, a comment on this blog, a post on the #lanarts freenode channel, or an email to domuradical@gmail.com. Feedback very welcome !

Fedora 18+Cinnamon

So, I had told myself I'd get use to Linux prior to coming to Red Hat, but truthfully that wasn't much needed. You learn fast when you're thrown in, and its sink or swim.

So, Fedora 16 was my first Linux distribution. I liked it a lot. I liked GNOME 3 a lot. With Fedora 16's end-of-life approaching (today, in fact) it was time to jump ship. GNOME 3 was nice enough, but I decided to put some of the noise about it in perspective and try something else.

Installing

Noticeably worse - a bit sad because obviously a lot of work was put into it. The new layout shows you all your options at once, but I think stepping you through them was more user-friendly.  Partitioning was confusing but in the end, it all worked well. Once I figured out I had to click on my F16 install, and hit a 'minus sign', everything went smoothly.

GNOME 3.6 Visuals, Graphical boot loader, etc

This probably impressed me more than it should have, but everything looked really tight to me. The fedora boot loader has a graphical back-drop, the login screen looks really nice, as were the various GNOME3 visual improvements. All of it fit together really nicely. Of course, at the end of the day, I would happily turn off any of these things for a better workflow. It sure is nice when people ask 'Whats this Linux thing?', and you have something shiny to show them.

Bugs

So once I tried to get some real work, I was unhappy to find a lot of small Eclipse issues. While F18 can only be blamed for bugs in Eclipse to a limited extent, it is one of those 'too big to fail' applications these days, so its worth mentioning. Without going into detail, these included issues with Java perspective not showing up after installing Eclipse Java Tools, and various graphical glitches using Eclipse C++ Tools. A more fundamental bug occurred when I tried to turn on desktop icons in GNOME 3.6 - instant crash, and crashing whenever I logged in.

Cinnamon!
The best thing about failing to get icons working on GNOME (admittedly I didn't try hard) was the decision to try out if they worked with Cinnamon. First off, I was very impressed with how well Cinnamon integrated with the whole Fedora user experience. Not only did a single yum command and a 'cinnamon --replace' have me trying it out in seconds flat, it was very simple to make my default desktop environment (toggle on log-in).

For someone like me that found GNOME 3's visually appealing, Cinnamon was perfect. Very soon I got rid of that 'hot corner' that GNOME 3 is so centered on, and set up some settings to my liking. Overall I find it more featureful, perhaps more Windows-like, but I'm not complaining.

Some things I do miss though is the nice way of dragging windows into workspaces with GNOME 3, and the 'application-centric' alt-tab that groups windows based on application.

Anyway, that's it for now. Overall I really like it, but then again I would have just been happy to get up to date packages again. YMMV.

A Lesson from Java's Swing

So whenever possible, I like to apply things I learn in my hobby programming to my professional programming. Conversely though, sometimes I am inspired by the design of parts of icedtea-web (the project I work on at Red Hat). To be fair, this is more the design of Java's Swing library, but it got me thinking.

The menu code in Lanarts was pragmatic but also hackish. It piggy-backed the normal event loop and each menu was a pseudo-level. That meant there was a bunch of classes that inherited from GameInst that were only part of the menu code. The menu code was created based off these objects being planted into the pseudo-level, configured with callbacks to wire the menu logic and drawing, and just enough menu placement logic code so that things were spaced sanely on different resolutions.

Taking a Swing at a better design

Although it wasn't the first time I used Swing, recently while having to assemble a dialogue box with nothing but Swing layout managers, it struck me that this could be a good approach for Lanarts user interfaces. While Swing has a large number of obscure layouts, a comment struck me that I forget the source of: "Using GridLayout and BorderLayout you can create pretty much any interface". So I coded the equivalent of these in Lua. This resulted in two small classes:

1. InstanceLine:

Arranges objects in rows, this is similar to Java's GridLayout, but is designed to be especially convenient if you just want a single row.

2. InstanceBox:

Objects are added based on relative position; a value 0 to 1 is used for x & y coordinates. Using this layout you can easily align something against the center-top of a box, and another component on the center-bottom, for example.

Using these classes nested together, flexible layouts can be created with a lot less mucking around with coordinates. The x & y positions of each menu component are now calculated each time they are drawn, instead of being fixed absolute values. This allows each layout to only store relative positions, making logic simpler. As well components can be created without their locations having to be known at the time of creation.

The GameInst structure was abandoned as well, and instead a simple event loop was created in Lua.

It was really fun to code, and ended up being a large improvement. Here is a picture of the result with debugging code turned on:

Note this looks exactly like it did before -- not bad for a complete reprogramming in Lua!

The elegance with which it could be programmed made me feel a lot more confident in Lanarts ability to act as an effective moddable engine. I was able to code it in Lua with only take very brief breaks to quickly add a missing function or two on the C++ side.

One surprising inspiration I got is to have a similar mechanism for the level generation. A nested tree of randomly generated layouts could produce very interesting results!

Lua & Lanarts

So lately I have been making some significant progress on the Lua side of Lanarts. Here's some summary!

LuaWrap, my pet Lua binder

After much frustration with existing Lua binding solutions (manual bindings, LuaBind, SimpleLuaBinder) I decided like any arrogant programmer to simply write my own. Of course, since I wrote it from the ground up, it suits my use-case quite well.

It is fairly small (24 short source files), flexible, and does not try to control your Lua environment in any way like SLB does. As well, although some performance was traded for ease-of-use, it provides an easy to use interface to eg Lua tables that suffers no performance penalties (assuming sufficient inlining). Here's an example of binding a global variable that should compile to the same code as if written by hand:

void bind_globals(lua_State* L) {
     LuaSpecialValue globals = luawrap::globals(L);

     globals["foo"] = "bar";
     globals["baz"] = 1;
}

LuaWrap is located in the lanarts source-tree under src/luawrap/. It does not depend on any libraries other than Lua.

Rewriting the main loop

So I wanted to move more towards having Lanarts as a game engine controlled by Lua. Now I definitely treat this as the compromise that it is -- it is perfectly possible to write a game in Lua, and that is not the goal. The plan is to allow people to modify the game very flexible in Lua without worrying about the networking aspect (except possibly for very heavy modification). The hope is that will inspire experimentation with the game mechanics.

So, as a start to this direction, I rewrote the main loop in Lua. Here's a look at the inside of the loop!

function main()
    net.sync_message_consume()

    local timer = timer_create()

    if not steponly then
        game.draw()
    end

    if not game.step() then 
        return false 
    end

    if not game.input_handle() then 
        return false 
    end

    local surplus = settings.time_per_step - timer:get_milliseconds()

    if surplus > 0 then 
        game.wait(surplus) 
    end

    return true
end

Object-Oriented Lua!
Figuring I'd continue this top-down approach, I have begun working on porting some of the menu code in Lua. For the first time, this actually meant I wanted to write something object-oriented on the Lua side! Now, OOP isn't a silver bullet, and I always like to weigh the pros & cons of other solutions -- but for graphical interfaces I think object orientation makes a lot of sense.

The first task I had was to decide on an object model. Now I think this is a really cool part of Lua -- it does not impose an object model on you. I settled on a very simple syntax, a single function 'newtype' returns a table suitable for use a 'type'. After which you simply add methods to the type. A special method, the 'init' method, is used to form a 'create' function. Here's what this looks like in action!

import "utils.lua" -- imports 'do_nothing'

TextLabel = newtype()

function TextLabel:init(font, options, text)
    self.font = font
    self.options = options
    self.text = text
end

TextLabel.step = do_nothing

function TextLabel:draw(xy)
    self.font:draw( self.options, xy, self.text )
end

-- Example usage
mylabel = TextLabel.create(font, options, text)

Some things notable here that highlight features of Lua:

1. For people coming from a Python background, 'import' seems like a Lua keyword. Actually, it's a function that is being called with a string literal. Lua allows this syntax for one-argument table & string literal functions.
2. 'function TextLabel:draw(xy)' is equivalent to 'function TextLabel.draw(self, xy)'. The colon operator is nothing more than syntax sugar for 'pass self as first parameter'.
3. Lua silently (for better, or for worse!) ignores extra parameters, allowing a generic 'do_nothing' function like the one used.

 Anyway, that's all for today! Just wanted to give an update as I take a break from gameplay-oriented updates, and the dreaded mess of implementing client-side prediction. Stay tuned.

My Year of Game Development

TL;DR? It's new years, and the first release of lanarts in 3 months! 
Download: here!

Github link

I believe I've grown a lot as a programmer in the past year. My knowledge of version control has expanded greatly -- from initially using SVN as little more than a file drop. I've moved from using windows exclusively to using linux exclusively. I started working at Red Hat this summer and learned much about real-world code (for the curious, I'm on the OpenJDK team, working on icedtea-web).

I decided to write a retrospective on my past year of game development on lanarts, I hope you enjoy it.

... Though to be honest, I didn't feel I could do it justice without some additional background pre-2012.

Pre(r)amble    Game Maker days

A game from my Game Maker days

I started programming by making games in Game Maker, although I have sworn off the program years ago. Since then I found that programming was fascinating in itself, and perhaps more so without annoying user interaction to worry about. In that time I did a great deal of hobby C++ programming, and some Java.

I started to enjoy working on large projects, namely a python-like scripting language. While very interesting, this proved to be unremarkable to my friends. So I thought, developing games again would be nice.

Summer 2011    From zerglings to witches and wizardry

My roommate was interested in collaborating on a project, and so we set off to make an RTS that was centered around LAN play. Lanarts. Somehow this idea got dropped, and instead we opted to make an RPG. The name stuck.

The first thing I did was toy around with level-generation code. It was quite simple, just plop down some rooms and tunnel between them randomly (backtracking on failure), but it worked well -- the code in place still stems from this.

After that I sought out find tiles to graphically display this dungeon, and found the rltiles tile-set, and subsequently the rogue-like Dungeon Crawl which uses them in a heavily modified form. Much distraction ensued! Soon me and Pat were playing Dungeon Crawl more than coding. However at the end of all the dungeon-diving my vision was clear, to make a game that could closely resemble a co-op roguelike as possible. 

Fall Semester 2011    The foundations of a game

I used SVN & CMake in a research project during a research position I had during summer 2011, so they were natural choices for me to use in my game. Pat was using linux exclusively, while I was on windows, and this was a very good thing to tackle from day 1. In retrospect I wish I had also handled networking issues from this point as well.

Work on the engine progressed. I had the foundation of a game engine going in C++. OpenGL drawing, game actors acting in an event loop, and a rather complicated actor-storing data-structure that, while tricky to write, I still use and has worked very well.

January 2012    Movin' to git

Why git ?
I was fed up with using TortoiseSVN, and Pat convinced me to get a google-code account and try out a better version control system.

Features at this point
Basic .BMP loading, OpenGL drawing, font loading with FreeType, a minimap, collision system, field-of-view, keyboard controls.

No gameplay ... yet!

February 2012    It's alive!

Initial Development
The game progressed with some additional sprites hard-coded into the game, which now could be any image format and not just .BMP. A single enemy was added, able to path-find to the player. It could be killed with a simple ranged attack. A fog-of-war outside of the field-of-view was implemented; the map no longer starts revealed.

March 2012    It's a game!

Adding Gameplay
The game progressed by leaps and bounds this month. Enemies could attack, and 4 different kinds of enemies were introduced (all still in the game!). The level generation was tuned further and levels were given distinct layouts. An inventory was added, basic items such as HP & MP potions, as well as basic stats such as experience points and levels, and damage. No death animations were present yet, and melee attacking was preformed by simply walking into enemies, much like typical rogue-likes.

April 2012    It's an online game!

Taking it 2-Player

The game became even more game-like, with weapons, scrolls, and an additional spell (in addition to blinking and fireball which were already in). Monsters were no longer melee-attacked by walking into them, instead requiring a key press. Enemies get stronger by a fixed formula the deeper you go. Online was implemented! It was fraught with problems - crashes and synchronization issues - but the game could be played with 2 people!

May 2012

Online was further stabilized, projectile items added, additional tilesets, a game-chat bar that features notifications. Many new enemies.

June 2012    First blog post!

Overhaul of stat system to one used currently, many new enemies including a set of animals, and two bosses. Many UI improvements, addition of weapons such as bows, early prototype of fighter class. Added visual representation of resting-system. Enemies travel in groups nicely thanks to the RVO2 library.

July 2012

Fighter class fully added, with separate sprite, and berserk spell. New tabs added to the interface. Stats displayed more nicely. Arbitrary numbers of players were added. Moved to github, where the code currently resides. Mostly fail at attempts to get additional developer interest.



August 2012    ... More than 2 players!

Shops were added. New archer class hastily added, was quite underpowered. Continue to look for help on the game, without much luck.

September 2012   ... ARRP, last official release (until today!)

The game was released for the ARRP. See this playthrough! The equipment system was redone with many new equipment slots. The main-screen was redone to allow for setting IP and connection port cleanly without fiddling with resource files. Work started on a new game, Carny Death Peddlers, with and old partner-in-crime, REZ, from my Game Maker days. The ability to work with a brilliant pixel artist was too enticing -- even if the project was forced to use Game Maker...
 
October 2012    ... And Carny Death Peddlers is finished!

Frantic game development, in time for Halloween!
The game was successfully finished within a month-and-a-half for a Halloween-themed game development contest. I think it's obvious that this is a very small timeframe to complete a game. The dedication that my artist partner REZ showed for completing the project kept me on-task. There was definitely many stressful periods but I've never worked on a game with someone with such unified vision, it was awesome! The game has since been featured on several gaming websites such as GameJolt, and has ~1000 downloads on 64Digits.com. The game features great original music by Glock&Mr8bit. 

 November & December 2012    ... A needed break, and then back at it

Engine improvements
After the release of the last game I was a bit burned out. However, creating a full game in such short amount of time was inspiring to reapply my efforts towards polishing Lanarts. Glock&Mr8bit and REZ both agreed to help with the game. Unfortunately, REZ soon became busy with his own projects. Glock&Mr8bit worked away at producing music, and I worked on improving the engine in various ways, such as being able to play sound effects and music, and a better Lua framework. Still looking for additional developers.

Download: here!
This release features:

• Lots of balancing work
• Lots of new items, with new items added for practically every equipment slot.
• Two new enemies, a centaur who keeps his distance, and a hydra whose head count represents its remaining HP (a future change will make these more like the 'cut off one head two grow back' hydras of legend).
• A new fighter ability - 'Power Strike', an attack that hits multiple enemies in an area with your weapon, and also knocks them back with a temporary stun. Gained at level 3.
• Interface improvements, better auto-equip logic when switching equipping projectiles & projectile-using weapons. Spells that are typically used once and then switched to melee no longer default to melee when their key is held. You are now able to use spells without first switching to them (previously two keystrokes were needed to use a not-selected spell).