Talk:Unreal Engine 4
Add topic| This is the talk page for discussing improvements to the Unreal Engine 4 article. This is not a forum for general discussion of the subject of the article. |
Article policies
|
| Find video game sources: "Unreal Engine 4" – news · newspapers · books · scholar · JSTOR · free images · free news sources · TWL · NYT · WP reference · VG/RS · VG/RL · WPVG/Talk |
 | Text or other creative content from this version of Unreal Engine was copied or moved into Unreal Engine 4 on July 18, 2024. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. |
Chronology of early UE4 development
[edit]Accroding to the article as it is now, it seems that Sweeney was the only one working on UE4 from 2003 to 2008. However in Nov 2005 Mark Rein said the following:
When can we expect to see Unreal Engine 4, then? Rein tells us that he was showing a journalist round Epic's North Carolina headquarters recently, explaining how one of the options for new employees will be working on research projects into the next-generation of gaming. "The guy said, "So would that be Unreal Engine 4?", and I said, "Yeah I guess it will be." So technically Unreal Engine 4 is in development, but it's for the next generation of machines, not even the ones coming out now."
I'm not sure how to add this into the article. Technically Rein only said that developers would have the option to work on UE4, so it's hard to say anything specific. Do note that as these are both primary sources they can contradict each other and we don't need to maintain consistency between them.
source: https://www.gamesindustry.biz/focus-epics-mark-rein-sets-the-record-straight J2UDY7r00CRjH (talk) 23:46, 18 July 2024 (UTC)
Proposal: Standardized release history tables for Unreal Engine articles
[edit]I would like to propose adding standardized release history tables to the Unreal Engine articles, starting with Unreal Engine 4 and, if the community agrees, extending the same format to Unreal Engine 1, 2, 3, 5, and future versions.
Currently, release information is mostly presented as prose, making it harder to compare versions and follow the engine's evolution. A standardized table would make the information easier to read, maintain, and update.
The table could include fields such as:
- Version - Release date - Build number (if applicable) - Major features or changes - References
Using the same layout across all Unreal Engine articles would also provide a more consistent experience for readers.
I also have a question regarding maintenance. Since Epic Games publishes official release notes for every new version, would it be possible to automate updates (for example through templates, Lua modules, Wikidata where appropriate, or another maintenance workflow), or is manual updating preferred by the community?
I would be interested in hearing the community's thoughts before starting this work. Gogo25171 (talk) 13:21, 24 July 2026 (UTC)
- If you mean subversions like 4.1, 4.2, 4.x I think it is not a good idea in general just from my own preference, and additionally due to WP:NOTCHANGELOG. If you are referring to the major versions, we sort of have that as summaries in Unreal Engine.
- I do agree however that engine changes are hard to follow. For example there are a ton of new features in UE5 that aren't mentioned. Eg: Procedural Content Generation, new software lumen, new AA method (SMAA), new animation tools etc. This said I don't think having a table of each release's features is the right answer. First of all, only notable new features should be added to the article. What exactly is notable is hard to say, I think it should only be fully new systems, or new features that solve long standing issues. So I think that rules out automated release notes. Second, additional to the notability guidelines in WP:NOTCHANGELOG, I think the more you have dates and version numbers in an article the worse it reads. For example instead of "In [year], [version] was released, containing [features]" copy pasted for each release, it might be better to just say "in later versions, [features] were added," where [features] contains the features from many versions combined. Because, the average reader probably does not care what date and version a feature was released. They may only care that it was added in a subversion, and if we didn't write it that way then readers would assume that it was contained in the initial release. Another option is to write something like "between [eg.] version 4.2 and 4.5, several features were added, including..." and then listing important features in chronological order. Then again, this loses information, so it's a tradeoff. Another option would be to list the exact version only for very important features that significantly contribute to the history of the development of the engine, but this is hard to quantify. Maybe we can look at other software examples. Although in my opinion, many software articles read like changelogs already. Also, I'm not 100% against listing versions, I'm mainly trying to give some input. J2UDY7r00CRjH (talk) 17:31, 26 July 2026 (UTC)