Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Anrlndo]

Hi guys. I'm new to the forum and new to DF. I'm inspired by Zach and Tarn's work and I would like to start developing my own games. I've got some basic skill in Python and I have a few questions for anyone that would be interested in helping:

1. What technical aspects should you consider when getting into game development? the things that I can think of thus far are:
graphical models
music
animation
concept design
story writing/character development
programming experience

Am i leaving anything out here?

2. Programming language - which would be the best for an open source sandbox game with basic graphics? I'd like to develop a game with graphics like some of the packs included in the LNP for DF. What language would you recommend? I have some experience with Python, what else would be best to get familiar with?

3. Any other major tips or things to consider if I seriously want to get into developing my own work? I just want to work on it in my spare time and release it for free for people to enjoy.

4. Any good online sources or courses (paid/unpaid, idc atm) that can help me learn these basic things?

Thanks so much, hope to hear from you guys soon!

[Levi]

1) Trigonometry!  I only mention it because I suck at it and it always seems to come up.

[hawkeye_de]

Hi Anrindo,

it depends what your are trying to do...do you want to create a roguelike with similar graphics like DF ? Or more graphic-intensive games ? Just be aware of that more ambitious your visuals are, the effort will be also exponentially higher. So in any case start simple!

Python is fine to start with.

Just tell a little more what y wanna achieve, then we could give more concrete tips.

[Anrlndo]

Sure. So what I want to do is create my own sandbox game with the ability to mine to different sub levels like in dwarf fortress, and have randomised events, a procedurally generated world with different races, lore and apocalyptic events that act as challenges to the player. I like the graphics in various packs for df, which I find a little bit more accessible than the ASCII graphics. I'd like to be able to simulate basic primitive technology such as growing crops such as wheat to be ground in a mill into flour and then transport those resources to a bakery for workers that can be assigned roles such as baker, for example. I'd like to incorporate similar trade types for carpenters, writers, priests, miners, militia, sorcerors, engineers, potters, hunters, etc. I'd want to incorporate a weather system with seasons and have enemy NPC factions such as native monsters that are sentient beings that can create their own dwellings, military buildings, cast spells, etc.

I like in dwarf fortress how it is a living world and anything can happen at any time. You can be invaded by were monsters, demon invasions, floods, etc. I'd like to incorporate something similar into my own game.

Hopefully that gives a rough idea of what I want to achieve.

[hawkeye_de]

Since you have a big game idea in mind, you should strongly consider to start with ASCII graphics. You can use Tiles later... You find some tutorials https://www.reddit.com/r/roguelikedev/ in the tutorials section in the right view.
If you want to learn Kotlin, there is also a pretty new engine for tile/grid games, which has the advantage that it has a GUI system...https://hexworks.org/posts/tutorials/2018/12/04/how-to-make-a-roguelike.html. Personally I would not choose Python if I want to make a big game but for learning it is perfect.
*Disclaimer* I am one of the contributors of Zircon. */Disclaimer*

But again....if this is your first game, start a small one...look at https://7drl.com/ for some inspirations. Your scope should not be bigger for your first game.

[Anrlndo]

Thanks a lot Hawkeye, appreciate the help

[ChairmanPoo]

You should consider whether you really want to develop games or you prefer to play them instead 

I get the impression that many would be developers mix the two. This leads to hilarious kickstarter results 

[Reelya]

Highly recommend checking out some industry-related podcasts, such as the ExtraCredits one on youtube.

One big part you missed out of your skill list is all the management side of things. Making the assets for the game is only a small part of it. For example, QA/Testing time would likely exceed programming time by a big margin.

One thing you probably should definitely NOT do is jump right in and start coding your "dream game" with a long list of cool stuff you're going to add to it. These projects never get anywhere because you're constantly cramming stuff in and it will always look and feel like a mess that you can't show anyone.

Focus instead on scoping out small ideas for demos or small games. Have a strict feature list and time frame. These should be written up as an elevator pitch (1-3 sentences describes the thing to make) along with a Game Design Document. (https://en.wikipedia.org/wiki/Game_design_document) that's about a page or so outlining the feature set, target platform, time frame etc.

Then, making the thing and work out how long it actually took you and write up a game post-mortem.
http://lvictorino.com/blog/write-post-mortems.html
A post mortem should be a short essay describing what you made, what went to plan, what didn't go to plan, and how you plan to improve things the next time. The goal of each game-design cycle is that you have a complete, small game that's ready to upload as a demo.

If the scope was too large (didn't finish a playable game in the aloted time), make another one with less scope. Here, the concept "minimal viable product" is useful. The MVP is the smallest feature set that exhibits all the desired behavior. for example, if fighting and collecting loot is part of the design, you need exactly one enemy type and one loot type. The same concept can be applied to adding new content to an existing bigger game you're working on: treat each new addition as a mini-project, write up an elevator pitch and 1-page design-doc related to the new content and budget time to complete it, along with milestones etc, and do the post-mortem for it the same as you do for a complete game.

As for all the stuff you want to add to your game, consider studying something call the "gameplay loop".
https://gameanalytics.com/blog/how-to-perfect-your-games-core-loop.html
Gameplay loops are a concept about the cycle of actions that players must take while playing the game. Run, jump, shoot, kill, heal up is a rough outline of the gameplay loop for an FPS. However, there can be overlapping / nested / fractal gameplay loops. For example, killing enemies and collecting loot is one loop but you can have another loop of your weapon being damaged/repaired/upgraded along with high-level character goals being another loop (clearing stages/levels/area). Dwarf fortress's Fortress Mode gameplay loop probably alternates between "build structures" and "assign workers". By focusing on the "gameplay loop" as your core design principle you ensure you stay focused on what the player is doing, rather than focus on "adding more stuff". e.g. if you decide "the game needs 7 types of bread for variety" then you can ask, how does this add new gameplay loops or improve existing ones? It doesn't, so don't add more types of bread.

Another important area is to study game theory if you want to be a designer. A "dominant strategy" is one that is always the best option. They are basically the death sentence for game design. If you add one of these inadvertently, they basically ruin your game design. This is why many units in games stick to a "rocks-paper-scissors" type of balance. If you have a "best" weapon, or "best" armor then this is a design problem. Why do any people have non-best armor then? Players will always ignore the other choices if there's one best one, so there will be no variety of builds or weapon/armor choice.
http://www.gametheory.net/dictionary/DominantStrategy.html