FreeGameDev

Sometime last year, I completed a somewhat complicated game and attempted to sell it. The release didn't go so well, so I went with the "get a real job" plan instead (which worked out a bit better).

So... I have a large project on my hands, in a playable and functional state, with content, reasonably consistent graphics, and some semblance of sound. I don't actually want to see the project die, so I am considering a full free & open source release (game, code, content, tools, and plans). However, since that is also a lot of extra work, I would like to know first whether or not I might find interest in the project.

The game is Orthot II - a 3d transport puzzle (like Sokoban & Chip's Challenge, but with an extra dimension). It includes a complete level editor & loader.

It looks a bit like this:


The [still commercial] demo is available at my website:
http://orthot.eketech.com

If you think it looks like a worthy project, please post on this thread - If it looks like people are interested, I'll shut down the sale, post a "freeware" release, and start planning the open source transition.



Incidentally, since I needed everything manageable by myself (for solo development), the project is also intended to become a Game Creation System for minor/solo projects (focus on tools which work well for non-expert use, so that things like lack of artwork don't have to be a crippling hinderance)

Hi,

Your game looks quite interesting! I also have a similar idea --- a suspended attempt to combine Sokoban (more exactly, Puzzle Boy) and rolling block mazes together (see my GitHub page).

Hi Eketek (saw the post about the misspelling ) and welcome!

Your game looks pretty interesting, and I agree with you that it would be a shame to see it die slowly on your hands if it's not doing too well as a commercial product. Having it as an open source project could hopefully give it a second life, see it integrated in Linux distros repositories if it is cross-platform and has no NC or ND clause for the art assets, etc.

Though looking at the website, I see that the demo requires the Unity3D web plugin, which raises a concern - if it's being developed in Unity3D, which is a proprietary platform, you'll likely find a lot less interest/resonance in the free software community where most favour using libre engines (and to some extent libre tools, but that's not a strong requirement). If the game is open source but can't be built by any interested party (even if Unity3D is "gratis" at this scale). It does not mean that you shouldn't open source it though, just that it will be a difficult to see it really thrive as a community project; it might find some interest in the Unity3D community though if some of them are free software-inclined.

If my guess about the engine is right, an alternative could be to reimplement it all in the quite similar but MIT-licensed and community-driven Godot engine (Disclaimer: I'm one of the upstream developers). But that would likely be quite a lot of work. On the other hand if you open source your Unity3D project, it could also be that someone else proposes to reimplement it in Godot (or Uhro3D or any other libre 3D game engine). But that's of course very hypothetical.

Note also that open sourcing your game does not means that you can't continue to sell it. it's of course less compelling to buy something that you can get for free, but most of the time building a game from source is not something that everybody does easily, and some will gladly pay $5 (or more, but I'd try the strategy of low price + many customers instead of high price + little customers - with some message explaining that it's a libre games, but that sold copies support its further development) to get binaries for a libre game. See e.g. Wyrmsun on Steam (which is GPL'ed with CC and public domain assets, and no NC clause either) or Tales of Maj'Eyal (also GPLv3 with libre assets, apart from the sprites which are commercial but allowed to be redistributed with ToME - I would not advise such a restrictive clause for your game though).

Hope this helps
Feel free to ask if you have any question.

Unity3d has been on its way out of my project for a while now, and its replacement is considered a high priority (it restricts a major project goal, produces excessively large builds, and wastes a lot of power when there isn't much else for it to do). I already do my own graphics and asset management, and, where I haven't been too rushed, have abstracted their API away from game logic. I was thinking I'd just throw everything directly at OpenGL.

It reminds me of Puzzle Moppet: viewtopic.php?f=22&t=3221&p=31812&hilit=puzzlemoppet#p31812

I have basically decided that Orthot II should become an open source project. But it isn't quite there yet. However, as an open source project, perhaps that's how it will get there... !

Anyway, the plan is to start simple. I don't want to put my old Win7 drive back in my computer and boot it, just to strip out some lazy DRM, so I'll do the next-best thing: I'll cancel the sale, add a free key to the commercial distribution (which includes the game, the level editor, and a very useable 3d mesh editor (though it can't be used presently to add custom graphics without a rebuild), then call it free, post an announcement, and worry later about whether or not anyone is actually interested.

Afterward, the entire Unity project will be released under some OS licence and hosted somewhere, and work will begin to drop the Unity dependancy.

If the project gets a lot of attention, the next step should probably be to re-design it and switch from C-Sharp to C - for performance, simplicity, and perhaps to make the project feel a bit more free. (actually "a lot of attention" might instead result in some existing project getting extended/improved [if needed] to implement my workflow, then used as platform to rebuild the game)

Update: The first step is done - the sale has been cancelled and I am now distributing it free of charge from my website (http://orthot.eketech.com/___release.html).

Hi Eketel,

Thanks for your kindness! I have download the full version and tried it

acme_pjz {l Wrote}:Hi Eketel,

Thanks for your kindness! I have download the full version and tried it

Hopefully, it has been interesting and fun.

Keep in mind, the entire project was designed for solo development and (at least where I took my time) extensibility. There are likely to be some interesting features to find if you want to play around with it and think about things you could use it for.

A level editor and mesh editor are included, if you want to take a look at them -press 'esc' ), then click the edit button at tge bottom of the menu that appears (which might be partially cut off, since I didn't anticipate every UI issue). They should help you understand where I want to take the project (I'll post the docunents on my site later, though except for the text-based configuration [which the docs cover], both editors should be pretty easy to learn by experiment).

Also, the game has a lot of hidden complexity, particularly in the movement engine (complex collision resolution, gravity, portals, force propagation, and surface interactions, all quite concurrent). project was designed for solo development and (at least where I took my time) extensibility. There are likely to be some interesting features to find if you want to play around with it and think about things you could use it for.

A level editor and mesh editor are included, if you want to take a look at them -press 'esc' ), then click the edit button at tge bottom of the menu that appears (which might be partially cut off, since I didn't anticipate every UI issue). They should help you understand where I want to take the project (I'll post the docunents on my site later, though except for the text-based configuration [which the docs cover], both editors should be pretty easy to learn by experiment).

Also, the game has a lot of hidden complexity, particularly in the movement engine (complex collision resolution, gravity, portals, force propagation, and surface interactions, all quite concurrent).

Hi,

I'd like to report some bugs:

* The portal from world 3 to world 1 doesn't work
* Also, there is a portal in world 3 doesn't work (on the left hand side, second to the highest one if i remembered correctly)
* The final big cubic maze level has a bug: if you reset in this level the game crashes.

I have another question: it looks like that there are 3 or 4 levels in the demo version don't appear in the full version. Where did they go?

Also, the game has a lot of hidden complexity, particularly in the movement engine (complex collision resolution, gravity, portals, force propagation, and surface interactions, all quite concurrent).

I agree with it. When you proposed a lot of different types of tiles and want to put them together, things get complicated and buggy.

About "portal" bugs, I was almost worried there. Those where "teleporters", and it was just level linking errors (I should have prevented packaged data from being able to reference anything not in the package without at least a warning).

The maze generator crash on reset is a much better bug. I'll have to look into it sometime. Fortunately, it shouldn't affect anything other than that level...

The levels which are unique to the demo where added to the demo after the game was finished, to fill it up a bit better and show some extra features. I'll post those levels somewhere on my website later.

The complexity should be fine. It has been heavilly tested and is isolated from anything that doesn't involve local movement. There are some weird results, but these generally involve situations which where ambiguous at the design stage.

Wow this looks really neat!

I found some time, have gathered the sources for my game, and posted some editor documentation and some 'missing' puzzles on my site.

Editor docs:
http://orthot.eketech.com/docs.html

Extra Puzzles:
http://orthot.eketech.com/puzzles.html

--------------------------

The transition is going to either take a long time or be a bit complicated (or both). The plan right now is to keep my c-sharp code mostly as-is and replace Unity3d with equivalent usage of OpenTK. Fortunately, all I did with Unity was set up an empty scene with a few entry points attached, then used Unity as a library (no "unity" scenes, prefabs, assets, and whatever else to deal with).

Hi,

Your game looks very interesting and I downloaded the full version two weeks ago. When concentrating on trying to solve puzzles, I found many levels designed so ingeniously that I can hardly put it down. I really like this game very much and hopefully it could get more and more attention.

On the other hand, I am going to design some levels using your editor tool with my friends. Each of us is interested in it and this will be pretty absorbing.

Excellent. I will have to release the packaging tool as well, and write a document to go with it (so you can organize them into something a bit more coherent than single files tossed into an editor workspace, and access a few more features).

It should also enable the text boxes, level-set progress flags, and a partial MusicXML importer (though due to incompleteness, you'll be stuck with the default single-voice semi-random synth parameters for now).

Also, if you want to know how far this project branches out: At some point, a revision of a simple sound effects generator led to what seems to me to be the first use for sound synthesis of instantaneous magnitude shifts (for nearly unrestricted rampless volume change for "in-voice" percussion) and polynomial splines (for tone generators). Sometimes, it even produces nice results...

I recently resolved about 2.5 years worth of indecisiveness over what to do with my game. The decision reached is to re-write it in HTML & JavaScript, and use THREE.js as a rendering interface.

Development is moving along nicely. The first visible improvement over the old version is graphics. Terrain meshing and shading is a lot more versatile:

Hi,

I'm happy to hear that the development is still going on. The screenshot looks impressive. It must be an enormous work porting the game from C# to JavaScript.

acme_pjz {l Wrote}:Hi,

I'm happy to hear that the development is still going on. The screenshot looks impressive. It must be an enormous work porting the game from C# to JavaScript.

I think that the thing that makes that screenshot nice is the system I came up with to define, parameterize, and control the shader that I was testing:

{l Code}: {l Select All Code}

var FG_tex = await libek.load('textures/wall_8bit_fg.png')
var BG_tex = await libek.load('textures/patterns.png')

FG_tex.magFilter = THREE.NearestFilter
FG_tex.anisotropy = 4
BG_tex.magFilter = THREE.NearestFilter
BG_tex.anisotropy = 4 

let FG_Color1 = new libek.shader.ManagedColor("yellow")
let FG_Color2 = new libek.shader.ManagedColor("white")
let BG_Color1 = new libek.shader.ManagedColor("orange")
let BG_Color2 = new THREE.Color("green")
     
let material = libek.shader.buildVariantMaterial("standard", {
  map:FG_tex,
  edgeinsetcolor:FG_Color1,
  bguv:"uv",
  roughness:0.6,
  metalness:0.1,
  sample:tt`
    vec4 mc = texture2D( ${FG_tex}, vUv );
    vec4 bc = texture2D( ${BG_tex}, bguv );
    vec3 fgColor = vColor*mc.r + edgeinsetcolor*mc.g + ${FG_Color2}*mc.b;
    vec3 bgColor = vColor*bc.r + ${BG_Color1}*bc.g + ${BG_Color2}*bc.b;
    sample = vec4(fgColor * mc.a + bgColor*(1.0-mc.a), 1.0);
  `
})

(A major focus with this project is setting up components for a toolchain and framework which I think would work well for solo programmer-artist projects)

The project has recently passed what I consider to be its first critically important milestone (portals - a very complex feature which necessitated a very thorough definition of all motions and an unusually high level of complexity in the graphics and animation handling).

Presently, the game has these features partially or fully implemented:

Rendering, resource management, and a lot of boilerplate code
Mesh loading (loads Wavefront '.obj' files with runtime material assignment)
Terrain mesh generation & texturing
Internal puzzle data representation
Puzzle data parse/load [from the previous version] (only partially done - most elements have not yet been implemented)
Puzzle/Scene load, reset, and unload
Core puzzle functionality: Main loop, movement, topological queries, and events
Animation (partial - the core functionality is in place, but most of the animations are not [and all of the animation is of the maybe-placeholder variety])
Puzzle elements can move, fall, and interact with each other
Puzzle elements: Walls, ramps (stairs), ladders, portals, and scene-portals

Most of the puzzle elements are unimplemented, I have not yet done anything about sound, and the project is dependent upon data and the editor from the previous version. The code is a bit messy and a lot of my plans are undocumented and may need to be prodded out (hitting that critical milestone while I was still motivated was far more important).

If there is any interest in collaboration at an early stage (or at least an opportunity to start looking and poking at the source code and documentation), I think I am nearly ready to set up a repository and initial commit for the project.

Hi Eketel,

I'm looking forward to the code repository of your game! Although I'm not familiar with JavaScript, maybe I can't help with the coding.

I set up a repository for the project:
https://github.com/Eketek/orthot

I am not yet ready to deploy it as a web application, but if you download a copy, "o3game.html" will run the game. "orthot/orthot.js" contains the main entry point into the game code (the anonymous function passed to jquery). The documentation is ... mostly in my head.

I got a lot done over the past couple weeks. Recently implemented puzzle elements are: Regular blocks, crates, ice-blocks, ice-floors, keys, and locks. The main movement logic is in place (~2000 lines of code so far), is doing what I want (integer-interval physics with well-defined rules for movement and collisions), and is even far superior to what I wrote in the previous version. All of the puzzle elements implemented so far behave close enough to the previous version that the puzzles from the previous version using them work the same.

The game should be playable at a basic level (comparable to an early alpha build) once gates, buttons, wildlife, exit points & completion/progress, and tool-tips/text boxes are implemented.

Seems very cool!
Any chance this could be extended to work with AFrame WebVR?
See: https://aframe.io/docs/0.8.0/introducti ... reejs.html

Julius {l Wrote}:Seems very cool!
Any chance this could be extended to work with AFrame WebVR?
See: https://aframe.io/docs/0.8.0/introducti ... reejs.html

From a cursory check, it looks like A-Frame already uses the same objects as Orthot, which would make integration fairly simple if interoperation is only about importing models and animations or scripted components. Higher level interaction would be a bit tricky, because all moveable objects need to use instantiable and independently transformed/positioned intermediary objects (to allow things to pass through portals nicely).