The smart way to do stuff.

[Twiglard]

In C#, you can compile and run code at runtime (after the program has started)[...]

Just be aware code can't be unloaded then. Once it's loaded, it exists in memory as long as the program hasn't yet finished execution.

Shit, in SDL, I had to make a method to wrap the SDL_ttf (the thingie that writes stuff on the screen), because writing something to the screen using SDL involved like, 5 function calls (loading a font, creating a surface, writing on that surface, etc). So I made a method to do all those 5 when I called my own function. This is the kind of job I wanna avoid. [...]

Answering FuriousGamer87, I kept back-ups of my code, with the dates in the name locally and online. I'll read up on what SVN is.

As for SDL, there's sdlmm that wraps the stuff around in C++-specific constructs. I haven't used it yet but seems sane <http://sdlmm.sourceforge.net/classSDLmm_1_1Surface.html#d0>.

Use git nowadays, not svn for versioning the code. Observing a proper (that is, efficient) version control workflow requires some training, but once you do, you won't come back.

Doing stuff from scratch since you don't understand existing solution is a project in itself.

Recommend using either Qt Creator or KDevelop for IDE. Just beware of Eclipse, it's a buggy, overcomplicated mess.

I think if you want to make your first game you should not ttry too hard to make it perfect. Keep things simple and hardcoded. Don't fear if it's spaghetti-like. Don't spend too mcuh time wondering what it'll be like in a year or two. Just get thigns done.

It's a lot faster to hardcode than ti's to modularize everything, at leas at first. If you succeed and make a game and keep doing it THEN you should try to modularize so things are more reusable. I'm just giving advice not to do that in your first game.

If anything programming for years for a living taught me, it's to hate actually writing. Think more, write less. Programs grow large and the spaghetti nature of code can't keep up with the sheer size of the functionality.

Modularizing makes sense for having a module not concerned with what other modules are doing. Less they communicate, the better.

 

[belowmecoldhands]

Twiglard, in my experience, it's a heck of a lot easier to hardcode UI pieces. I did a test-run of this idea and had a basic UI going almost immediately. The only problem was it was spaghetti-like. It'd be fine if I was just making one game. However, what if I wanted to reuse the code? What if I came back a year later not having finished it and got confused by the big ball of yarn on the screen? Spaghetti code is easy to work with if you're familiar with it, but soon as you walk away for a while it's s***.

I made this advice bcause modularizing (making reusable) everything is a big job and not always necessary either.

Many people who start making games do not code well. Their first game is crap. However, it could be that not looking at the details tooo much is the reason they finished their first game AT ALL. Maybe some people are different.

My other peice of advice was to set limits on your game and on yourself. Without limits, you'll probably never finish. And don't think about the future too much either, as it can throw you off. Keep the game simple and don't spend too mcuh time on it. Too much time just means there's a greater chance you'll lose interest and never finish it.

A lot of this is tied to the advice someone else about not doing all the engines yourself. Try to get them online as a package or library. It'd take a LOT OF TIME to make all the engines yourself AND make them all reusable.

Here: (http://www.rpgcodex.net/forums/index.php?threads/the-smart-way-to-do-stuff.95265/#post-3589259)

If you aren't interested in being an engine programmer I wouldn't suggest making your own tools. With Unity, UE, and a host of other options you can focus on design and not have to do things like implement an entire animation system from scratch. Even the humblest rpg is enough of an undertaking it is good to take shortcuts whenever you can. So I would grab an engine and a tutorial and go from there.

 

[Mastermind]

Maybe I was not clear, when I said I'm not a programmer, I meant to say that I don't have enough knowledge and experience to consider myself one. But I love doing the stuff. Using something like gamemaker or stuff that cuts off the coding part would eliminate part of the fun.

Gamemaker doesn't cut off the coding part if you're making a game that's even remotely complex. 90% of the time I spend in gamemaker involves coding something. It just speeds up a lot of tasks and makes stuff a lot easier to organize. Amusingly, the way you did the UI is pretty much the same thing I did in gamemaker.

 

[Twiglard]

Original poster, it'd help a lot if you asked specific, separate questions, not as run-on sentences. Otherwise it devolves into abstract vague talk.

Many people who start making games do not code well. Their first game is crap. However, it could be that not looking at the details tooo much is the reason they finished their first game AT ALL. Maybe some people are different.

I don't agree at all. Don't finish the first game, explore the problem space. Even if finished, it woulda been simple and/or buggy crap only salvageable if had good death animations.

 

[Raghar]

Anyway, this wall of text is to ask: What's the smart way? Point me in the right direction on UI making

Perkel

UI is always strongly dependent on game, and it shows artistic impression.There is no smart way in UI making. I always drawn UI prototype on paper until I was satisfied, and then made it. I tend to use an extremely lightweight overlay, as a last post-processing step. I try to keep it separate from rendering as much as possible to be able to test game independently on UI, and to avoid breaking stuff on UI changes. It also allows me to create nice decorations when I have time, which I don't have because I review code during testing. It's quite important to take time when programming UI, because it's what player would see majority of time, and it should be unobtrusive, well designed, and easy to use. Then it's only about to register event listeners, capture input at correct place, and make it well responsive. If you keep UI in separate thread, try to spend effort to ensure you'd communicate with low latency with the rest of the game.

Various games are using various algorithms for handling UI elements/pixels. Some can get away with something extremely simple, other needs quite complex stuff.

That's about the gist of it.


There can be also problems with handling conversion of coordinates into worldspace in 3D scenes. But it also needs tailored solutions.

One of funny problem is too exact handling 3D models, model moves because of animation, and user would select another model because the click resolution is too exact. (Divinity Original Sin had this.) Another fun is clicking into space between hand and body, because hand moved.

 

[Norfleet]

Unless you're making the UI itself the game, I would say that the best UI is the one which presents the user with the most useful information absorbable and allows the user to perform the action he desires with as little effort as possible. So, by logical extension, the ideal UI is a direct brain feed of all information and then doing the desired action as the user thinks of it. Obviously, you will not achieve this, but the goal is to approach this ideal form.

The opposite of this is turning a horrid UI into the game itself, like QWOP, where the task is trivially simple, but the UI is intentionally horrible, and that's the game. This conjures up the hilarious image of a next-gen shooter given an interface like QWOP, so your character flops around like a de-boned fish trying to shoot his enemy without shooting himself.

 

[J1M]

http://www.awesomium.com/

This looks like it does what I suggested earlier (using HTML/CSS to define a UI). Hopefully someone around here will have time to review it.

 

[Davaris]

http://www.awesomium.com/

This looks like it does what I suggested earlier (using HTML/CSS to define a UI). Hopefully someone around here will have time to review it.

It was so good they used to offer it as a plugin on C4. He has a 'no outside libraries rule', so that should tell you how good he thought it was. With the free version you could have a web browser inside your game. I got it working and yes it was awesome.

https://www.terathon.com/wiki/index.php/Browser_Plugin

Unfortunately the Awesomium people changed the interface to the library often. This is a big no no in libraries and caused support problems, so C4 reluctantly dropped it. The Awesomium people breaking the link to your game, every couple of months is something you might consider, otherwise it does what it promises.

Speaking for myself, other than a cool buy now webpage inside your game, I wouldn't bother with it. I'd just get an engine with its own full featured interface library.

 

[J1M]

Speaking for myself, other than a cool buy now webpage inside your game, I wouldn't bother with it. I'd just get an engine with its own full featured interface library.

Sadly, unless your definition of this is very loose there aren't many engines that have one.

 

[Davaris]

Sadly, unless your definition of this is very loose there aren't many engines that have one.

I guess it depends on what you want. The engine I use has everything I need. It even lets you make additions using their plugin system.

http://www.terathon.com/wiki/index.php/Panel_Editor
http://www.terathon.com/wiki/index.php/Widgets

 

[J1M]

I guess it depends on what you want. The engine I use has everything I need. It even lets you make additions using their plugin system.

http://www.terathon.com/wiki/index.php/Panel_Editor
http://www.terathon.com/wiki/index.php/Widgets

A quick look at the API suggests you specify everything in pixel sizes? And there is no way to theme controls independently of each other?

That is quite primitive.

At bare minimum I would expect the ability to anchor controls to each other and specify dimensions in terms of percentage.

 

[Davaris]

A quick look at the API suggests you specify everything in pixel sizes? And there is no way to theme controls independently of each other?

That is quite primitive.

At bare minimum I would expect the ability to anchor controls to each other and specify dimensions in terms of percentage.

Could be its specified in pixels, so you can work with texture maps? All I know is when I change the size of the screen and restart the engine, it is all scaled correctly.

Could be its just one theme, since its for making games. You'd have to ask him about that.

I haven't a clue what you are talking about when it comes to "anchoring controls". I make what ever interface I like and I can drag it around the screen and it works. Sorry, I'm not an interface expert. I just use it and it works.

If you have more questions or suggestions, I suggest you ask him over there.

 

[adrix89]

For the GUI of a project that I am coding I found the most simple and flexible design is a hierarchy tree with parent child relationships and a basic class for all the elements(text,button,images) to subclass.
I am using an engine(Love2d) based on lua so it works just with tables. Note the hierarchy and the classes are separate, the hierarchy is just a basic table.

Drawing can be as simple as selecting any element in the hierarchy and it will draw it and its children in the branch.
Mouse and keyboard focus is also simple. Just tell what branches are to be evaluated and it will go from the top of the tree towards the root.
There are a couple of tricks like text focus and optimization possible but that is a library problem.

The game maker would just need to make a new element, add it to the hierarchy table and override the functions and data he wants like the update function or click function.
No need for complicated classes, no request system,event system, states, quotas,stacks. The elements are just things that are drawn and manipulated, you can have your own separate structures and class system for items,inventory,stats and simply link them to the elements you need.
I think this design is much more flexible and clean then Immediate Mode GUIs(IMGUI)

For other languages it would require some other similar data structures but it shouldn't be too complicated.