Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Nov 2002
Offline Last Active Yesterday, 04:50 PM

#5293819 Designing UI library - positioning items in containers

Posted by alnite on Yesterday, 10:44 AM

It's been a while since I wrote my own UI library, but here's my opinion.  Take it with a grain of salt:


Preferred size/min/max

I am not in favor of preferred size, min, or max.  I think this pollutes the logic.  Consider two child items side by side, both with preferred size of 100.  Container is resized to 150, what is the size of each child item?  If your answer is 75, then why bother with preferred size at all?  Why have a parameter at all only to be ignored?


Instead, each child should be responsible in its own proper rendering and logic in any size.  By any size, I mean even down to 1x1 pixel.  No minimum size, no maximum size.  You have a button, that button better works even when its 1x1.  You have a radio button, it better works at 1x1.


You can enforce minimum size at the container level, but child item (which cannot contain another child) should be able to handle any size.  Object positioning should be handled by the container, and any items should not dictate to its container how it should be positioned, neither preferred, min, nor max.


The reason why is that I have worked on some custom UI library that follows this Java's swing approach, and it has these preferred size, min, and max etc, and they dictate the way the container align and position its children.  It's hard to resolve conflicts at the container level if the child items can dictate to its container how to position itself.  One child say my min is 100, another say my min is 150, and container is resized to 200, which one should you resize?


It gets worse if child items are engineered with these preferred, min and max in mind, that certain logic starts to fail when the size goes beyond or lower than these arbitrary thresholds.  "Since my size won't ever go lower than 100, right?, so I'll draw this 5x5 important UI element at exactly the 95th pixel"  Guess what, your width is now 80, and that important UI element is now gone.  Great.


So, no min, max, or preferred at all.  As a matter of fact, maybe let the container tells its children their size.

#5293813 Cloudhosting a C# Console Application utilizing UDP

Posted by alnite on Yesterday, 10:03 AM

Actually most server apps I know of lack of a UI frontend.  That does not mean it can't have a UI frontend, just depends on your use case.


There are a few server "engines" out there that's been mentioned several times like SmartFox, though I believe it's Java, and I am not sure if it's the 'goto' service.  And in regards to AWS to Azure, it comes to personal preference.  Do understand that once you choose one, you'd usually 'marry' that platform.  It'll be another engineering task to move from one to another.

#5292941 How should I develop this game?

Posted by alnite on 22 May 2016 - 04:37 PM

because I know a single person with no team can't really do something good in this area


Actually, yes you can, but it does take a lot of time and dedication.



I want to develop an RPG game. It's not for me, or for many people. It's only for one special person. I have one month to do this, and I don't know where to start. 

The game would be a story that simulates the butterfly effect. The player will have many choices in many parts of the story, and choosing something will cause a different ending.


I think this is a little too much for a one-man one-month project.  Multiple ending paths isn't easy to do.  Being able to architect a game world where different actions lead to different things require a lot of iteration and testing.  You really have to know how to code a game well before taking this task, considering that you are new to game development.


If you are not familiar with game development, your initial struggle would be figuring out how animations, collisions, and different game mechanics work.  Different types of games require different technology.  For example, A* is not required for a fighting game, but maybe required for an RPG depending how you present it, and a very robust version is required for an RTS game.  What you need to learn and do really depend on what your game look like and how to play it.


So, scoping.  If you ask me, in one month, it's probably more feasible to do a pure text-based adventure game.

#5278639 best way to write clean code

Posted by alnite on 29 February 2016 - 12:06 AM



For example: If you have a function called "CreatePath()", make sure all that function does is create a path and nothing else.  Make sure you test it such that it can handle any combination of parameters and corner cases such that it has exactly ZERO (0) bugs.  "CreatePath" cannot call "CreateUnit" or any other functions that might dilute and increase its complexity.



2. Don't be afraid to refactor and rewrite parts of your code.


As you add more logic to your code, refactor is inevitable.  Don't wait to refactor until the last step.  One cause that leads to spaghetti code is people are afraid to create new bugs that they keep monkey-patching on top of what was originally a perfectly fine codebase.  I have been seeing this so many times in my professional life doing code review.  People are so afraid modifying an existing function to make implementation less complex, and would rather put another layer of complexity.


Me: "You can just edit that one function to accept an extra parameter, and it will be easier."

Them: "Well, I am not sure what it does and I don't want to break it" (or some other lame excuse like how he has to update the tests)

Me: "But now you just duplicated the code, and next developer will be confused which function to use"




3. Write Automated Tests


Test, test, test your code, and write a separate program to test your code.  In all my professional life, nothing have given me better confidence in my code until I have written automated tests for my code.  Sure, it's an annoying thing to do when you write your tests for the first time (ah geez, another shit to worry about), but the confidence you get from running one single command and have ALL your code tested and validated in less than a minute is just too good to pass up.


Follow #1 above to make it easier to write your unit tests.  Follow #1 above to make it easier to write functional tests.  If your code is a spaghetti, your tests will be a spaghetti too, and it will annoy the heck out of you.



4. Document Your Code


Another thing that most developers avoid (after writing tests) is writing documentation.  You HAVE TO write documentation to your code.  It sorts of gives your code that final conclusive stamp of approval and seal the envelope.  Writing documentation puts your mind into a 3rd person perspective.  I have found so many design flaws when writing documentation.  For example, let's say your CreatePath() function is badly written that it internally calls CreateUnit() and CreateEnemy().  Writing tests will make you aware of this, and writing documentation will make you reconsider what kind of parameters to accept to avoid calling CreateUnit() and CreateEnemy().


If tests make you aware about the internal working of your code, documentation makes you aware of how components in your code play with each other.  Writing documentation is a form of rubber ducky programming.  You are trying to explain to some other (imaginary or not) person who is clueless about how your code works.



#3 and #4 are your worst enemies.  Somehow developers avoid them like plague thinking they have godlike coding ability that no tests is ever required, and no documentation is ever necessary.  "Code should be self-documenting anyway" rolleyes.gif, I always laugh at that statement.

#5271790 Resolving Creative Differences

Posted by alnite on 18 January 2016 - 10:51 PM

Who is in charge of what?


If you have done any game development professionally, you will learn that the game that comes out won't be the exact match of what you are thinking.  You have to let go the control sometimes.  This is not just your game.


When this kind of problem arises, usually people would do AB testing.  Create both, and see what works better.  Peer feedback is the most useful thing in video game development.  I am sorry to say that most likely your idea sucks, and so is his (and mine, and everyone else).  We rarely get the first implementation correct.  Peer feedback is important as it gives you honest reviews if game is fun or not.  You'd most likely end up with something completely different than any of you two could imagine.

#5265007 Why didn't somebody tell me?

Posted by alnite on 05 December 2015 - 07:29 AM

There is a Search Tools in Google Search that allows you to filter results based on time.


One time someone in my office did this during a meeting and everyone was like "WAIT, YOU CAN DO THAT??"

#5264676 Indie Game Company Names

Posted by alnite on 02 December 2015 - 06:49 PM

Zombie Rose (you know, rise, rose, risen, a little pun here.)

#5262769 Software Tool Selection Process - Improvements please

Posted by alnite on 19 November 2015 - 01:05 PM


Unity wouldn't be here if the original developers decided to use an existing game engine

Unity was conceived from the very beginning as a middleware package - it wasn't like they built a game and spun the pieces into an engine after the fact.


Which makes it sort of an exception to this whole discussion. If your aim is to build brand-new middleware, then building from scratch is clearly indicated.



Maybe I misunderstood, but isn't it the discussion of this thread?  Given Software Tool X, shall I rewrite or use it?

#5262651 Software Tool Selection Process - Improvements please

Posted by alnite on 18 November 2015 - 04:53 PM

There is nothing wrong writing your own.  Unity wouldn't be here if the original developers decided to use an existing game engine.  It's just like a natural selection.

#5261425 How hard it is to live from games as indie developer?

Posted by alnite on 10 November 2015 - 03:34 PM

Technical expertise and making money are two different things.

No one here is stopping you from making games, just don't expect making profits from it.

#5259816 How to cope with code in different languages?

Posted by alnite on 30 October 2015 - 06:07 PM

My main concern is that developers should start treating their code as assets.  People always get opinionated about programming languages.  X is better.  Y is faster.  Z is easier.  Whatever your preferred language of choice is, it doesn't really matter because you still have to put in the code, and that's where it takes the most of your development time, not your language being slower (or whatever).  You have done the hard work, but now you are thinking of scrapping all that, and I hope it's not just because of some arbitrary reason like "C++ is better".


@alnite, My problem with Delphi/Rad Studio does not stem from the codebase in general, but rather the way Embarcadero is taking the product as well as the quality of the IDE itself. I have the IDE crash on me at least once a day. I end up chasing quirks deep in the VCL source, or rattling my brain trying to understand their Direct2D implementation since the docs are not that amazing. And frankly, as someone that has decades of programming experience but just trying to finish my first big game project, Pascal is not the way to go.

Please dont get me wrong. I love Delphi, but it will never match VS in term of power. I just watched a video on the new DirectX debugging features of VS2015 and I was blown away with how powerful it is and how deep you can investigate. Yet, interface-wise, nothing matches the speed at which you can pump out native Win32/64 apps.

Embarcadero isn't the same since Nick Hodges left...

And alnite, you're totally right, a game doesn't have to be written in C++. But I believe that using Delphi will make things more complicated. The first time around anyways!


From what I get reading your posts, it seems that you used Pascal for the editor, not for the game itself.  I don't see much wrong with it.  If you are inches away from completing the game, just hammer through it, finish it in Pascal, despite the IDE challenges.  Even if the game is written in Pascal, if you are *that* close in finishing the game, just finish it.  This happens all the time in studios, and that's because it makes sense financially and time-wise.


Future shiny version can be written in C++ if you prefer.

#5258996 How to cope with code in different languages?

Posted by alnite on 25 October 2015 - 02:02 PM

I have a few options I thought of, most of them are problematic, so this is where I would appreciate some insights.


What are the problems?  Does the current Pascal codebase have any problem?  If not, why do you insist on porting it to C++?

A game does not have to be built in C++.

#5255209 What exactly is API-First?

Posted by alnite on 02 October 2015 - 12:55 PM

Just had a conference today and they talked about micro services. Seems the trend these days is to push a lot of little web api's and then make your products like legos by picking the services you need to complete the project. So literally your app could be made up of 20 different web api's, where each does their very own very specific task. As a developer I like this approach because you can really break the tasks down for your team and keep things very specific and simple to work on. Just better make sure when you change an api you are really careful since it could be used in a hundred different apps.


Microservices is not a new idea.  It's old.  It wasn't feasible back in the day because the amount of effort to maintain hundreds of services.  For each service, you need a physical machine, sysadmins to maintain the machine, developers to maintain the app, and some deployment process for updates.  One service is fine, but when you have hundreds of them, who's going to take care of it all?


Now with virtualization everywhere, Puppet/Chef/Ansible/Salt scripts for server maintenance and deploys, and recently Docker that can simplify deployment dependencies, the microservices idea resurfaced again.  It's not a paradigm shift.  It's like dusting off an old keyboard and you realized how awesome those springy keys were.

#5255206 What exactly is API-First?

Posted by alnite on 02 October 2015 - 12:49 PM



API is just some methods with bunch of parameters, RESTful HTTP stuff.


Looks like a tech journalist with no real technical knowledge got to talk to some bigshot developer at some crowded convention, and the word API got thrown around in the conversation.  Having first heard of the word API, this journalist think it's the next big thing.  Insert big company names like Google, Intel, HP, and Netflix, API makes it sound like it's a whole new idea that's driving the industry now.

#5254926 How do you plan your project?

Posted by alnite on 30 September 2015 - 10:41 PM

For personal projects, I only keep a TODO file on the project folder.  Inside this TODO file is a list of features I would like to implement.  The purpose of this file however is not to serve as a ticket-tracking like JIRA but a reminder for my future self.  Personal projects tend to suffer from drag with no specific deadlines, due to personal circumstances, changes in your life, etc.


If I am in the middle of implementing something, I will finish that feature even that cost me some sleep hours.  I don't want to be staring at my code 10 weeks later with my code half working and forgetting what I was doing.


For this reason, a full-featured ticket tracking like JIRA or anything else feels a little over the top for personal projects.