Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411273 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 01:29:21 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityTownhallTIGSOURCE GUEST ARTICLES
Pages: 1 2 3 [4]
Print
Author Topic: TIGSOURCE GUEST ARTICLES  (Read 52268 times)
Noah
Level 0
*


View Profile
« Reply #60 on: July 17, 2011, 11:42:34 AM »



1899: Steam and Spirit is a novel browser-based adventure game by Italian developer, Moloc Lab.

The game is set in a steampunk universe, with Part 1 taking place aboard a British submarine off the coast of Algiers. You are in command of a youthful Winston Churchill who, after a night of heavy drinking, must drag himself out of bed and resume a diplomatic mission of utmost importance. For the time being, that mission is to acquire some diving gear so that Winston can make it onto shore. This task in itself requires some clever tricks, a little ingenuity, and even a tiny amount of geographical knowledge.

The atmosphere of Steam and Spirit is wonderfully minimalistic, combining an ambient underwater soundtrack with some comely lo-fi graphics. The interface itself shares this concept, consisting of a "look/interact" verb coin and a hassle-free inventory.

While the game has seen a small amount of coverage this year, its nature as a work in progress means that it has undergone a fair bit of change. Recent updates have smoothed out some of the earlier flaws in its design, making it more fun to play overall.
One such update is the replacement of an unintuitive right-click function with the verb coin I mentioned earlier. There's also been a revised translation, plus a demo for Part 2 has been added so that we might get an even better feel for the direction the game's headed in.

Normally, I'm content to just enjoy a game like this, rather than write about it. However, when I checked on Steam and Spirit's progress today, I really felt compelled to give it some more limelight. With its new coat of polish, it shows even more promise as a real gem in its genre.

If you take a liking to the game or are interested in its development, you can follow its progress on twitter, or even donate via Moloc Lab's homepage.
« Last Edit: October 14, 2011, 02:58:36 AM by Noah » Logged
Anomalous Interactive
Level 0
*


View Profile
« Reply #61 on: July 20, 2011, 06:00:00 PM »

This is an article I wrote for Gamasutra. You may want to post it on TIGSource as well!

An Indie Guide to Quality Assurance Testing and Procedures

My name is Ryan Keable and I am a co-founder of Anomalous Interactive, a new indie development studio out of Melbourne, Australia. Before I began running my own studio I was many different roles in the Australian Games industry. One of those roles was lead Quality Assurance manager on Wicked Witches latest title, Wii AFL.

After this role I began QA consultancy for The Voxel Agents, another indie dev team in Melbourne who are responsible for the successful Train Conductor iPhone series. Working with these guys I realized that many indie dev teams don’t know enough about correct QA procedures and operations!

I found that many small teams fully realize is that QA affects production more than you think. The more efficiently you can manage your QA the faster your games will be developed and they will release with a higher level of polish. We followed this QA process in development of our latest game, Slingshot Justice and I would like to share a few hints and tips with you.


Bug Tracking and Ticket Management

This is the most important and most obvious part of the QA process. When you are writing down bugs, you are identifying and categorizing an issue in your game that needs to be fixed. Correctly reporting bug information and categorizing it clearly will make the job easier for those who will be required to solve it.

Identification:

The first step is to identify Who, What, when, Where and How (why is the same thing as how respectively).

    * Who: refers to player based choices when the user has the option to select from multiple characters, modes or scenarios to play as. This is the first step for identifying how to resolve a bug
    * What: what occurred? In the most simplest terms write down what occurred to the best of your knowledge (you may not always be sure but the more detail the better)
    * When: When did the issue occur? about what time during the game play? etc...
    * Where: is purely location based. what level were you playing on? What screen were you on? etc...
    * How: Write down Steps to reproduce where applicable. This is important as it will help your programmers to reproduce the error and apply the appropriate traces in the code to see what is actually occurring.
          o Remember: The cause of bugs are not always obvious; programmers ARE human, assist them as much as possible.


It is also beneficial under certain circumstances to list out an array of issues that are covered by the same category. This is helpful with areas of the game such as UI. A list of bugs found in a single UI screen can be grouped into the one ticket and displayed as tasks. This helps to prevent bloating your ticket system with too many tickets and the annoyance of having to look at multiple tickets that all cover the one area you are currently working in.

Categorization:

Now that you have an informative bug written up, many tracking systems will allow you to create development categories such as ‘code’, ‘art’ and ‘design’. Categorizing your bugs with these kinds of keywords will help identification and sorting in your tracking system.

Priorities:

Identifying the priority of the bug is very important for work flow. When you are working with a system that involves upwards of 100+ bugs, organizing tickets into levels of priority will help both production and the ticket owners responsible for fixing the issues determine where to start. Organizing priorities also helps establish the overall work flow for Milestones and Sprints.

Submitting for Testing:

This was a system I loved to work with. When the owner of a ticket has decided that their bug is resolved on their end, that bug is now ready for testing. Create a ‘testing’ resolution for tickets to group all the tickets that need to be tested together. This allows production and QA to see just how much work is required on the re-testing end. Allocated tasks should also be put through this process so QA is aware when a new feature is implemented and ready to be tested.

Communication and Commenting:

Your ticket system and work flow should allow for a good deal of back and forth dialogue between the reporter and the owner. All transfers of tickets between reports, owners and testers from allocation to testing and to final resolution should be accompanied by comments. This does not just signify ticket sign off but is also great for iteration.

One of the best experiences I had on QA was creating comment based dialogues back and forth between myself and the UI programmers as we worked through specific bug or usability issues. This simple dialogue freed up our time from having to do specific 1 on 1 sessions over simple issues or creating multiple tickets for the same category and bloating the system.

Here is an example from Wii AFL:
My bug report:
- Injuries’ button hover state is scaling incorrectly
- ‘Player name’ is injured and is out for 1 weeks
- There is no notification when an player has recovered from injury
* can we add textual information in the injury field to display recoveries?


This was returned by the Programmer with:

- ‘Injuries’ button hover state is scaling incorrectly - fixed
- ‘Player name’ is injured and is out for 1 weeks - fixed
- There is no notification when an player has recovered from injury
* can we add textual information in the injury field to display recoveries?
What information should we display and how do you want this information to be displayed?

In this fashion we polished the bug and maintained a design and production dialogue without any unnecessary meetings.


Google Spreadsheets are Awesome


As you probably know already, Google docs are awesome. They are also amazing for Test Matrices, on the fly QA testing and Asset Tracking.

Test Matrices:
Test Matrices should be used as final comprehensive checklists to ascertain whether your product is functioning correctly. Test Matrices are checklists that cover all functionality within a given system. You can use as a resource domain for bugs or as a checklist to write bugs from.



Data Entry and Analysis:
Spreadsheets can also be used to record data and information generated in your game overtime. The collected data can then be analysed and compared in order to determine if there are bugs or design flaws with the related feature.

This is fantastic for tracking statistical data in your game such as:

    * scores
    * user growth systems; experience, power ups, etc...

With a recorded overview of data you have the capacity to compare and contrast the data accumulated data and find any errors or idiosyncrasies. It will also help you to evaluate user progress and user experience, depending on the feature

For example, in my Wii AFL, football players gained experience after every match. The rate at which XP was gained and spent (amongst other things) was tracked in this Spreadsheet.



From this data we reported numerous bugs that would of been difficult to spot through general observation. It also provided us with an overview of the user experience of these systems and allowed us to adjust the features accordingly

Asset Tracking:
Google spreadsheets can also be used as an asset tracking system, either for task development tracking or as a general asset checklist. Again on Wii AFL we used this process to track the current level of implementation, exportation and development of over 1000 animations.

The shared access to google docs disabled any bottle necks that are normally created by version control ownership by allowing all our animators to post their updates simultaneously into the document.

Bug testing for the animations was also integrated into this google doc system by creating columns dedicated to checking specific aspects of the animation; both technical and aesthetic. All bugs related to an animation were eventually handled by this system and written as comments inside the related column and coloured correctly for the animators to interpret.

Final Notes on Google Docs:
While I have really only covered spreadsheets, don’t forget about google’s word processor and drawing tools! Use these tools to create on the fly, dynamically updating design docs and specs. You can support design docs with simple illustrations that can all be worked on collaboratively.

Make them pretty! Use headers, columns and row breakers to make your docs easy to read. The colouring rules for spreadsheets are really easy to set up and work dynamically and should be used to display the different states of development. A simple colour system is red for not done, yellow for in progress, blue for done, green for approved!

Google docs are shareable. I cannot stress the importance of this, it completely removes production bottlenecks created by version control ownership and lockouts that limits only one person to work on a document at any given time.

Google Docs are automatically saved, revisions included!

Finally there are exporting issues when converting from google docs to excel so please do not attempt to create game data in google docs then export it into your engines!


Builds for Testing


It is always important for development and production to have working builds. Do not let broken builds stop your artists and designers from continuing their work. Try to get one or two clean builds out each week for testing. When writing bugs, the build date should be reported on every ticket - this is very important! Build dates should be displayed using some form of debug text on the interface

Debug builds should also be used rigorously during the testing process to minimize time spent playing the game to unlock data. If you want to test a feature at the end of the game, don’t force your tester to play through an hour of content before they can unlock it and test it. Displaying memory and the frames per second rate in a debug build is very useful when looking for memory leaks (derr).


The Do’s and Don’ts of QA Reporting and Testing


A final few notes on QA reporting and testing:

    * Never ignore an issue - always report everything, even trivial issues. If possible, interrupt what you are working on to do so otherwise if you put it in the back of your mind you’re bound to forget.

    * Be comprehensive - do not assume something will work, know that it does work, every single facet of it.

    * When working in a small team where there is no dedicated QA then QA becomes the responsibility of everybody. If you see an issue, report it. If its an issue for yourself to fix add it it to your to-do list.

    * Streamline your to-do lists into your tracking system. You should all be able to assess where all the bugs and tasks are at any given stage and who’s working on them.

    * Remember QA and Production go hand in hand!

    * Don’t spend too much time getting caught up with QA! Find a balance where minute QA detailing does not impede your more important work of getting the game done!

    * Do NOT just write tickets for yourself, write the ticket with an adequate description so any layman can understand it. Not only is this important if someone else is responsible for the ticket you’ve created but when you are doing regression testing you will be able to remember exactly what the issue was!

    * Spend the first half of the week adding features Test new features on Wednesdays Aim to have bug fixes out of the pipeline by the end of day Thursday Re-test fixes and add any additional polish on Friday!

    * Keep in mind prioritize your QA around your sprint and milestone production schedules but try to allocate at least one QA task a week

    * Share the tasks. One person per week should really be spending half a day testing the features that have been added recently

    * When you add a new feature or update a feature that you know will have a compounding effect on a current system, allocate a Test Matrix check of that system after it has been implemented



If you follow the recommended practices and process detailed in this report you should be staying on top of your QA process on a week to week basis. You will have no fear of massive amounts of QA grind work to be done just before release and you are more likely to release bug free.

I hope these tips and hints have been useful, these practices certainly changed how I approach development. If you have any more questions hit me up at [email protected], tweet us at http://twitter/anoamlousint or join us at http://www.facebook.com/anomalousinteractive.

« Last Edit: July 20, 2011, 06:07:48 PM by Anomalous Interactive » Logged
ஒழுக்கின்மை (Paul Eres)
Level 10
*****


Also known as रिंकू.


View Profile WWW
« Reply #62 on: July 20, 2011, 06:01:02 PM »

that sounds like it might work better in the 'tutorials' subforum rather than on the frontpage
Logged

Evan Balster
Level 10
*****


I live in this head.


View Profile WWW
« Reply #63 on: August 21, 2011, 05:58:24 PM »



The End of Us is a small flash game created as part of a 48-hour collaboration between Michael Molinari and Chelsea Howe.  I played it at a friend's recommendation; after I finished, I was left in awe and reconsidering a lot of the theories and ideas I've developed about games over the last few years.

The game is quite easy, and very quick to play through -- five minutes or less in length -- and very much worth your time to try.  If you're idle enough to be reading a gaming news site, you can spare the five minutes.  Go on; I'll wait for you.

When you've given it a proper look, hit the jump for some thoughts.



I've been fixated on storytelling in games for a good while.  Immersion, and its emotional counterpart, attachment, are critical to making the events of a game feel impactful.  Immersion comes naturally if there's nothing to break it, but attachment is far more difficult -- game designers' efforts toward it often fail.  That hallmark of game stories, "Your love has been kidnapped!", is a prime (if simple) example.  The player is told from the get-go to care about another character simply because the protagonist does, and this backfires.

For the longest time my thoughts were focused on finding ways of delaying storytelling and doing it slowly and subtly.  Give the player some time to become immersed in the game's world and identify with their character.  Then, with great care not to force the matter, introduce likable characters and let the player act out the protagonist's feelings toward them.  Many of my favorite games utilize this strategy to great effect.

However, it seems this might not be the One True Way.

The End of Us absolutely floored me by getting me attached to another character in the game in the span of sixty seconds.  Orange Comet -- I can't help but use that as a proper name -- enters the scene after just long enough to experiment a bit with controls.  An antagonistic introduction leads to a bit of playful fighting, then a competitive interlude.  Note the clever and subtle use of dynamic music to guide the player's emotions.

In the final sequence, we see the characters protect one another from danger.  This affirms from the game's side an attachment the player almost certainly -- if inadvertently -- feels at this point.  The titular "End of Us" comes as Purple and Orange hurtle towards a familiar-looking planet -- a fall only one of them can survive.  Whether or not the player recognizes this choice, the bitter ending comes to pass -- an aged, injured, and overwhelmingly lonely survivor sinks from the screen in unmistakable despair.

This extremely simple, surprisingly impactful story draws its power from a feeling of attachment -- one created not by means of narrative but by means of play.

Play?  Play?!  What a concept!


Check out Molinari's site for a few more narrative experiments of similar scale and depth.  (Short and deep, that is!)  I'll be following both of these developers to see what else they come up with.
« Last Edit: August 21, 2011, 09:40:12 PM by Cellulose » Logged

Creativity births expression.  Curiosity births exploration.
Our work is as soil to these seeds; our art is what grows from them...


Wreath, SoundSelf, Infinite Blank, Cave Story+, <plaid/audio>
Android-Music
Level 0
**


Musician, That's all.


View Profile WWW
« Reply #64 on: August 23, 2011, 12:42:37 PM »

Sorry guys, no image, video instead:


Hope this doesn't hurt much. Even if this article is poor, you may like the game itself! Cheers!

The End is a puzzle platformer where you collect stars, fight bosses via "Go" like mini games(the ultimate death cards) and get various interesting items! One of many pluses of the game is music - it's calm, clean, warm and relaxing. You can create your own customizable character, the choice of body parts is rich enough for anyone's imagination!

Gameplay is pretty interesting, while it's a simple platformer it has a great feature: shadows! Shadows play a big role in this game, especially if you cannot reach one or another platform: once you find a proper angle for a shadow and cast a spell, it becomes solid so you can easily pass a certain abyss or prevent your death in some cases. The game's world system reminds "Altered Beast" on GameBoyAdvance just a little bit!

Graphics are awesome as well - very accurate approach on animation, backgrounds are beautiful - each world represents something unique - junkyards, shadowy realms, even forests look quite different!

Another plus is social element - you're not alone exploring the mystic grounds of "The END", other players appear in the lobby quite often! Some players may also like Facebook integrity as well!

Overall great game, really worth a try!
Logged

http://georgedziov.com/
Try my new metal pack - http://gameprefabs.com/products/show/399
Game Developers O.C. - http://www.facebook.com/#!/groups/144438572289633/
ortoslon
Guest
« Reply #65 on: November 17, 2011, 09:30:05 AM »

Recent Good Knytt Stories #4

Ahead lie four platformers that can be beaten in under ten minutes each (by me, that is). As usual, you’ll need the latest version of Knytt Stories to play these levels.


1. Oxi by Harumbai is a hard level that packs great graphical variety and detail into ten screens and forces the player to backtrack just enough to appreciate them fully.




2. The Extinct Bird by Christian S., the easiest level on this list, maintains the feeling of hot pursuit with well-timed cues.




3. Super Juniland by Jerom is unforgiving. The soothing music loop might start to get on your nerves a hundred deaths in. Playthrough.


4. The Greying Tower by Talps builds puzzles around switches and predictable enemies. Playthrough.
Logged
MinskWorks
Level 0
***

Greg Pryjmachuk


View Profile WWW
« Reply #66 on: November 19, 2011, 07:43:05 AM »

I recently started a series of blog post on my very own blog about what I can do to broaden the appeal of adventure titles.

The Importance of Player-Environment Communication
http://gpryjmachuk.wordpress.com/2011/11/18/239/

Takes a look at ways to best communicate different messages to the player, without using text and without losing any of the message.

Let me know what you think could be ammended, improved?

Thanks
Logged

J. R. Hill
Level 10
*****

hi


View Profile WWW
« Reply #67 on: January 12, 2012, 08:14:20 AM »



Hello friend!  Do you enjoy games from the infancy-stages of console entertainment?  Unspeakable carnage loosely justified by some kind of "story" about saving a loved one?  Partaking of fine and exotic seafoods?

If so, you need to check out Abobo's Big Adventure.  This shouldn't-be-free flash game is a successful combination of humor, mayhem, nostalgia, and love.

Abobo is just plain ridiculous.  In terms of pure comedic value, the game is the best thing to hit the indie scene since Barkley: Shut Up and Jam: Gaiden.  The game revolves around protagonist(?) Abobo's absurd propensity for violence, and never fails to take the route of most-possible-casualties.  It also walks that fine line between crude humor and that more sophisticated, internet-refined version of blatantly offensive humor.



//Idk how you embed these things lol

The game blends gameplay elements from several classic NES titles, and references everything from Back to the Future to Gizmoduck.  If you were born in the 80s, this game is going to mine long-forgotten gems from the dark recesses of your memory.  After which, there's about a 50% chance you will destroy it with a firearm.  It's kind of like Old Yeller in that regard.

Lastly, aside from some hitbox-slash-timing-related glitches in the first level, the game is extremely polished.  The load time for this flash game is significant, likely due to the large number of audio files accompanying the many stages, bonus rounds, and cutscenes.  Abobo sticks closely to its NES-inspiration, but also boasts some great original artwork throughout.  The amount of time and effort that has gone into this title is evident in each level.

All in all, Abobo's Big Adventure is a game worth gushing over.

Gushing blood.  Blood everywhere.
« Last Edit: January 15, 2012, 02:56:11 PM by J. R. Hill » Logged

hi
ortoslon
Guest
WAT
« Reply #68 on: January 29, 2012, 06:39:47 AM »

Recent Good Knytt Stories #5

Here′s an hour′s worth of jumping, climbing and gliding. As usual, you’ll need the latest version of Knytt Stories to play these levels.



1. Snow Machine by RichardJ is short, scenic and devoid of challenge.





2. The Dying Core by Egomassive puts you through lasers, water, lava and spikes. Custom music tracks set the tone for each trial.





3. White City by Headgrinder has you exploring nooks and crannies of an abandoned floating city. Playthrough.



4. Do Not Pick Up The Key by Talps is a hard level about temptation. Do not watch the playthrough.
« Last Edit: January 30, 2012, 07:50:36 PM by Derek » Logged
Pages: 1 2 3 [4]
Print
Jump to:  

Theme orange-lt created by panic