This means I'll also try reworking and consolidating the tutorials so one can follow them with a more coherent "red thread", as well as improving the documentation in various other ways to help newcomers with the common questions we hear a lot. I have a slew of things in mind for 1.0.Īpart from bug fixing and cleaning up the API in several places, I plan to make use of the feedback received over the years to make Evennia a little more accessible for a new user. In the future we'll move to the develop branch again. On Futureįor now we'll stay in bug-fixing mode, with the ocational new feature popping up here and there.
#Gamemaker clean text wrap install#
The rise of the Linux Subsystem on Windows have alleviated most of this though and I've not seen any Windows install issues in a while. Post-launch we moved to Django 2.2.2, but the Django 2+ upgrades have been pretty uneventful so far.Some people had issues installing Twisted on Windows since there was no p圓.7 binary wheel (causing them to have to compile it from scratch).
#Gamemaker clean text wrap code#
People have wholeheartedly adopted the new f-strings though, and some spontaneous PRs have already been made towards converting some of Evennia existing code into using them. The purely Python2-to-Python3 related bugs have been very limited after launch almost all have been with unicode/bytes when sending data over the wire. I've not heard almost any complaints or requests for help with converting an existing game. Overall the move to Python3 appears to have been pretty uneventful for most users. It may still produce line widths >100 at times (especially for long strings), but otherwise this reduces the number of different PEP8 infractions in the code a lot. I have set it up so that whenever a new commit is added to the repo, the black formatter will run on it. I'm not really convinced that black produces the best output of all possible outputs every time, but as Greg puts it, it's at least consistent in style. But many places were sort of hit-and-miss and others were formatted with slight variations due to who wrote the code.Īfter pre-work and recommendation by Greg Taylor, Evennia has adopted the black autoformatter for its source code. Inline image by me (/griatch-art)Ī related fun development is Castlelore Studios' development of an Unreal Engine Evennia plugin (this is unaffiliated with core Evennia development and I've not tried it, but it looks pretty nifty!):Įvennia's source code is extensively documented and was sort of adhering to the Python formatting standard PEP8. Already now though, it has gotten plugins for handling both graphics, sounds and video: In the future we want to extend the user's ability to save an restore its layouts and allow developers to offer pre-prepared layouts for their games. It already had the ability to structure and spawn any number of nested text panes. On FrontendsĬontributor friarzen has chipped away at improving Evennia's HTML5 web client. But there few new features also already sneaked into master branch, despite technically being changes slated for Evennia 1.0. Since version 0.9 of Evennia, the MU*-creation framework, was released, work has mainly been focused on bug fixing. The art of sharing nicks and descriptionsĪnnouncing the Evennia example-game project "Ainneve"īuilding Django proxies and MUD libraries Being able to identify which change caused poor performance is essential to help you design a well-performing project.Spring updates while trying to stay healthy If you don't realise your project is slow until a long way in to development, it can be very difficult to identify what is making it slow. Testing regularly on your target devices also allows you to quickly spot any changes which have a big performance impact and revise it to be faster. The Remote Preview Paid plans only feature can make this quick and easy. To avoid surprises, test regularly on the intended device to make sure it is still running fast enough. Since your computer may be several times faster than your mobile device, you may inadvertently design a project that has no hope of running well on a mobile device and not find out until later.
If you are developing a project for mobile, you must test on mobile from the start. Modern desktop computers are very powerful, and most people develop on desktop devices. It's harder to get good performance on these devices because they often have much weaker hardware: slower CPUs, slower graphics chips, and less memory. Generally the main problem with performance is getting your project to run well on mobile devices like phones and tablets. There are also some best practices to help avoid getting stuck with a poorly performing project without knowing why. These are mainly aimed at avoiding situations which cause unnecessarily poor performance. This section covers some general performance tips.
0 kommentar(er)
