• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

1189 Excellent

About doeme

  • Rank

Personal Information

  • Location
  1. Meetings are boring! Meetings are boring, overcrowded, take up much of your valuable time and don't produce the desired results. Or they can be interactive, efficient, goal-driven, interesting and sometimes even fun. So how to go about planning and running successful meetings? Five and a half Steps to successful meetings Running successful meetings is not difficult; it just needs some preparation and a bit of practice. Before I go into the details on how to plan and run an efficient huddle I would like to state two very important point: If you call in a meeting, you are the one responsible to get the most out of it. It's your show, so while you might not be the main contributor to the content be sure you are the one to drive the meeting forward. Be the facilitator of discussions, be the one to help everybody to keep the focus and last but not least be the eye that watches the clock. As Slayemin put it so aptly in the comments below: "The ultimate purpose of a meeting is to reduce confusion and uncertainty. If people go into a meeting and they leave less confused or uncertain, then it was a good meeting. If people go into a meeting and come out with the same or greater amounts of confusionion, it was a poor meeting. As a meeting attendee, you are either the one who is confused and uncertain, or the one dispelling confusion for others." Step 1: Send out the agenda before the meeting. When you schedule a meeting prepare an agenda and send it to anybody involved. Preferably early enough so anybody can read through it and comment on the agenda if necessary. Tell everybody what this meeting will be about and what its goals are. This helps you also to keep the meeting on topic later on, as it prevents people from shoving in an extra discussion about something else. Having a clear agenda also helps to decide who needs to be in the meeting and who will waste his time as an over-passive listener. Step 2: Have a well structured Agenda Try to keep the agenda short and on topic, as this also helps to limit the scope of the meeting, which in turn helps people to sty focused. I structure almost all my meetings very similarly like this (Although often in a paraphrased way): Introduction to the topic and the goal of the meeting. Take a few sentences to introduce the crowd to the topic you are about to discuss about. If there were any previous meetings to the topic do a short recap of them. And most important state the goal of this meeting as clearly as possible. Assess the points to discuss or the problems to solve. Break down the problem into smaller items that can be tackled in the time you have. Tell them something along the line of "In order to achieve XY we need to solve A, B, and C and I would like to discuss this in this order". Discuss the points or solving the problems. Now go along and discuss the items you brought up. Take notes or have someone take them for you. Define action items to carry out. Assign how to continue after the meeting. Assign the action items to a person and have them write their todos down. Conclusion & define follow up meetings. Wrap up the meeting by going through your notes again and communicate what you expect to be done until the next meeting or deadline on the topic. Step 3: Stop the babble, focus on the topic Time is money, so you don't want to waste it talking about irrelevant stuff. Often enough there are meetings where two people start to discuss something in a very detailed manner while five people sit there bored staring at the walls because nobody wants to interrupt. The solution is to create an environment where it's ok to stop runaway discussions. I sometimes distribute red cards at the beginning of the meeting and tell people that if they are thinking that a discussion doesn't contribute to the meeting they can raise that card. The people talking should then finish their sentence, write down the topic of the discussion and postpone it. In groups where I have done this regularly we now can do this easily without the red cards, because everybody knows that it's ok to tell the others to shut up for now. Step 4: Manage the time Try not to call in meetings longer than two hours and if you have to, plan in frequent short breaks. People cannot stay concentrated for longer than one hour without a quick breather. Be dependable when it comes to timing and duration of meetings. Be on time when starting a meeting, better yet be five minutes early and have everything setup and ready. Having ten people watch somebody fiddle around with a projector for five minutes is not funny. Have your handouts, Flip-charts, presentation and any office supplies needed such as post-its, markers and writing pads ready at the beginning so you don't have to run off to find them in the meeting. Ending the meeting on time is the harder part but with a bit of training this becomes easy as well. Start out by time boxing the items on the agenda, and have an eye on the clock during the meeting. Often it's better to conclude a meeting on time, even if you have not reached all the discussion points on the agenda, take a breather and schedule the next meeting at a close time in the future. Estimating how much time something takes is hard at first and needs a bit of training but a good guideline is to do a quick calculation along the line: "five people are in the meeting, everybody will talk 5 minutes about the subject, so 25 minutes it is." Step 5: Track the discussions This one is simple. Take notes, sort them after the meeting and archive them in a place where you can find them again. Distribute the notes to the people involved between meetings, so you don't need to raise the same issues over and over. Also encourage others to take (& share) their personal notes. Optional Step 5.5: Get Feedback Running meetings takes training and training needs feedback. Get feedback on how the meeting went from the participants. One quick way to get feedback is to prepare a flipchart with a pre-drawn graph on time invested vs. outcome and have everybody leave a tick-mark on the graph. Follow up with the people who think they wasted the time, ask them why. Also give others feedback when they run a meeting to encourage them to do the same. Using this on different kinds of meetings Meetings can span a very large range from all-out creative brainstorming sessions to the dry presentation of your new company regulation on home-office work. While the five steps fit any kind of meetings, they can be tailored a bit to fit any particular style of meetings. I tend to place my meetings into four overlapping categories to get a first grip on how I want to run a meeting and what to expect as outcome. The boundaries between the categories are fluid but knowing in which area I am usually helps me in setting up the agenda and time frame of a meeting. Informative: The purpose is to fill in the attendees with certain kind information, frontal presentation is often the way to go, but restrain yourself from droning away. Keeping your audience's attention up is one of the key challenges. Having a clear and focused agenda that helps people follow up the progress of the meeting and stopping any unnecessary babble helps to avoid losing the audience. Your job as the facilitator of the meeting is to get the facts across in a concise manner and answer any questions from your audience to their satisfaction. Creative:Usually the most interactive kind of meeting. You try to find out something new, whether an artsy brainstorming session or a technical design meeting usually you get the crowd to participate. Challenges are to restrain run-away discussions and actually find a conclusion while not restraining the people from getting new ideas in. As the runner of the meeting you are responsible that your creative process runs smoothly and ensure and document the progress of any discussions and ideas. Decisive: You got the facts laid out but you need to find a decision on something where the facts are already laid out but might be conflicting or not yet fully understood. Often combined with the informative meeting, the challenge here is to actually get a decision to made and responsibilities cleared. To keep these kinds of meetings short having a pre-read where everybody can get up to date in his or her own time helps shorten these meetings. Time boxing these meetings helps to avoid running a discussion in circles, sometimes one has to agree to disagree but still decide for one option. Analytical: You got a problem here but we don't know what (or who) caused it, so you call in the gang and to figure out the why. Collecting and consolidating any information on the problem before the meeting will speed up the actual process of analyzing the facts. Have an eye on conflicting information, check for any inconsistencies and bring them to the attention of the attendees. You might not be the one person with the deepest insights into the problem but your job here is to mediate between multiple different opinions on the state of affairs. Especially when the question borders on the "who caused it" avoiding slipping into a blame-frame is often a key. Analytical meetings are often followed or interwoven with creative or decisive meetings so be sure to track and document the meeting for further use. Now Meet up! The five (and a half) steps and the four flavors of meetings are tools for you to use, but said that as with everything it's practice and not the tools that make perfect work. To run meetings smoothly and confidently you will need some interpersonal and crowd control skills which will come with practice and time. Use the five steps as an anchor point for planning and running meetings, decorate them with your personal style and preferences and your meetings will never be boring again but efficient, goal oriented and successful. Article Update Log 26th Ocotober 2015: Added quote from Slayemin
  2. This is an excellent point and condensation of what I tried to tell. Would you mind if I quote you in the Article? 
  3.   Thanks for the appreciation but I disagree with your statement. While being creative is part of being a programmer and sometimes you have to experiment to find a solution, producing working software is the only thing that counts in the end. Any good working environment should make room for experimenting but I would rather have this not tightly integrated in any project with a deadline.  
  4.   Very good advice, for me this plays into becoming a teamplayer and being a "good citizien" for your team. 
  5. Everybody is a great coder It's now over fifteen years since I first got money for a program that I wrote, and since over ten years I consider myself a professional software engineer. When I started out programming I was convinced that raw coding ability and deep, innate technical knowledge of a few programming languages would be all it would take to make it in the industry. But over the years I learned that there is more to being a professional programmer than hacking together complex code. Having worked both in academics and industry, this often became most apparent to me when working with newbies fresh out of college. Often they are great programmers but lack some of the surrounding skills to make them look professional to me. So what distinguishes the common coder and/or hobbyist from the pros? Before I forget: This article is written on a purely subjective basis of my personal experiences, feel free to tell me that I'm wrong Diversify your knowledge Get things done with your code While being an able coder is not the only thing that counts, not being one immediately disqualifies you to become a successful programmer. Be sure to master at least one full-fledged common programming language such as C#, Java, C++ etc. Go into details of the language, know the standard libraries, know how to wield the language to great effectiveness and know how to cope with any limitations it will have. As a bonus to your main language, know at least one scripting language to automate small tasks, create quick experiments and do ugly proof-of-concepts. Don't be slowed down because you don't know your basic tool - the programming language - well enough. In short: Make sure you know how to get things done and get them done reliably. Show me your mind Getting complex things to work is only one side of the medal, the other side is that those complex structures want to be explained. Maybe your fellow code monkeys want to discuss a problem with you, maybe it's your boss trying to get a grip with your skills, maybe it's plain old documentation that needs to be written. Whatever the cause, sometimes just writing code comments is not enough. Know how to visualize (and read) software structures. Be it UML diagrams, flow charts, ERD or simply Venn diagrams, know how to draw a diagram that others can understand. You don't need to be fully proficient in the last details of the "official" iconography of any visual language, but not being able to draw a simple class diagram or state machine will leave your thoughts behind closed doors for others. On the other hand, learn to recognize (and name) patterns in these charts, however badly scribbled by one of your fellow hackers. Prove me that it works Yay, your great ideas and concepts are approved by your team and you've written that beautiful piece of code to solve the problems of the world. But does it survive the impact of the users? Testing, Testing, Testing is the only answer to this. Know how to test and debug your program. Relying on print-debugging and testing by "it appears to run correctly" may work for small projects and in the short-term, but there is a certain point where we want to guarantee that a program works in exactly 'that' way. While you don't need to embrace test-driven development in the full, know at least about unit testing, know how to use a debugger efficiently, use software asserts and read into design by contract. Learn how to do a performance analysis of your code and other non-functional requirements. Be able to write consistent and good tests for your software, know what is covered by your tests and what is not. Your code has a history While well-tested code is a must, sometimes the path that leads to any particular solution is also important. Sometimes you just have to see how code evolved to understand it or find the exact moment when a bug was introduced, luckily there are plenty of versioning tools out there which help with this task. Be sure to know about source code management and versioning systems. It doesn't matter whether this is SVN, Git, Mercurial, TFS or any of the others on the market, just be at home with the usage of at least one and get the basic concepts behind them. It's not just about versioning, but also about backing up code and traceability of features. It's astounding how many hours of productivity I've seen go down the drain because some guy in a team of coders just did not use versioning software properly. Be it in files lost, because of an accidental overwrite, being unable to merge a conflict with a team member or just messing up the workflow for everybody else by not following the basic concepts behind source code management. Take one for the team Now you're able to produce well-designed, peer-reviewed, tested and traceable code which greatly increases your chances to be seen as a professional software engineer. Time to start working together with other great professionals out there. Software development is no longer an occupation for loners who work alone, nowadays software development is considered a team sport by many successful companies. So be sure that you are prepared to work together with other humans and become a team player. Grasp the basic fundamentals of software development processes in teams, know about iterative vs. incremental software development, about defining deliverables and features. There are tons of development processes out there to read into, be it scrum, kanban, XP, feature-driven development - whatever floats your (or your employer's) boat. No need (yet) to get any certificate on anything about these processes, but be aware that they exist, and that they are used to great success by many software producing companies. Another major point is if you want to be part of a tight-knit development team, learn to be a "good citizen" for that team. Be honest towards yourself and others, learn how to communicate on a professional level if things don't go according to your plan and last but not least, sometimes you just have to bite the bullet, swallow your pride and take one for the team. That's it? Am I missing something in this article? Certainly. Of course there is more to being a successful programmer/software engineer than the five points mentioned above, and of course, not all of them apply to the same extent to anyone or any company. Working with a startup indie studio that needs to produce something now with limited personal resources puts a different weight on things than being hired by an AAA company where you are just a tiny cogwheel in a great machine. Also, some of the things mentioned above are easy to learn, while others need time and experience to grow. Learning tools is easy, learning people is hard. It's a catch-22 you need to work together with other professionals to gain the skills needed to be accepted as a professional yourself. Keep an open mind for well-meant critiques and be reflective about yourself and don't give up. Feel free to comment on this article or reach me over PM. Article Update Log No updates yet
  6. For over eigth years SVN was the cornerstone of the software engineering department at the company I work and it helped us to develop high quality medical simulation software. However as our product portfolio and out team grew, SVN started to show some weaknesses when resolving conflicts, hotfixing old releases and switching branches. So we decided that now it is time for a change. We did some evaulation of SCMs - namely TFS, Pearforce SCM, Mercurial, Plastic SCM and Git - and the sole winner, and honestly my personal favorite was Git. No other SCM would allow us so much freedom in creating a superb and decentralized process for software developing. Just one caveat, Git is not that great in handling large binary files of which we have quite a few, since all our simulation assets are basically checked in together with the code into SVN. Yes storage is cheap, but wasting space with binary data which cannot be properly diffed just feels not nice. Apart from this when working on SSDs storage isn't that cheap anymore. Luckily the git large file storage extension was recently announced by github including a reference implementation of a storage server, so we decided to jump on this opportunity and try this out. Setting up the LFS-reference server for a first test run was easy, our testing-infrastructure-guy churned out small script which takes over the configuraiton - which basically is setting a few environment variables - then starts the server. For the moment we just blatantly ignore any security issues. The server ran smoothly, so since we're already using Atlassian products we decided to install the trial version of stash as well and got our developers to download SourceTree as a Git client. Especially our modelers and content-creators are not really keen on using Git from the command line so a nice UI will help getting them to accept the new tool. Installation of the git-lfs client went smoothly as long as it can find the git-executable in your $PATH variable, if not the path can easily be supplied manually. Configuring lfs, registering stash as a remote repository and initially checking in our codebase and resources went well when done from the command line. Tracking large files is very easy by supplying patterns similar to the ones in the .gitignore files git lfs track "*.mp4" On every push to the stash-repositories the files would be checked in into the LFS and stash would only get a text-file containing a hash & file-size for the files stored on the LFS server. Sourcetree did not find the LFS-Extension at first until we realised that we needed to switch from "embedded git" to system git. But there the troubles would not end, since the LFS server did not run on the same hostname and the user needed to enter two sets of credentials for a push and aparently sourcetree could not handle that additional dialog. After a bit off googling we could fix that by usinggit config --local credential.helper store we could enter the credentials once on the commandline and since they would not be asked again sourcetree could cope with this. What's not nice on this is that the credentials are stored in plain-text on the users machine. Here the winstore-helper for git comes in handy. This helper lets you use the windows credentials-system for storing the credentials and we considered that reasonably safe and on a plus side one can use the windows credentials settings to manage the credentials. So basically we now have a running evaluation system with stash, the git-lfs server and users which can use the convenient UI of sourcetree to work with git. So where do we go next? First on we will try to get more experience with LFS and will try out if we can get rid of the credentials-workaround by putting the LFS-server on the same domain as stash. Then we will see if we can get stash to work with the LFS-extension And last but not least we will fiddle around with the development workflow to see what works and what not.
  7. Thanks for all the responses, It is interesting to hear different points of view. I guess it is not as easy as I thought to formulate a "done" definition.     the "it's right" and  "reasonably" part is exactly what I would like to explore more here.     It is not about trust or about somebody not doing their job properly, but about that the view wheter something is fixed or not may differ depending on the view of the person. I just think that it might help to work together if all persons concerned share a common view when a piece of work is done. My experience is that there are sometimes some gaps between developers, QA and product managers when a feature is done and this can lead to some frustration on every side.   I see a lot of discussions like this which i think could be prevented by a definition when something is done: PM: Is the login screen done? Dev: Yes PM: Cool, then we deploy it next week Dev: Oh no, it's not back from QA and the definitive layout and images are still missing PM: So it's not done? Dev: No, it's done. I closed the ticket and handed it over to QA QA: We're not testing without the layout and images, because else we're testing twice Dev: So open a new ticket for the layout PM: But the layout is part of the login screen, do why wasn't this added before QA .... So in this case a definition of "done" as "Functionally complete, with all images and layout" would have prevented the whole discussion.
  8.   I try to clarify a bit: I'm trying to get a feeling on how other teams handle it when they say "We're done with this feature" what prompts them to define that something is done? In your example you say you're "done" when you hand something off to QA. My guess is the QA has some requirements for accepting a feature to test; for example, they want the developer to describe a test-case before handing it off, or have some automatic unit-tests that need passing etc. For instance if your code doesn't build QA probably wont be able to test, so they hand it back because you are not "done"   And these rules are excatly what I try to get to. I'm wondering if other places have a checklist when stuff is ok to hand on to QA (or the end-user if QA is done by the devs)   I'm pondering about this because I was talking with a friend who is in QA and usually they have pretty clear rules when a feature is "done" in the term that it passes QA or not. But he was also a bit venting off on developers who deliver a "fix" without actually having run a program once or even telling what QA has to look at and then expecting them to handing out a "QA-Passed" label for it.
  9. Hi all,   Just our of curiosty, do you have a written down definition of done or acceptance crieteria in your team/company? And if so, how is is formulated and what is in there? I'm talking about the criteria when you or your team deem a feature or requiremet  to be "ready" excluding any bugs that might be reoported much later from somewhere.    
  10. In a previous entry I wrote about my journey to find a suitable library for creating and interactive UI for viewing and modifying graphs which lead me to the Open Graph Drawing Framework to layout my graph for drawing with Qt. So here is the code for the prototype that I wrote: Setting up First we set up a simple graph consisting of a parent with six children. I link child[0] to child[1] for a bit more complexity.//------------------------------------------------------------------------------// Creating example nodes and edges//------------------------------------------------------------------------------ogdf::Graph g; // Root data container for OGDFauto parent = g.newNode(); for(uint i = 0; i < 6; i++){ g.newNode(); g.newEdge(parent, g.lastNode());}// An edge between two nodes for more complexity in the layout// and to force ogdf to create bent edges g.newEdge(g.firstNode()->succ(), g.firstNode()->succ()->succ()); Then I set up QGraphicsView which is straight forward from the documentation. For simplicity I draw every node as a square of 40x40 pixels. It is also possible to set individual dimensions (and other attributes) or elliptical shapes for single nodes using the GraphAttributes class. But for simplicity I leave it as it is.QGraphicsView* contentWidget = new QGraphicsView();QGraphicsScene* graphicsScene = new QGraphicsScene();contentWidget->resize(500, 500); Arranging the graph After the set up, we call the layouting of OGDF. The spatial information of the graph among other attributes is stored in the GraphAttributes class. There are quite a few layout algorithms provided by OGDF, but I found the PlanarizationLayout the easiest to use, which yielded good results without too much tweaking.//------------------------------------------------------------------------------// Layouting//------------------------------------------------------------------------------// The GraphAttributes will contain the position and other layouting informationogdf::GraphAttributes ga(g, ogdf::GraphAttributes::nodeGraphics | ogdf::GraphAttributes::edgeGraphics | ogdf::GraphAttributes::nodeTemplate | ogdf::GraphAttributes::nodeStyle | ogdf::GraphAttributes::edgeStyle);ga.setAllHeight(40); // Set the dimensions of all nodes; ga.setAllWidth(40);// Create and apply a layout on the graphogdf::PlanarizationLayout layout; layout.call(ga);// resize the graphicsScene to the bounding box that was calculated in the layoutgraphicsScene->setSceneRect(QRect(0, 0, ga.boundingBox().width(), ga.boundingBox().height())); Drawing Drawing of the nodes is straight forward. We iterate over all nodes in the graph, retrieve their positions from the GraphAttributes and then draw a square on the QGraphicsScene.// Draw the nodes QPolygonF square; // create a square of size 40, 40 to use for displaying latersquare setBrush(QColor(1, 1, 0, 1)); squareItem->setPos( x, y); graphicsScene->addItem(squareItem);} Drawing of the edges is a bit more complex, as the edge-paths can be a combination of straight lines and cubic bezier splines. From the start point of an edge it can go straight to the end line or have multiple splines in between. Every cubic bezier spline needs three points to be drawn, so we can check if the number of points in a edge path is a multiple of three to determine if we have splines in between. I havent tested if the splines are connected seamless or if they can have straight sections in between.// there is also a forall_edges(edge, g) macro for(ogdf::edge edge = g.firstEdge(); edge; edge = edge->succ()){ auto polyLine = ga.bends(edge); QPainterPath path; // here we should check if the line really has at least one point auto pointIterator = polyLine.begin(); path.moveTo((*pointIterator).m_x, (*pointIterator).m_y); // move the line to the starting point if(polyLine.size() % 3 != 0) // straight line to either the starting point of the spline or the end point { ++pointIterator; } for(uint i = 0; i < polyLine.size() / 3; ++i) // iterate over the splines. Every cubic bezier spline needs 3 points { /// get the three points and increase the iterator afterwards /// maybe we need a path.lineTo(point1) here as well, to connect multiple splines auto point1 = *(pointIterator++); auto point2 = *(pointIterator++); auto point3 = *(pointIterator++); path.cubicTo(point1.m_x, point1.m_y, point2.m_x, point2.m_y, point3.m_x, point3.m_y ); } if(polyLine.size() % 3 == 2) // Straight line to the end point { path.lineTo((*pointIterator).m_x, (*pointIterator).m_y); ++pointIterator; } graphicsScene->addPath(path); // Add the edge to the scene} And finally we show our widgetcontentWidget->setScene(graphicsScene); // Setting the scene to the graphicsViewcontentWidget->show();
  11. Practicing the "team" parts of scrum by yourself is almost impossible, as you are not able to reproduce the interpersonal relations of a team when you are alone. However the project-management parts are easily doable by keeping a high-level backlog, dividing it into stories and then into simple tasks, the way Tom wrote.   One of the key aspects of scrum is to have a "potentially shippable" product after each sprint, which is a very nice goal to train to. Have something working that you would be confident to display after a certain time greatly helps to get things done.   Also instead of practicing, get some reading done. I highly recommend "Scrum and XP from the trenches" (downloadable here: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches ) for a practice-oriented read, if you already know the basics about scrum
  12. No worries, thanks for the information.     Thanks for the tip, yED looks very nice. However the whole point was integration into my own project. But maybe having a nice exporter/viewer for it like yED will enhance the use even more.