12 lines
3.5 KiB
Text
12 lines
3.5 KiB
Text
These are some of the smaller design decisions that I made:
|
|
|
|
- In the Arena class, I replaced the old loop in UpdateEntities to an improved loop that keeps track of whether or not a pair has already been visited. In my opinion, (a, b) and (b, a) should be dealt with at the same time rather than in two separate occassions, since it makes it easier to calculate when one entity happens to be a player and special actions need to be taken. There is large amounts of spaghetti code in this function, but following it makes logical sense, it doesn't ever goto outside of the scope of the function, and I could have as easily handled the same functionality with a ton of flags.
|
|
- Rather than setting the speed to zero, I added a flag to indicate whether an entity was frozen. Also, I made this flag a member of all mobile entities, even tho some of them cannot be frozen, like home base.
|
|
|
|
Several larger-scale design changes were made to the system as a whole.
|
|
|
|
- This change hasn't been propagated completely, but I had this idea that since many of the entities in the arena (as well as the arena itself) is constructed from a struct of parameters, I should actually save this set of parameters for later use in the Reset function, rather than saving individual pieces of information (such as where Player started, what color Robot was, etc.) If I just save the entire params, I could just reference it later and it could be a const. Again, this hasn't been completely implemented but just a concept.
|
|
- The arena now exhibits the observer pattern by providing an API for entities to register their sensors to the arena. Then, every frame, the arena will perform calculations to determine whether that particular sensor should be set to an active state. Each entity will then handle the event. This is in contrast to the old system where the arena simply performs a limited set of "hardcoded" calculations pertaining to a specific set of collisions. This choice is better than the hardcoded calculations because it makes the arena closed to change: when new functionality needs to be added, a new Sensor and Event is created for it and processed by the entity, while the arena simply performs general calculations.
|
|
- The motion handler is now a generic class that the player has one of and the robot has another one of. The player's motion handler will be able to accept commands from the keyboard, while the robot's motion handler will mainly be responsible for handling collisions and helping the artificial robot brain determine where it will go next. The reason for this abstraction is because these motion handlers have similar purposes, but their exact functionality differs from entity to entity. Therefore, an abstraction would make it easier to keep the similar parts under the same code, while tweaking only the different functionality in the base class.
|
|
|
|
Another design decision that I have been contemplating for a while but have not yet implemented is delegating the actual rendering of the graphics to each entity. Therefore, rather than requiring the GraphicsArenaViewer to contain methods such as DrawPlayer, it should instead contain a simple DrawScreen function that calls the Draw() functions of its children, which then calls the Draw() functions of its children until it reaches a child which renders itself using the passed graphics context. This approach also parallels the UpdateTimestep function, which delegates what happens to each individual class by calling a UpdateTimestep() function that exists within the child classes.
|