Lix > Lix Main

2018 roadmap

(1/2) > >>

Simon:
2017 -- 2018 -- 2020 -- 2022


Hi,

Lix has progressed nicely throughout 2017, I've hit all my high-level goals:

* Guarantee 100 % solvability for lemforum, Rubix's singleplayer, NepsterLix, ClamLix.

* Improve the worst tilesets, throw out my 2006 programmer art.

* Add music, ship with some free tracks, allow to add your own tracks.

* Implement the networking mode. Play games with forumers who weren't around in 2010-2014 to play L++ or C++-Lix multiplayer.

* Enable Linux packagers to create system-wide installable packages.
Of course, some tilesets can still be improved, the networking UI should offer spectators to view other teams' skillsets, ..., but I've still managed everything I expected.


This leaves no clear high-level goal for 2018. What should be the focus of development?

Even without one big core idea, you can help enourmously: Look through the Lix bugtracker. Its first page shows only 25 issues, please look through other pages than the first, too. What are the worst issues that I should prioritize?

-- Simon

Forestidia86:
Some suggestions:

Bugs:
- RAM-issue on Windows, that leads to crashes on large maps

Feature Wishes:
- Undo button for the editor
- Skill blueprints
- Better replay management (multiple issues in the issue tracker)

Then there are a couple of possible physics changes: tumbler, blocker, builder, that you seem to have planned.

Simon:
Thanks for the suggestions. All four are large endeavors, and I'd attack them in this order:

Replay management: This can improve in small steps and is the easiest, even though I have to make GUI, which takes long to get right. For a selected level in the singleplayer browser, the game should offer all replays installed in the standard replay tree. On manually saving a replay, you should optionally enter a name that overrides the timestamped default name. Replays should be movable/renamable from the replay browser.

Skill blueprints: This can also work in chunks, with a dumb implementation at first that merely draws a diagonal line under the miner. More powerful blueprints would simulate physics and then visualize the result somehow without really drawing permanently to the land; this might be tricky to make efficiently. We'll see.

Undo: The original idea was to use the object-oriented command pattern for this, but the code is expensive to refactor towards this. If I make this, it'll be a naive implementation with lots of savestates. We'll have to measure RAM, but since these savestates (levels) won't eat any VRAM, there should be no swap-to-RAM-then-crash here.

RAM crash: This is the hardest to fix because, to my knowledge, I must hack the VRAM map apart into several VRAM bitmaps, and then savestate only the changend parts. This will touch a larger chunk of already-complicated code. I'm considering to defer this because our workaround -- avoiding gigantic maps -- is sad, but at least it has prevented all crashes during the 2018-03-11 session.

-- Simon

geoo:
The one thing I've been wanting to see for a long time (and that has been discussed multiple times) would be neutral lixes, and individual pre-placed lixes.

Thread on gameplay: https://www.lemmingsforums.net/index.php?topic=2899.0
I think there the conclusion was to have the following rules: if there are neutrals on the map, only neutrals count. Together with the current rule of instant nuke if overtime is 0 this would also emulate the "Capture the Clone" mode from Clones. In singleplayer I presume we'd want everyone to count?

Thread on level format: https://www.lemmingsforums.net/index.php?topic=3226.0
As mentioned there, the simplest option is to keep the hatch rotation as before, and have a special hatch version for neutrals. Either with a separate field about number of neutrals to spawn per hatch, or just having the same number of neutrals as player lixes. (In the editor, there could be a neutral copy of each hatch.) The other option was have each hatch indicate which player it belongs to, and save that in the level format. (Priority keys change the tribe of the hatch, including neutrals.) It'd make the editor a bit more user friendly (with no other hatches changing tribe when you change the tribe of a hatch), but would need extra code for backward compatibility. I believe there was also a proposition (especially in view of asymmetric maps) to give each hatch also its own lix count and spawn rate, but that would probably be a UI nightmare and could be reasonably substituted for with pre-placed lixes.

Pre-placed lixes in the level format and editor: Same as hatches, in that it could either use the rotation system + special identifier for neutrals, or store the tribe for each lix.

Simon:
Neutrals and individual lixes: Yes, especially neutrals are the most promising physics addition. Both require physics and format changes. Ideally, I'd merge the tumbler rewrite from summer 2017 into the next physics version, but I would like better physics unittesting before I merge the tumbler rewrite. The yak is hairy.

The danger is that I postpone physics indefinitely.

-- Simon

Navigation

[0] Message Index

[#] Next page