Hello all,
After thoroughly reviewing subclasses and superclasses in Java as well as having some difficulty finding a half-decent map generator (believe me, I’ve tried a lot), I have finally decided to make one myself. This is a simple proof of concept and certainly not finished, but here is my first prototype. Because I was able to plan it out beforehand, the code was surprisingly simple.
I am, however, rather frustrated at the lack of my ability to create a save state. I was considering attempting to create some sort of array that kept all the data but such a system, while technically possible in Flowlab, is not very practical at all. If anyone has any ideas on this, please let me know! Until then, happy map making, and if you have any ideas for sprites I should add feel free to ask. SAVE SYSTEM CREATED
Side note: I was going to name it something much catchier until some quick google searches found that it was an eponym for a brand dealing in… not child-friendly products. Flow-Map is most likely not permanent and I would love to hear other ideas.
Another side note: no, Crunch Time is not dead, I need to finish college.
This is definitely a pretty neat concept. I know it’s still a work in progress, but I would like to see a sort of grid or snap to grid function to help align props more efficiently and faster.
I know a click and drag might take a bit, but I feel it would definitely help speed up the moving process since the objects seem to take a bit to move around using WASD.
I’m also not too sure how to exactly handle a saving system, or at least a saving system to be shared. It could be possible to create a sort of code or map seed, but I don’t think you can copy a huge code within a flowlab game unless the player memorizes and writes down the entire thing.
A normal saving system would require a save behavior per object. Since they are spawned objects, you would need a save behavior in a separate object to keep track of how many were spawned, the rotation and location for each one, requiring multiple save functions so it may not be the easiest task. I’m sure there may be some easier way using lists or something.
Yeah, lists would probably be the best way to go. I am making a similar type thing, but its about mechanics and wiring. Right now I am working on the wires, and how they interact with each other. I am using a system that is held in a list, similar to a OBJ file. (Thanks to TheBrickCentric for explaining it to me, and helping me on the way.)
Thanks for the responses guys! I am certainly considering doing some list stuff. It would be a lot easier scripting it and unfortunately I do not believe Flowlab has an easier way than scripts. It would take a lot of values per object but I think it is possible. If anyone has a better idea let me know please, this could be brutal to do then find a more efficient method after. Also, I will certainly add some mouse controls.
Alright, drag clicking is now implemented. Double-click to drag. A simple debounce-style system did the trick with minimal issues. Time to tackle… save systems.
Here is something I would recommend adding.
This is an example I made a bit ago and it allows you to be able to click and drag the camera around the map and also has zoom in and out features as well. I don’t know how large of maps you plan this example to make, but if it’s anything larger than the screen, this would probably be useful. That way you can click and move the camera around to view the overall area if it bleeds off the screen. I was wanting to make a flowlab version of AutoCAD at some point, so I started with this example, but I never continued it further.
Thanks, I’ll look into that! My first thought was having a cute little tiki totem you could drag and drop as a camera but I will consider the other options as well.
There is now a save system. It was actually much easier than anticipated. Making multiple saves is going to su.ck, but for now everything works. You can now save as many objects as the Flowlab data type limits can handle!
If you are wondering how, I tried to organize my code fairly well and am planning on adding more comments. Here’s the essay format for the 1.5 people who asked:
Each variable type is organized into a separate number list. There is one for each of these: x, y, sprite selection, object type, and rotation. Getting the data is super easy, barely an inconvenience, as all blocks have a parent, or superclass. Basically that means any code in the parent is automatically copied into the children. Don’t think about the analogy too hard. The parent block (big red in the editor) has code that when a message is sent telling it to save, it sends each variable to the save block. every object in the game only needs 1 message sent since all children share sent messages with parent types! This is a vastly more optimized way than CodeAlpaca’s version. Here is where it gets really interesting though, and what CodeAlpaca found out too. All the save messages in both of our examples are sent at the same time. How, you may ask, does the computer know that object 1’s X variable should be paired with only object 1’s Y variable? Well that, my deae Watson, is due to object-oriented programming. You see, most larger programming projects separate code into different files. These files all run in synchronicity. For example, Minecraft would have different files for player code, zombie code, and chicken code. Then for each chicken spawned, it makes a copy of that chicken code. Every frame (or for Minecraft, tick), when the computer runs the code for chicken 1, it does all the code at once before moving on to chicken 2. This is object-oriented programming. Thus, program 1 finishes before 2 even though the player never knows that, because it all happens on the same frame. Flowlab does this too! Thus, all the variables for object 1 get sent simultaneously, allowing us to simply ask the computer for the first set of variables from each list [or array] to construct object 1. This pandora’s box has been solved by basic computer science principles. Yay!
Update:
I was rather sleep deprived when I first made the system and although it miraculously worked with minimal bugfixing, the current state of things is much better. The save load system is now simplified into a 3-step system. This just allows previous builds to load quicker. I also added some new sprites, fixed the totem shadow, and increased camera speed. I am open to suggestions on how to continue improving this. For now, I will continue to work on adding more sprites to the five categories and adding a second set of objects that will be larger than the first, such as wagons, ditches, thicker walls, and more. Thanks all and I will try to keep this updated!
