Download Stareater v0.6.1
Game preview is like a cherry on the top of data system rework. As the whole save format has been reworked, I've made save metadata more accessible. Previously the code had to read and parse whole save file to get save title and game turn number and when building list of saved games it had to do it for each file. Now it can read just first few lines from each file and read whole file only when actually loading a game. Preview data is also in those first few lines and it can contain whatever GUI needs to make preview image of the saved game. At the moment it contains turn number and star positions and colors but I can easily expand with occupied regions and power graphs or shrink it to just player colors for multiplayer games. That can wait because it requires more thinking what to show in preview since star dots on small map alone make too noisy image.
If you are really interested in feature list in upcoming milestone then you can take a peek at project's milestone task list. I promise to write more about it in next post :). Just one more thing about last post, I can't stress enough how important it was to change "state engine" to more native solution, I'll try a different angle at explaining it. Take a look at this image:
Previous solution contained a quite lot of "unclean" code meaning it was not fully supported by IDE (development environment) in some way or another. Engine for example was completely written in different programming language (T4) then the rest of the project (C#) and the nature of that language made it hard to write and debug. Instead of having IDE notifying me immediately when I wrote something wrong while writing the code I had to run the script in order to uncover simple type fellers and guess from cryptic error message where the problem is. Following script execution step by step was unsupported too and I had to resort to clumsy data dumping to find out where exactly the error is. At least that was the case in IDE I was using at the time, newer ones are a bit more helpful. Point of the engine was to generate C# code for data classes but it too had to happen through a bit more of T4 scripting in order to define which properties and behaviors particular class should have. Generated code should not be edited because T4 script would overwrite changes if retriggered so each kind of custom behavior has to supported by engine and used through class code generator script. In the end using all that generated code for big operations (copy, save, load) was relatively clean, there were some hoops to jump through in order to handle dependencies but nothing so dramatic.
New solution, as you can see from the picture is much much cleaner. Engine code is roughly equally in size as previous one but it's mostly nice and clean C#. There are few spots where a magic is used to generated code while application is running but it's kept to a minimum in both quantity and complexity. Even if something breaks there it's easy to debug. Data is now pure regular C#, no metaprogramming tricks. Well, class attributes have to have certain reflection attributes but let's pretend it's normal code, if nothing else it's very brief overhead. Now classes are free to have whatever constructor they need and set whatever property they want to default values and enjoy full IDE coding support in the mean time. This part was the biggest reason to change the engine and I'm happy with the result. Lastly, major operations are slightly simpler then before, there are still some hoops left but a little fewer this time. There, I'm done, hope this has convinced you :).
Nema komentara:
Objavi komentar