HOME DOWNLOADS PROJECTS DOCUMENTATION CONTACTS

Learning curve

Intro

NOMRHIS is a protocol of browsing of interactive multimedia content. The content itself may reside on local filesystem as a package file or on server as network service.

So the following learning steps are designed to give quick overview of all general components of NOMRHIS first. And only after that diving into details. Although you may consider passing learning steps in different order.

I. Overview of standalone mode

1. Installing client

For standalone mode you only need to install a client program Kernel Panic. See part I on Installation page for instructions.

2. Standalone mode examples

Download level 1 examples from Example pack page. Unpack the archive somewhere. Read main README file most carefully. And now you should pass examples in numeric order by reading REAME files first and then executing and playing with each example. You don't have to dive into source code yet.

II. Overview of network mode

1. Installing server and plug-ins

For network mode you also need to install a basic server NomrhisD and at least one plug-in module (server is worseless without plug-ins). In our case the plug-in module will be Lua binding. See part II on Installation page for instructions.

2. Network mode examples

Download level 2 examples from Example pack page. Unpack the archive somewhere. Read main README file most carefully. And now you should pass examples in numeric order by reading REAME files first and then executing and playing with each example. You don't have to dive into source code yet.

III. Learning subsystems in details

0. Method overview

You have got general overview of NOMRHIS. Now you will most intensively use Examples and Reference manuals.

Here are general learning technics for particular subsystems:

  • Reading overview of subsystem and then reading API reference (like it is fascinating science fiction book - you read but not digging into details) which you may consider optional
  • Taking some example as base and modifying it somehow referencing to API reference
  • When you've played enough with examples you should try to set your own goals and write something from scratch yet referencing to reference manuals. You should start with writing standalone application (while learning) since without using graphics at all network site will look like black screen

1. Learning graphics

Graphics related functions may be divided into 4 groups:

  • Frame viewports setup
  • State setup (fixed setup and GPU programs setup)
  • Raster operations
  • Geometry rendering operations

See Frame rendering overview page for more details. In the end of that page you will see a list of graphics related modules.

2. Importing models from 3D modelling and animation programs

I guess you aren't going write all models in code:) So you should learn more about models on this page and then visit Blender exporter page so you could put models from Blender into your sites.

3. Working with local filesystems

Repositories are commonly used to store scripts, images, models and other data. While stand-alone repositories are read-only, local repositories grant write access also. See FS storage page for more details.

4. Few more subsystems

To finish overview of subsystems you have to read Input, Font_decoder, Image, Utilities, Network and Module manager pages.

5. Writing UI

I'll have to somehow disappoint you: widget system isn't complete yet. You may play with early stages at Widget system page.

IV. Writing something

Now examples are over, theory is over. Time to write something yourself. For now you may consider taking an example closest to your idea and turn it into your project. After some practice it won't be necessary. You'll need refer to Reference manuals very often. Especially to Client API modules

V. Planning complex project

If you've taken NOMRHIS seriously and planning to do something big here's the list of things you may consider thinking about:

  • Resource syncrhonization. To keep local repository up-to-date efficiently you may consider package version system. This is achieved by storing file list as file itself and using package status files.
  • User interface. That usually means dealing with widget system. You may require writing custom widgets for your project. You also may consider designing your own style for specific or full set of widgets. And of course user interface is tightly bound to general logics
  • Level mechanics and event system. Whether you use 3D, 2D or some really weird mechanics you'll probably need to count same things on server and on clients (so called prediction). You'll have to develop event system carefully. You'll have to think about not allowing client to cheat. And you may consider using datagrams and clock synchronization in real-time mechanics.
  • Logics. Usually application maintains a number of screen layouts. Each of them are linked together in specific way. Layout usually consists of level frame and UI overlay. E. g., registration screen, login screen, main menu, level 1 with HUD, level 2 with HUD, high scores menu, credits, etc. Since desktop instance creation is fast it is recommended to create brand new desktop and level instances at each screen layout switch. That would be a kind of encapsulation.
  • Storage. Most long-term data is stored on server. To consider storage technics at least you have to understand if one or multiple servers are to be used for storage. SQL database is fine for single server while NoSQL technologies are widely used for distributed storage. As an exception you may consider storing individual settings on client side. But if user enters your site from many hosts this may be considered impractical.
  • Service maintainance. This may also become a problem for big systems. Updating service to new version, raising new servers, raising servers after failure. Extending distributed storage in consistent way. You may even reconsider server topology when it comes to tough buisiness.
Documentation
Learning curve
Installation
Server configuration
Reference manuals