The smart way to do stuff.

[desocupado]

In the second semester of 2012, I started making a game. I planned for a turn based rpg. For about 4-5 months, I learned C++, SDL and game designing, and at the same time worked on it.

Long story short, by the end of those 5 months I had a battle system done.
It featured:
-Equipment
-Buffs/debuffs
-Melee and ranged attacks (It featured a row system, where only the front row was reachable in melee)
-Nearly 100 different skills/spells implemented and working properly (a few needed testing)
-A few enemies with rudimentary AI (If you killed a mercenary a necromancer would raise it as a zombie. Once I forgot I had implemented that, and saw it happen, it was cool as all fuck)
-Item usage

I was proud as fuck of it. Still am, since it was my first and only big project in C++.
On the other hand I'm also aware that it had:
-No animations
-Poorly commented and messy code
-Hacks all over the place
-Probably some bad shit I, to this day, still don't know how to do properly.

One of the things that stuck out like a sore thumb was the way I did the UI. I didn't know how to do the UI at the time, and I still don't, so what I did? In my game loop I detected clicks, checked where the clicks ocurred, and if it was a click on an area I assigned a button, it would call the proper function. This was a pain in the ass to make, made the code a hard to understand mess, specially with sub-menus.

Now, that old itch is back. I want to code some shit. I'm planning C# and either XNA or Mono (or something different if I read a compelling argument). It's gonna be a turn based tactics game with mechs.

Anyway, this wall of text is to ask: What's the smart way? Point me in the right direction on UI making, animation handling. What should I learn that will save me time, what tool should I use to make my life easier? What's easier (and cheaper to get assets) nowadays, 2d or 3d?

Just to say, I'm hardly a proper programmer. It's a hobby, and I have yet much to learn.

 

[ProphetSword]

You might consider Unity. It uses C#. I've been working on a turn-based CRPG in it for a while now using it, and it does most of the graphical work for you so that you can get the code knocked out. There's a learning curve involved, but once you've mastered it, you could pretty much make any kind of game with it.

 

[FuriousGamer87]

For 2d, you may want to consider using pixel art as it is the fastest and easiest way for a non-artist to make presentable graphics.
Learn to abuse color theory and proper shading techniques
Use skeletal style animation techniques where every movable parts is broken up as it's own for easy replacement.
This allow to you to use the same animations for every other characters quite easily while redoing everything from scratch.

No idea about 3d since I give up on that once I realize coding graphics in 3d is hell without a team.

If you are not a programmer, then best you learn how to do SVN and backup really quick first.
SVN or Subversion is designed so you will always have different copies of your game assets in different stages of your development.
This is important, especially when you want to try out new stuff or you wreck your code and have no idea what the fuck happen.
My recommendation is using TortoiseSVN for doing so.
Backup is also very important if you don't want to lose all your hardwork in a single freak accident.
Use google drive for this purpose. It's free version is more than enough to do the job well.
Remember to put the SVN source folder into the google drive folder for double the security.
Make sure to commit your changes after every gamedev session when you still remember what did you change. It takes only a few seconds and will save you a lot of grief when you need to troubleshoot when you did fuck everything up.

 

[Fuzzy]

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.

 

[Destroid]

I think git/hg and github or similar is a significantly better option than using SVN and a cloud service. However for a one man project source control doesn't add that much value over making copies.

 

[desocupado]

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.

What I am asking, is the smart way to do it. My UI code became hopelessly tangled with the other stuff in my previous project, it was stupid, but I didn't know better. I didn't use an API for anything other than graphics.

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.

When I ask what's the smart way, I mean, what should I know before coding an UI, and animation, what tip will make me avoid shooting myself in the foot? What API's do I use for UI and animation, and what graphical API will make my life easier, offering me already made tools to work with graphics.

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.

 

[TheFilthyJack]

My humble suggestion would be to have simple 2d graphics placeholder and focus on the combat mechanics and simple movements as well as UI code. Also, seperating the Rendering code, so that you can have the same ruleset/combat mechanics and will be able to update to 3d later. Even if your coordinate system is 2d it is very easy to adapt to 3d as you only add a fixed Height coordinate determined by the floor/walkable area/tile.

Here are in my opinion the most challenging parts of game engine coding:

-Runtime Scripts : If you don't want to have to recompile the whole engine everytime you add a game script you'll probably need to have a script engine able to interpret and link them to in-game events at runtime. (AI, cutscenes, ui, dialogs)

-Dialogs : It can be easy but then you also need scripting actions and conditions in dialogs too. So you need to create your own dlg/scr format and store them as external resources.

-Resources Loading : You will probably need to save all your characters/dialogs/scripts and graphics as external resources that the engine loads at runtime, this means basically adding Class.SaveToFile() and Class.LoadFromFile() to your exsting structs/classes.

-3d geometry/texture loading : A pain if you're not using any lib. Basic .obj format is a good start, as every 3d software can export/import from obj.

-3d physics : Quite advanced maths, if you don't mind geometry related maths then you're fine, there are a few free decent libs in c++.

For the rendering part you'll find an infinite amount of free libraries to load and animate 2d sprites and tile-based maps. This is why you can focus on developping the fun part which is everything not related to rendering 3d objects and animate them. If you chose 3d you'll have a hard time finding free or well documented code on how to load geometry/texture/bones/weights and handle the matrix-related maths.

I guess one thing you should focus on as well is threading and timers. You have to setup a GameSpeed and have certain events running 'at the same time'. This is quite challenging for new programmers but is a very powerful tool if handled correctly. Also organise your project files, it becomes huge once you have a working engine.

Coding a full engine for fun is cool, it doesn't matter if you're skipping a few steps in programming, as long as you're entertained or motivated you'll want to learn more on your own.

What API's do I use for UI and animation, and what graphical API will make my life easier, offering me already made tools to work with graphics.

That would be Unity nowadays.

Good luck

PS: (Sorry for the wall of text...)

 

[desocupado]

Can you elaborate more on runtime scripts? I have no idea what those are, and how you fit those in a program.

You said you can use them for AI, for example. In my previous program, the AI routine was a series of if's checking the conditions of the PC's and enemies, to decide on what to do. For example:

if (ally_hp < 30%) heal
else if (enemy_hp < 30%) set enemy as target.
attack( target );

Of course with loops and stuff to iterate over the ally/enemy list. This was all done in C++ code, inside the enemy class.

 

[slowdive]

In C#, you can compile and run code at runtime (after the program has started). This allows users to add code or functionality to the program. I used the following code in IceBlink to allow users to create and run their own scripts (from IceBlink Engine GitHub):

#region Script Stuff
public void executeScript(string scriptPathFileName)
{
bool foundOne = false;
Assembly compiledScript = null;
string filename = Path.GetFileNameWithoutExtension(scriptPathFileName);
foreach (AssemblyObjects ao in assemblyObjList)
{
if (ao.AssemblyFileName == filename)
{
foundOne = true;
compiledScript = ao.AssemblyCompiled;
break;
}
}
if (!foundOne)
{
string textReturn = readTextFile(scriptPathFileName);
compiledScript = CompileCode(textReturn);
AssemblyObjects newAO = new AssemblyObjects();
newAO.AssemblyFileName = filename;
newAO.AssemblyCompiled = compiledScript;
assemblyObjList.Add(newAO);
}
if (compiledScript != null)
{
RunScript(compiledScript);
}
}
public Assembly CompileCode(string code)
{
// Create a code provider
// This class implements the 'CodeDomProvider' class as its base. All of the current .Net languages (at least Microsoft ones)
// come with thier own implemtation, thus you can allow the user to use the language of thier choice (though i recommend that
// you don't allow the use of c++, which is too volatile for scripting use - memory leaks anyone?)
Microsoft.CSharp.CSharpCodeProvider csProvider = new Microsoft.CSharp.CSharpCodeProvider();
// Setup our options
CompilerParameters options = new CompilerParameters();
options.GenerateExecutable = false; // we want a Dll (or "Class Library" as its called in .Net)
options.GenerateInMemory = true; // Saves us from deleting the Dll when we are done with it, though you could set this to false and save start-up time by next time by not having to re-compile
// And set any others you want, there a quite a few, take some time to look through them all and decide which fit your application best!
// Add any references you want the users to be able to access, be warned that giving them access to some classes can allow
// harmful code to be written and executed. I recommend that you write your own Class library that is the only reference it allows
// thus they can only do the things you want them to.
// (though things like "System.Xml.dll" can be useful, just need to provide a way users can read a file to pass in to it)
// Just to avoid bloatin this example to much, we will just add THIS program to its references, that way we don't need another
// project to store the interfaces that both this class and the other uses. Just remember, this will expose ALL public classes to
// the "script"
options.ReferencedAssemblies.Add(Assembly.GetExecutingAssembly().Location);
options.ReferencedAssemblies.Add("system.dll");
options.ReferencedAssemblies.Add("system.data.dll");
options.ReferencedAssemblies.Add("System.Windows.Forms.dll");
options.ReferencedAssemblies.Add("System.Drawing.dll");
//options.ReferencedAssemblies.Add("System.Drawing.Bitmap.dll");
options.ReferencedAssemblies.Add("IceBlinkCore.dll");
options.ReferencedAssemblies.Add("IceBlinkScriptFunctions.dll");
options.ReferencedAssemblies.Add("IceBlink.exe");
options.ReferencedAssemblies.Add("IceBlinkToolset.exe");
// Compile our code
CompilerResults result;
result = csProvider.CompileAssemblyFromSource(options, code);
if (result.Errors.HasErrors)
{
// TODO: report back to the user that the script has errored
StringBuilder sbErr;
sbErr = new StringBuilder("Compiling file: ");
sbErr.AppendFormat("\"{0}\"", "script.cs");
sbErr.Append("\n\n");
foreach (CompilerError err in result.Errors)
{
sbErr.AppendFormat("{0} at line {1} column {2} ", err.ErrorText, err.Line, err.Column);
sbErr.Append("\n");
}
MessageBox.Show(sbErr.ToString(), "C#Script – Error");
return null;
}
if (result.Errors.HasWarnings)
{
// TODO: tell the user about the warnings, might want to prompt them if they want to continue
// runnning the "script"
}
return result.CompiledAssembly;
}
public void RunScript(Assembly script)
{
try
{
object o = script.CreateInstance("IceBlink.IceBlinkScript");
object[] parms = new object[] { frm.sf, parm1, parm2, parm3, parm4 };
o.GetType().GetMethod("Script").Invoke(o, parms);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
this.errorLog(ex.ToString());
}
}
public string readTextFile(string filePath)
{
StreamReader streamReader = new StreamReader(filePath);
string text = streamReader.ReadToEnd();
streamReader.Close();
return text;
}
#endregion

 

[TheFilthyJack]

You said 'inside the enemy class', what happens if I need to have unique behaviour or reaction for every character?

This is a really nice feature to be able to interpret a script at runtime in C#

For example your AI is made of if statements and different gameplay conditions, but you may want to have a different AI for each chracter. In that case you would have a small script assigned to each character.

*script: a set of instructions either in plain text (you need to create a parser/interpreter), or pre-compiled.

Example of game events:

struct character
{
int char_id,
coord_x,
coord_y,
stat1,
stat2;

......

int script_id_ai, //runs every turn or predefined time
script_id_on_damage, // runs when character takes damage, to be able to make him say 'ooch' or consume pots when hurt.
script_id_on_death, //when character dies you may want to update a death count or even make other enemies flee etc..
script_id_on_heartbeat; //executes every game loop
};

Your engine loads the resources at runtime and all the scripts. Then your main game loop takes care of sending the events (calling required scripts when appropriate). Then you can have all the default AI scripts but also some custom unique behaviour (bosses etc). No way you're putting all this code in the engine itself

The same example is valid for UI:

on_click
on_mouse_over
on_keypress

and pretty much everything else:

objects:

on_damage
on_interact
on_pickup

The concept allows you to modify anything in the game without having to touch the engine.

 

[desocupado]

Interesting. On my first big project, I was putting everything on the engine. Every enemy class had it's own AI routine made of ifs. Some copy and pasting and some modifications depending on the expected behaviour.

Where can I read more about scripting? You got a book or a link?

This feature isn't present on C++ right?

 

[TheFilthyJack]

Scripting is just your set of 'if instructions', it can be in C++ too, only in a separate file (precompiled), scripting is the ability to execute external code from file or memory. C# is apparently able to compile and execute C# code from source at runtime.

A very basic scripting example...

Engine:

Pointers to available functions.

0-Attack(character, target)
1-Say(character, text)
2-Move(character, x, y)

List of Characters.

0-Player
1-Npc1
2-Npc2

Engine loads this 'script' in memory and interprets/translates it:

1 1 hello
2 1 56 135

Say(Npc1, "hello");
Move(Npc1, 56, 135);

This way you only compile the engine once and then modify/add script files, or character/spells/items files saved in binary format for fast loading.

I don't have any reference for scripting in game engines but some of us like slowdive might be able to give you more tips. I'm using a developper tool to precompile scripts for me as well, these can then be executed easily.

 

[28.8bps Modem]

This feature isn't present on C++ right?

Well, you can load a native code at runtime (dlopen), but it's not exactly a great way to do your scripting. It'd be a pain in the arse to maintain.

There are however a bunch of scripting languages that are pretty trivial to embed in C++ programs. Lua is the most commonly used for the purpose, since it has a comprehensive standard library but not so comprehensive that it's a nightmare to lockdown all the system calls you never want a script to able to access. Check out the embedding part of the manual if you're interested, it's pretty easy to get started.

That said, if you're not wedded to your existing codebase, it might make sense to have at least a look at Unity as other people have suggested. The asset store can be a help for your problem of getting animated characters, though don't get your hopes up. Sometime the selections can be pretty meagre outside of some bog standard scenery, etc.

Whether you decide to use 2D or 3D rendering, it makes a certain amount of sense to do your animations in a 3D modelling package. A lot of 2D rendered games like current codex darling Underrail use 3D models rendered as sprites for their character animations. It's a big time and money saver over hand animation in 2D.

 

[J1M]

slowdive, use the code tag.

desocupado, I will answer the question you posed in the first post. The industry standard, "correct", way of handling a UI is to use a Model-View-Controller pattern combined with an event system.

There are many variants on the Model-View-Controller pattern. The stock pattern you will see in a textbook is not very practical, which is why you will find modified versions of it in the commercial implementations. The most well-known of these is the MVVC pattern from Microsoft.

Model - The actual data. If the checkbox is true/false, the list of items.
View - The graphical element presented to the user.
Controller - The glue between the other two classes. Tells the view to animate, tells the model to change state.

An event system is basically a way for unrelated objects to talk to each other. You register one class to be notified when a certain event happens. A different class "fires" that event. An event manager sits in the middle and passes events to the classes that ask for them. The advantage and disadvantage of an event system is that the class that fires the event does not know or care if the event is responded to.

Regarding tools:
I recommend the Github for Windows application combined with a free private github repository from a different git repo site. (A private repo costs money on github.)

I like working in XNA with C#. That is a solid choice, and if you ever have a hit on your hands it is fairly easy to convert your game to other platforms using MonoGame. (In fact, all of the best-known MonoGame games started as XNA projects...) Comparatively, Unity debugging is limited and a pain in the ass.

I don't have a specific UI library to recommend to you for XNA. I built my own because I was interested in building a UI system like that. If I was starting from scratch today without a desire to build my own, I would try to find a library that allowed use of CSS/HTML to define the UI layout. Be wary of a UI system that was built for a very simple genre. Most of the Unity tools that are available are guilty of this. They offer the ability to easily get a high score on the screen, but building complicated RPG menus is a ridiculous endeavor.

If you aren't able to find a more robust option, I might be able to share the UI system I built a couple of years ago. I strongly suspect there is something more complete out there.

 

[QuestionMan]

You can program the most elaborate system, but you will have a hard time filling it with appropriate assets. Been there, done that.

Placeholders... Yes, you can create a game using placeholders all the way through, but it's not so easy to just replace the placeholders in the end.
The most important thing is to check your imagination with reality:

This ugly rough terrain is the placeholder for an epic landscape.
This white quad is a placeholder for a flashy stylish button.
This cube is the placeholder for a highly artistic model.
This ugly house model is the placeholder for a skyscraper.
This empty gameobject is the placeholder for a cool magic particle effect.

If that's your project - scrap it! All these things only work in our wild imagination, but not in reality.
You can bluff yourself with "sure I can do it, I'll make some assets myself and the rest I'll buy from some store".

Ok, so you are making a button in Photoshop, and you want this button to be *final* in your game. Here comes the catch: in order to have something *final* you want a certain polish and style. A style that even fits the atmosphere of the game and looks right in all places. Can't be that difficult, can it? Yes, it can! A simple fucking button!

Ok, then you say... scrap it, I'll buy all assets. First it costs a lot of time to even find art assets. Then a lot of time to evaluate if it fits your style. Then a lot of time to adjust and modify it, so it fits the aesthetics. Of course a lot of money too.

These are things which can make many projects - even as a hobby - stop, and end up frustrating at best. What is the solution of that?
Probably going fully abstract for your project. Abstract and yet aesthetic with colors. Even if you have a cube-game with minimal art... it's not so easy to make it aesthetically pleasing. Don't go for pixel-art - too much of a Sisyphean task. Everything involving visual or audio art is a special area. That's reality. I'm writing because I'm in the same boat... and while I meanwhile realized how much of an effort all this artwork is, I am considering recreation projects or mods more, because the time required to produce assets of similar quality - is... a lifetime.

 

[Davaris]

Anyway, this wall of text is to ask: What's the smart way? Point me in the right direction on UI making, animation handling. What should I learn that will save me time, what tool should I use to make my life easier? What's easier (and cheaper to get assets) nowadays, 2d or 3d?

Just to say, I'm hardly a proper programmer. It's a hobby, and I have yet much to learn.

The smart way to do anything, is to use something someone better than you made. So find an engine made by someone who's skills you know and respect.

When it comes to art, 2D is easier than 3D. If you ever expect to make a game anyone else would want to play, store bought assets isn't going to cut it. Individually the assets may look great, but together with a lot of other assets, it looks like a pile of random rubbish. So if you can, make your own art. If you don't have the interest to make art, team up with someone who does. I would say exactly the same to artists. I've seen enough artist only made games that look good, but the game play is dull and lifeless. If you don't like programing, you can't make fun games, so team up with someone that has that interest.

Speaking for myself, I won't waste a cent on assets until I'm forced to. I just use the ones that came with the engine I bought.

BTW An example of someone that did art the right way is Styg. He's not a brilliant artist but his game looks coherent, because he made the art himself.

 

[CyberP]

team up with someone who does..

You make it sound easy. I don't even know an artist.

 

[Davaris]

Its not easy. You have to go where artists hang out and ask them. 99.9% will turn their noses up, because they've been burned by useless programmers in the past.

Regardless, buying random assets is a waste of money IMO. You will spend a lot and your game will look like crap. I'd advise newies to get their game as close to done as possible, with placeholder assets. Then when you have a working game, worry about the art.

 

[CyberP]

"I'd advise newies to get their game as close to done as possible, with placeholder assets. Then when you have a working game, worry about the art."

Really, so you essentially double development time? Not to downplay the rest of your suggestions, but I'm not sure this is good advice.

 

[Davaris]

"I'd advise newies to get their game as close to done as possible, with placeholder assets. Then when you have a working game, worry about the art."

Really, so you essentially double development time? Not to downplay the rest of your suggestions, but I'm not sure this is good advice.

Most people will never finish their games.

And your point only makes sense, if you only make one game. If you make a good game on your first attempt (never happens), you can work on the next game while art is made for the first.

Making a game that no one will play because of random assets, is the biggest time waster of all.

 

[Destroid]

You will also have plenty of bugs and crap to fix in your game while the artist arts. I think art is also a lot faster to produce than code.

 

[QuestionMan]

No, this fully depends on your experience.

 

[belowmecoldhands]

I've coded mainly in c++ in my life so far. I've also played with many other lanuges, but t othe same amount.

Lately I was using allegro. I switched from Windows OS to Ubuntu and so I had t oabandon MS VC 2010. So now I've got codeblocks but haven't really figured out how to get everything runing again. The code I was using should work in Ubuntu if I can.

Anyway, wanted to say one of hte things I wa working on was a UI system which allowed for windows and events. I could probably have found something like this online and saved myself time, but I though it'd be fun to try. My point? It's not as easy as it looks.

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.

Want to know something interesting? The only time in my life I finished a game was in school, in 7th grade. I did it in a few days. It was a simple (if problematic) board game. You know why i finished? I finished because I had to. In all the years since I've oftne wanted to make a game but never idd. And the best reason I can think of is because I could never set limits.

 

[Sranchammer]

Programming is the opiate of the underclasses.

 

[Ninjerk]

Programming is the opiate of the underclasses.