This is mostly dedicated to people like pmprog and JonnyH who know about programming and the framework of OpenApoc more than me. Currently I'm actually limited in time I can contribute to the project, but since a lot of the game is already "done" in my head, I spend all spare time just implementing everything I already thought of. I could try tackle the problems I'll list here, but that would be very inefficient allocation of my time, as I can do much more by just doing more of the crucial features I already have thought through. And I've seen at least pmprog saying he wants to do something useful. So, I'm going to list stuff here that hopefully someone else can implement. So, what we currently need is: 1) Bug tracker Using Github Issues now. 2) Tooltips for UI This game uses them heavilly. 3) Proper rendering This one I might tackle eventually but if someone can figure out an exact algorithm that would be wonderful. I did a post on this http://openapoc.org/threads/task-rendering-algorithm.211/ and got an advice to draw stuff diagonally, but that answer did not account for 2x2x2 units moving through tiles. 4) Parallel computing The way we do it now is we do everything one after another, while it obviously can be done at once. Examples of what we could compute parallely: a) projectiles cannot collide, so we could just move and calculate collision for every projectile, and then apply every projectile's effect b) units's ai could think for every unit at once, as all that AI does is issue orders to units, and AI does not need the information on what are unit's orders to function c) rendering? I mean gpus are parallel now and they somehow do their work properly in terms of z-buffer, right? like they somehow manage to render multiple stuff at once and have it properly overlap based on distance to camera, we can do the same with sprites? or must sprite renderers all be single-core? d) updating map parts and units, units do not directly work with map parts, they work with parameters stored in tiles, parameters like "what's the highest object I can stand on, or can I pop my head there, or will it support my legs if I turn off jetpack". We can update map parts all at once and then just update those parameters all at once, this would allow us to do both units and map parts at once on different cores e) Map parts looking for support, this is huge and makes game hang for a big when you blow up something enormous, parallel would help a lot here. I remember JonnyH tried to do parallel for projectiles but for some reason disabled that because something wasn't thread safe. Can we go back and try to re-implement that? What was the problem? 5) Review and rework of code guidelines. Someone good at programming should review what's going on, look for what code guidelines we're missing, rework them, and then I would go and rename /rewrite stuff to fit that. What I'm talking about is for example in function "updateFalling" I'm checking if the unit has fallen into another unit, and if so, checking if is a brainsucker and if so, checking if the unit it fell into has a suckable head, if so, attach to it. Should this be forbidden, should we have a guideline like "function must contain only simple logic, and any complex logic must be separated into simple blocks", and thus this function would be separated into "updateFalling", "processFallingIntoOtherUnit", "attemptBrainsuck"? Or for example are some classes forbidden to do some things? For example, should BattleUnit play sounds, or should it send some event of "emit sound" kind, which the UI processes and plays sounds? Is BattleUnit supposed to access framework directly? I don't think we have that in guidelines now, and some coding has gotten a bit complicated due to that. I think a review and rework is in order, so that this (now quite huge) project stays easy to learn for new programmers. Oh and when we do that, I'll also rework all the variable names with "_" in them we have left behind from before camelCase was introduced. 6) Fix form borders Some forms have a minsize of 640x480 but size of 646x484 and have a border of 2x2. Some don't. This looks good but what if a user wants to play fullscreen 640x480? It will still have a border! I propose some way to change all forms to be 640x480, and add border in some other way (like, display a border under form if some tag is present on the form?) 7) Implement a storage class for categorised externalised engine variables. What I'm talking about is externalising things like max speed item can travel along XY when thrown, ticks it takes battleunit to move 1 voxel, projectile speed modifier, how many attempts pathfinding does before giving up, ticks between AI updates, AI priority multipliers for certain actions etc. All this should not be hardcoded but should be read from a file. And it should go in categories so there is a tree structure, at least 1 level deep. So it looks like AI Consts - AI priority multiplier for action: throw grenade - AI priority multiplier for action: fire weapon ... BattleUnit consts - Ticks per frame travelled - Ticks per frame turned - Ticks per debuff application ... UI Icons - Icon for squad arrow #1 selected - Icon for squad arrow #1 unselected ... 8) Figure out a better format than Xml for some (or all) our data files Currently saving battlescape takes an unacceptable amount of time because it saves arrays of 0's and 1's, and resulting file takes like 50 megabytes. Xml is not a good format for anything except small packs of data. It's definetly not to be used for: - game saves (those containing things like map part lists, arrays of data etc.) - game maps / tilesets / sectors - voxel maps We should figure out a new way to store stuff so that save/load times become acceptable at the very least 9) Figure out a better way of handling data to account for modding Currently several things hamper implementing modding: a) There is no way to delete something. How do I remove personal disruptor shields from the game? All I can do is make them useless, unproducable, name them "broken disruptor shield" and expect player to sell the stock. But I should be able to just have them vanish once player installed the mod. b) We don't separate types and templates from actual game data Everything is loaded on game start and saved in one place. There is no real difference between changing an AgentType (which should never happen in the game) or changing City's Vehicles (which is done constantly). Data should be separated, some data should load from data files and never change in game, some should be loaded changed and saved. This would allow us to mod data without it getting stored in the saves. Like, we would be able to change AgentType and have it affect the save that is loaded on next run. This would both allow us to have saves take less space, and have way easier time using mods (even turning on/off mid-playthrough which EVERYBODY will want). One other crucial example is dependencies and completeness of research. We change that directly in the data itself! What the hell? Shouldn't it be some other place where we track what's developed and what's complete? 10) I don't remember what exactly, but something about dependencies doesn't work in research and manufacture. Need to sort that out. 11) We need better lists. They should support mouse scroll, they should not immediately select item when you click on scrollbar, they should know how to scroll towards selected item (like when you open inventory for last agent in list of 30, list should scroll to make that agent the bottommost visible item). Also, we need multi-select lists for things like agent inventory 12) We need text input controls For renaming agents and bases and such. 13) We need to speed up rendering of objects tinted with full-alpha channel. I assume right now it multiplies colors while instead it should just fill the area. If I'm wrong and it already checks that then ignore. 14) We need to speed up rendering of primitives. Game uses a lot of lines and brackets and it seems to take a long time to render, can this be sped up? I mean it's just coloring some pixels, is that so resource heavy? I'm going to update this post with new stuff.