文件列表:

dotnet (0, 2020-10-08)
dotnet\PlanetCS1.csproj (178, 2020-10-08)
dotnet\src (0, 2020-10-08)
dotnet\src\Model (0, 2020-10-08)
dotnet\src\Model\Abstract (0, 2020-10-08)
dotnet\src\Model\Abstract\BlankTile.cs (602, 2020-10-08)
dotnet\src\Model\Abstract\ITile.cs (702, 2020-10-08)
dotnet\src\Model\Abstract\RealTile.cs (194, 2020-10-08)
dotnet\src\Model\Abstract\Resource.cs (388, 2020-10-08)
dotnet\src\Model\Abstract\Tile.cs (986, 2020-10-08)
dotnet\src\Model\Abstract\Unit.cs (316, 2020-10-08)
dotnet\src\Model\Enemy (0, 2020-10-08)
dotnet\src\Model\Enemy\Buildings (0, 2020-10-08)
dotnet\src\Model\Enemy\Buildings\EFactory.cs (261, 2020-10-08)
dotnet\src\Model\Enemy\Buildings\EGasCollector.cs (277, 2020-10-08)
dotnet\src\Model\Enemy\Buildings\EHQ.cs (247, 2020-10-08)
dotnet\src\Model\Enemy\Buildings\ENRGPlant.cs (264, 2020-10-08)
dotnet\src\Model\Enemy\Units (0, 2020-10-08)
dotnet\src\Model\Enemy\Units\EBuilder.cs (293, 2020-10-08)
dotnet\src\Model\Enemy\Units\ESoldier.cs (293, 2020-10-08)
dotnet\src\Model\Enemy\Units\EWorker.cs (290, 2020-10-08)
dotnet\src\Model\GameData.cs (1165, 2020-10-08)
dotnet\src\Model\Location.cs (391, 2020-10-08)
dotnet\src\Model\Map (0, 2020-10-08)
dotnet\src\Model\Map\GrassMap (0, 2020-10-08)
dotnet\src\Model\Map\GrassMap\GrassUnits.cs (8536, 2020-10-08)
dotnet\src\Model\Map\GrassMap\GrassWorld.cs (8124, 2020-10-08)
dotnet\src\Model\Map\Map.cs (624, 2020-10-08)
dotnet\src\Model\Model.cs (7065, 2020-10-08)
dotnet\src\Model\Move.cs (225, 2020-10-08)
dotnet\src\Model\Neutral (0, 2020-10-08)
dotnet\src\Model\Neutral\Buildings (0, 2020-10-08)
dotnet\src\Model\Neutral\Buildings\Building.cs (326, 2020-10-08)
dotnet\src\Model\Neutral\Buildings\Factory.cs (420, 2020-10-08)
dotnet\src\Model\Neutral\Buildings\GasCollector.cs (363, 2020-10-08)
dotnet\src\Model\Neutral\Buildings\HQ.cs (341, 2020-10-08)
dotnet\src\Model\Neutral\Buildings\NRGPlant.cs (391, 2020-10-08)
... ...

2/19/20: As I progress on this project, I have gained far more comfort with the Kotlin language. In the past, I tried to do a similar project in Java, however the verbose nature of the Java language does not make it well suited to rapid application development. Despite its mobile-intentions, Kotlin is just as well-suited to make desktop or server applications. Some of my favorite aspects of Kotlin are its concise nature. While I am not totally fond of conciseness that causes ambiguity, it seems easier to contend with as I spend more time with it. Another positive aspect is its ability to target the Java Virtual Machine, meaning Kotlin immediately has a large number of compatible platforms. Kotlin is compatible with all Java libraries, meaning all Java libraries can be used in Kotlin, and vice-versa. Kotlin's adoption in Android development has been rapid, however enterprise adoption has been sluggish, due to the preference of the industry to stick with what's widely known. Hopefully, this can change sometime soon because after using Kotlin,I never want to go back to Java! 2/23/20: PlanetJ1 has entered Alpha state. I am using PyQt5 for the GUI and Py4J to communicate the GUI with the JVM. Currently, I am able to move my one unique "unit" around the screen on a small grass map. Now that I have a solid foundation, I can start adding features :). PlanetJ1 is almost entirely integer-math based so it runs very fast, however there is a lot of memory optmization I can do. Because of the use of Py4J, the game can also be run over a network with client-server architecture, although it currently only supports one shared session. This means there could be potential for a multiplayer feature as well. The biggest issues I've had to gripe with is certain data structures. When using Kotlin, ArrayLists become almost completely useless as it's much better to use Kotlin's mutableLists. There are several features that have been completed already but simply aren't functional yet since I wanted to have a working version, first. 2/24/20: PlanetJ1 has some new features. I've completed the viewmode, meaning now the player can view an entire map without moving a unit around, however I will need to add the ability to specify a unit to return to in select mode. That is why the tiles on the GUI are also buttons, but I haven't gotten around to adding listeners to all those buttons yet. I've also added large map support, meaning maps are no longer restricted to 11 x 11 and can now go up to 2,147,483,***8 x 2,147,483,***8. I've also improved the GUI, adding the "Commander X16" (a reference to David Murray's computer project), an attempt at a more powerful, compact interface. I will also have to clean up the code because in my haste to add features I made it messy. 2/26/20: PlanetJ1 has one new feature. I've added "next builder" functionality, meaning if you click the Next Builder button, the game will "jump" you to your next builder. I felt like this was an extremely important usability feature because manually moving the viewscreen around to select units would be a huge pain. The functionality for the other "Next" buttons as you can imagine will implement similar logic, just for different unit types. At this point, I do not have any "Next" buttons for buildings, so those will have to be added as I add buildings. However, since I have the jump logic down well it will take only minor tweaks to be compatible. At this point, I'm thinking of adding my first building. This means I will not only have to add build functionality to the builders, but also add a building and its respective functionality, too. 2/27/20: No new features, however game logic is now threaded, meaning multiple moves can now be suggested to the game at a time which are then processed in batches to solve concurrent access issues. Threading was also necessary to finish implementing the build logic that I've been working on. I've also made the first building, which is a factory. I've also added logic for builders to build stuff, but I haven't implemented it fully yet. 2/28/20: The only new feature this time is the presence of the player factory now in game. Unfortunately, it is still not functional. I am almost finished with the build logic and also almost finished with the create logic, so not only will the factory be able to be built, but it will also be able to produce units as well :). I also found a movement related bug which allowed units to move over buildings which I have now corrected. An additional bug I found was with my "Next" logic which originally worked with only builders, but once I added additional units it no longer worked correctly. As a result, the next functionality had to be almost completely rewritten 3 or 4 times until it worked as expected. I also changed the "Next Builder" button to automatically go to Set Mode regardless if the GUI is in Set Mode or not because I imagine if you are scanning through your units you would want to see their stats or move them around or issue a command to them. Although feature growth has slowed recently, it will be worth it in the long run because the logic I have programmed is designed to be extendable, meaning adding new units and buildings will be very easy. The things I will work on next will be GUI commands that can be issued to selected builders to queue up buildings to be built in the model. Once that is done, I can then extend that logic into the creation logic which should be similar. 2/29/20: Build functionality is now complete. I also added a "wait" property to every unit and building, meaning they cannot build or create unless a certain amount of time has passed. Actions are "queued" until the timer expires. Resources are now displayed in the GUI, and creating/building will use them up. That makes what needs to be worked on next pretty straightforward: I need to implement some resources for the player to gather to replenish this supply. In addition, I also had to rework the movement and screen drawing logic. It's now much simpler. Instead of having duplicated units in the units layer and in the units list, now I just have all unit changing logic operate on the unit list. Some unit layer logic is still quite useful, so I have kept it. I also have finalized the create logic so factories can now make builders. The "next" buttons for workers and factories also now function, too. 3/1/20: Resource gathering functionality is now complete. During the gathering process, the resource's salvage value is added to the player's stockpile until the resource's health reaches 0, at which point the resource is replaced with a grass tile. During salvage, a worker is not allowed to move and currently salvage cannot be cancelled, which adds a strategic element to gameplay. I may add cancel functionality later. I think the next thing I should tackle is combat logic. I might just start off with melee-based combat and later move into projectile based combat, but we'll see. I now have melee-based combat working and I prevented the spamming of attack by setting a wait timer after every attack. Most of the base features have now been implemented, so I suppose it's time to start implementing the enemy logic. 3/2/20: Abort functionality is now complete. I've completed a rough draft for a first map. I still need to work on the enemy units and buildings. I've also added the Gas Vent, which is where a worker can be assigned to collect Gas. 3/3/20: I've completed the first map, which is a lake with a grass field around it. The lake is surrounded by gas vents and mineral deposits. Maps are now independent classes that are loaded into the model at startup. Maps can visually be designed within a simple text editor, which eliminates the need for a separate map editor application. The only issue is that the unit and the world layers have to be designed separately, but it's not really much of an inconvenience because the layers can be copied and pasted and text can be replaced with find/replace all, etc. I've also discovered that Py4J has a reflective access condition when returning ArrayLists of Strings. This currently does not affect the operation of the game, however this sort of access potentially will not be allowed in future versions of the JDK. This issue does not seem to affect Strings alone, however. That means this issue can easily be solved in the future if it becomes necessary. Instead I can return Strings to the Python GUI which can then split them into the respective substrings based on a specified delimiter, removing the need for ArrayLists of Strings. 3/24/20: As part of my new efforts to learn C#, I started porting the Kotlin project into a .NET Core 3.1 project. I haven't looked into it, but there's probably ways to call C# code with Python too, meaning my Python frontend can work with the C# version as well.

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：