aboutsummaryrefslogtreecommitdiff
path: root/content/blog/098_super_ui.md
diff options
context:
space:
mode:
authorKatharina Fey <kookie@spacekookie.de>2018-01-23 01:30:08 +0100
committerKatharina Fey <kookie@spacekookie.de>2018-01-23 01:30:08 +0100
commitc12a6259c78ae00a777078f1bda55a43f751d398 (patch)
tree461b7ef11375667c059a3ea435792eaccaccf348 /content/blog/098_super_ui.md
parent68010226f8c0141ebb897abe03b3c2b6f699373a (diff)
Deleting old articles, refactoring articles and re-formatting some older ones. Generally getting things into order. Publishing this version
Diffstat (limited to '')
-rw-r--r--content/blog/098_super_ui.md (renamed from content/blog/reboot/098_super_ui.md)12
1 files changed, 5 insertions, 7 deletions
diff --git a/content/blog/reboot/098_super_ui.md b/content/blog/098_super_ui.md
index 064e784..1a76f90 100644
--- a/content/blog/reboot/098_super_ui.md
+++ b/content/blog/098_super_ui.md
@@ -3,19 +3,15 @@ Category: Blog
Tags: /dev/diary, libgdx, game dev, java
Date: 2017-01-24 00:14
-**Let me tell you a factual statement**
+**Let me tell you a factual statement**: UI programming is terrible
-*UI programming is terrible*
-
-**Let me tell you an even more factual statement**
-
-*UI programming in LibGDX is even more terrible*
+**Let me tell you an even more factual statement**: UI programming in LibGDX is even more terrible
I am a big fan of LibGDX. It's a really nifty library/ framework to get started with game development if you're more comfortable inside a code editor than a full blown game engine that is more targeted towards designers and artists. And I put my money where my mouth is: I have a series about LibGDX development for beginners on this blog and work almost exclusively with it when it comes to my own projects.
Yet, there is something that bothers me and there didn't seem to be a great solution to fix it. UI code structure. In this post I want to highlight a utility I have written for LibGDX which is very easily embeddable into your existing projects which will you help structure UI code more efficiently.
-## The root problem
+# The root problem
The reason I dislike UI programming with LibGDX is that it usually results in very long code files or passing dozens of parameters into sub-classes that are needed to update the UI for button presses, etc.
@@ -29,6 +25,8 @@ Looking at this structure we have three main components that interact with each
Implementing this structure with Scene2D and LibGDX will result in a lot of very ugly code. Because the network signals need to know everything about the UI (how it is structured, etc). And our window state can be written to by two different sources which means that we need to mutex it to avoid race conditions.
+# Maybe a solution
+
So, what was I trying to solve? First a bit of limitation of scope. Because a lot of UI problems have been solved over and over again and usually at the cost of runtime performance or with a *lot* of extra code.
1. UI code doesn't have to be embedded in a screen