• 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.
Sign in to follow this  
Followers 0
Ketschak

Murl Engine Released - A Lightweight Native C++ Cross Platform Multimedia Framework

12 posts in this topic

The Murl Engine is not only a Renderer but offers also a lot of other features e.g.

  • OpenAL based 3D Audio System
  • Input Handling incl. typical mobile input devices like location service, multi touch, gyro, accelerators etc.
  • Rigid-Body Physics Engine
  • Networking Support
  • In-App Purchase Support
  • Logic Processing Framework on top of the SceneGraph Framework
  • Support for OpenGL, OpenGL ES and DirectX
  • Resource Management incl. Multi-Language Support
  • Clean and transparent abstraction layer for all supported platforms

I don't think that you can get this with an open source scene graph library.

Not the entire framework is closed source. The whole platform code is open source and can be easily extended. Only the scene-graph core is closed source but even here we provide a mechanism to add customized nodes and objects.

I agree with you that we should better showcase the individual features and flexibility of our Murl and promise that we will improve this direction.

0

Share this post


Link to post
Share on other sites

I agree with colossal, I had difficulty enumerating exactly what's on offer. The information that you presented in your response to him should be made available on your website in a place that's hard to miss. It has piqued my interest, however.

0

Share this post


Link to post
Share on other sites

How well do you support keyboards (multiple, international or strange ones in particular) and USB game controllers (particularly enumerating, mapping and calibrating unpredictable axes, switches, buttons)? I'd like something more friendly than the low level Windows API but more general than Microsoft's arrogant assumption that every peripheral is an Xbox 360 - like gamepad.

 

EDIT: I looked at the API docs. My grades: E for documentation quality (all skeletal, Murl::RawKeyCode deliberately omitted), F for keyboard support (half bizarre and half undocumented) and D for joystick support (Microsoft style).

Given the halfhearted documentation and the missing Linux support I have the impression that you have gone public too soon with an unfinished and unproven engine; a showcase of finished games would give a better impression than a roadmap of important features that aren't available yet.

Edited by LorenzoGatti
0

Share this post


Link to post
Share on other sites

In regard to keyboards we support both raw keys and mapped vanilla keys.

For internationalization we generally support all Unicode characters.

Actually we created for South Korea a special version of the Game Crazy Rings with Korean characters.

 

The framework provides a nice abstraction layer for game controller support. The framework will support standard

USB game controllers and the XBox game controller. Other non standard game controller can easily be added to

the platform code if required.

0

Share this post


Link to post
Share on other sites

In regard to keyboards we support both raw keys and mapped vanilla keys.

For internationalization we generally support all Unicode characters.

Keys do not have "UTF8 strings", and keyboards do not have "raw" and "vanilla" keys.
If it isn't documented, your keyboard support doesn't exist.
For example, in which order does Murl::Input::IKeyboardDevice::GetKeys() return its undefined strings?
I'd like to see comprehensive code examples: configuring arbitrary keys, text entry, modifier keys, etc.

The framework provides a nice abstraction layer for game controller support.

No. It provides a straightforward simplified interface to the XBox game controller, which isn't adequate.

The framework will support standard USB game controllers and the XBox game controller. Other non standard game controller can easily be added to the platform code if required.

Now it definitely doesn't support generic USB controllers; and USB defines a standard, what nonstandard controllers are you talking about?
0

Share this post


Link to post
Share on other sites

keyboards do not have "raw" and "vanilla" keys.

 

According to our definition raw keys are the actual physical keys on the keyboard.

 

The definition for raw key codes can be found in the file murl_raw_key_codes.h:

 

enum RawKeyCode
    {
        RAWKEY_NONE             = 0x00,
       
        RAWKEY_ESCAPE           = 0x01,
        RAWKEY_1                = 0x02,
        RAWKEY_2                = 0x03,
        …
 

There should exist a RAWKEY definition for every possible physical key. The list includes e.g. RAWKEY_0, RAWKEY_KEYPAD_0, RAWKEY_KEYPAD_NUMLOCK, RAWKEY_VOLUME_UP, RAWKEY_KANJI etc.

 

If you press on an English keyboard the key Y you will get events for RAWKEY_Y.

The same key is labeled with Z on a German keyboard. Nevertheless if you press the

key Z on a German keyboard you will get events for RAWKEY_Y because it is the

same physical button with the same key code.

 

If you press the two keys left SHIFT and Y you will get events for both keys RAWKEY_Y

and RAWKEY_LEFT_SHIFT.

 

To check for physical keyboard input, you can use the device handler's WasRawKeyPressed()method.

Logic::IDeviceHandler* deviceHandler = state->GetDeviceHandler();
if (deviceHandler->WasRawKeyPressed(RAWKEY_Y))
  do whatever is to do

In addition to WasRawKeyPressed(), physical keyboard input is also reflected by the IsRawKeyPressed() and WasRawKeyReleased() methods. During a regular keystroke, these methods return true in the following sequence:

  1.     At the moment of first pressing the key down, WasRawKeyPressed() returns true for exactly one logic tick
  2.     As long as the key is down, IsRawKeyPressed() returns true in every logic tick.
  3.     When the key is released, WasRawKeyReleased() returns true for exacly one logic tick.

This behavior is detailed described in chapter 01/tutorial 02/version 04:

http://murlengine.com/tutorials/en/_tutorial_chapter01_t02.php

 

RawKeys are typically used for control inputs in games.

 

Vanilla keys according to our definition are keystroke results after the operating system processed the key codes.

 

The result depends for example on your language settings. If you press the key Y you will get

lowercase y if the language is set to English. If you press the two keys SHIFT and Y you will get

uppercase Y.

 

If the language is set to German you will get z or Z.

 

You can use the methods GetNumberOfKeys, GetKey and GetKeys to get the UTF8 character representation

of the keys pressed in the most recent tick.

 

Vanilla keys are typically used if you want to enter text into an input field.

 

Simple Example:

 Logic::IDeviceHandler* deviceHandler = state->GetDeviceHandler();
    UInt32 numKeys = deviceHandler->GetNumberOfKeys();
    for (UInt32 i = 0; i < numKeys; i++)
        Debug::Trace(deviceHandler->GetKey(i));
    if (deviceHandler->WasRawKeyPressed(RAWKEY_Y))
        Debug::Trace("RAW Y PRESSED");
    if (deviceHandler->WasRawKeyReleased(RAWKEY_Y))
        Debug::Trace("RAW Y RELEASED");

 

 

It provides a straightforward simplified interface to the XBox game controller, which isn't adequate.

 

The mechanism for game controller input is similar to keyboard input or touch input. If it is not adequate for you, what is missing? 
 

USB defines a standard, what nonstandard controllers are you talking about?

 

We will support USB game controllers which are HID compliant. We don’t support USB game controllers which are not HID compliant.

0

Share this post


Link to post
Share on other sites

Keys do not have "UTF8 strings", and keyboards do not have "raw" and "vanilla" keys.

The question is what is reported by the framework, not what does a keyboard have.

A keyboard has physical keys, the framework reports key pressed/released state by so called raw keys via the Murl::Input::IRawKeyboardDevice interface.

You are right, the RawKey enumeration is missing on the Web-Site (we are still in open beta phase), but the enumeration can be found in the corresponding header file which is typically used during development.

On the other side every operating system does some kind of mapping a physical key to a localized character. Such a mapped character can be called vanilla key.

The Murl::Input::IKeyboardDevice interface reports these characters and yes of course, these characters are UTF8 encoded, think about e.g. a korean keyboard.

The framework do not report raw keys for non-physical keyboards e.g. touch screen keyboards on mobile devices. 

 

If it isn't documented, your keyboard support doesn't exist.

The methods are documented and the keyboard support does work on all supported platforms.

 

For example, in which order does Murl::Input::IKeyboardDevice::GetKeys() return its undefined strings?

In the order the keys are reported by the operating system (probably the order the keys are pressed).

The strings are defined by the corresponding pressed key.

 

I'd like to see comprehensive code examples: configuring arbitrary keys, text entry, modifier keys, etc.

The framework simply provides exactly the same information on all supported platforms.

Configuring arbitrary keys and other features are not supported by the framework.

A sample code for using the IKeyboardDevice is available in the Tutorial section in Chapter02 Tutorial01.

 

No. It provides a straightforward simplified interface to the XBox game controller, which isn't adequate.

Joystick support is currently not implemented in the framework's platform code.
n the current stage the framework is focused on mobile platforms which do not support joysticks by default.
The joystick interface is unfinished and prepared for supporting gaming consoles and pc in the future (the current interface is based on a N64 controller).
0

Share this post


Link to post
Share on other sites

So the Engine fully works with Windows 7, Windows 8, and Mac OSX? My project is a game designed for those Operating Systems.

0

Share this post


Link to post
Share on other sites

So the Engine fully works with Windows 7, Windows 8, and Mac OSX? My project is a game designed for those Operating Systems.


Yes, you can develop a game for Windows 7, Windows 8 and Mac OSX with our engine.

Please note that at the moment we only support Win32 (in regard to Windows). This mean you can build a Win32 Application/Game which will run on Windows XP and on Windows 7 and on Windows 8.

In the future our framework will also be able to build WinRT Applications. Support for WinRT is scheduled for Q4-2013.

Further information regarding WinRT can be found here: http://en.wikipedia.org/wiki/Windows_Runtime
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0