next »

[Enyx]

Hey guys, welcome to the thread for the development of my medieval RTS game. I'm coding this game in java using my custom 3D engine I call 'Enyx3D'. The engine is far from finished, but it holds enough capacity for the ideas used in this game.

The idea of this game revolves around using 'lanes' that run from one team's base to the other. To win the game, you must make use of your soldiers, spells, traps and other pieces of your arsenal to destroy the enemy teams base. I essentially visualize it as a combination of Age of Wars and Warlords, but set in a 3D environment, and with a different take on the mechanics used to win the game.

You will play on a campaign where you will travel throughout different maps and defeat different Kings around the world. Each King will appear on the enemy board during the respected mission, and you will have to faceoff against his army, of unknown capability and skills.

Please note that this is very rough currently, and a lot will change throughout the development process. Without further ado, here is the first devlog:





HELP: If you have any name ideas, or general ideas for the game, please reply and let me know!

Thanks,
Enyx.

[Foolish Mortals]

I'm always a fan of RTS games (though they're very hard to make right). I know this is your first post, but what sort of mechanics will set your game apart from the other tug-of-war style games you mentioned? Will you be able to choose certain compositions/orderings of units to send in each lane (ex: 2 warriors, archer, then mage, repeat) that can be set on repeat? Will the 3D aspect of your game play into the mechanics? Making a game in 3D can be a lot of work (hence why many indie games are 2D).

[Enyx]

I'm always a fan of RTS games (though they're very hard to make right). I know this is your first post, but what sort of mechanics will set your game apart from the other tug-of-war style games you mentioned? Will you be able to choose certain compositions/orderings of units to send in each lane (ex: 2 warriors, archer, then mage, repeat) that can be set on repeat? Will the 3D aspect of your game play into the mechanics? Making a game in 3D can be a lot of work (hence why many indie games are 2D).

Thanks for showing interest! All great questions too -
In terms of mechanics, I currently plan to have 3 cornerstones, which are Units (soldiers), Spells and Traps.

As for units, there will be a loadout screen where you can select 4 different unit types from your list of unlocked units. You will unlock more unit types by leveling up, and different Kings have a different special unit type each that can be used.

Similarly with spells, there will be 1-2 default spells given to every king, and then 1 spell that is king-specific. These unique spells will be based on the backstory of that particular King. (This is where 3D mechanics take place) For example, a human king may have a flame strike type of spell, that would affect both lanes around it. On the other hand an undead king could have a disease spell, that you could put on one enemy, and could spread to allies if they were 1 cell away, but would die if it couldn't spread in a certain time.

As for traps, well I know I want 3 basic types of 'traps', one that attacks enemies that walk over them, one that slows enemies that walk over them and one that acts as a blockade and stops the enemies proceeding, until it's been destroyed.

So essentially, I believe my game mechanics are going to revolve a lot more around strategy and putting together these different combinations to test their effectiveness in different situations. There will be a lot more happening on the board than games such as Age of War, which will make it a challenge. I like your idea of spawning different combinations of units, like set pieces, but I think this is way to big of an advantage for players, I want to make it as mechanically intensive and fast-paced as possible, whilst still keeping it fun.

I definitely agree that making a 3D game can be a lot more taxing than a 2D one, but in my case the heavier workload is only going to stem from needing good quality 3D models and animations. The way I'm coding it, alot of behaviours work in a 2D manner, so it doesn't give me too much extra work in that department. I'm confident that I should be able to have all the basic mechanics I mentioned here, done in around a month or less.

[DanTheMan112]

This is a great first start. Honestly I would go so far as to say anyone who nay-says the fact that it's written in Java doesn't understand the power of the language. C++ may be slightly faster but the truth is that you have the advantage of portability and the ability to write out to a browser, so don't listen to the elitists who say that C++ is better for any reason - it's really a question of the right tool for the job. It's also reasonably fast if you know what your doing, plus there's the advantage that you don't have to deal with memory access errors that are a plague when your writing your engine in C++.

I would definitely put some thought into the different kinds of troops and their respective abilities that they field on the battlefield, there's definitely potential there when you think about it.

[Enyx]

This is a great first start. Honestly I would go so far as to say anyone who nay-says the fact that it's written in Java doesn't understand the power of the language. C++ may be slightly faster but the truth is that you have the advantage of portability and the ability to write out to a browser, so don't listen to the elitists who say that C++ is better for any reason - it's really a question of the right tool for the job. It's also reasonably fast if you know what your doing, plus there's the advantage that you don't have to deal with memory access errors that are a plague when your writing your engine in C++.

I would definitely put some thought into the different kinds of troops and their respective abilities that they field on the battlefield, there's definitely potential there when you think about it.

I appreciate it man, thanks for following along.

I 100% agree with every point you made regarding the differences between C++ and Java. As a matter of fact, I probably wouldn't have started this devlog or even have a working prototype if I opted to start my engine in C++. Java is what i'm most comfortable with working in, and what I'm most proficient at currently. Opting for Java for my engine didn't restrict my idea process, it just so happens as this is the first 3D game I'm making and therefore I want to keep the scale down. I really just want to finish this project...

There will be a time for another project where I want to delve into the memory management wonders of C++, but for now I've got a couple of game ideas I want to churn out using my current engine. As it's my first 3D engine, I want to push every limit to find out the strengths and flaws of my engines design, to analyse and bring across to my next engine project.

I'm glad you agree that there's potential with the use of different unit types. It's something I've been prototyping a lot recently to try and get right. I'll be posting some gifs/screenies and hopefully another devlog reasonably soon, demonstrating these prototypes.

If you have any suggestions please get in touch!

[Enyx]

Sorry for a long gap between updates - exams caught up with me.

Introducing Ranged Units!

The following is the mechanical demonstration of a ranged unit, and in particular, this is an archer. This unit costs more, has less health, but the clear ranged advantage!

These units have a randomisation in the amount of power put into a shot, and a defined reload time, which defines their effectiveness on the battlefield.



And here's an example of a tactical way of using them to your advantage, having scouts in the front line, protecting the ranged units in the rear:



The archer is firing arrows, or how by code-name 'Missiles'. I've coded the missile class to be very flexible, allowing me to use them for all future ranged and spell mechanics. For example, all magical unit types, like mages, will use these missiles.

What's next?
 
Next I'll be working on billboard-made health bars, and creating a basic gui for displaying unit types available to spawn. Luckily, I've already put in the work to create a GUI rendering system prior to this project, which will save me a lot of time, however billboards are a new challenge for me.

Enyx.

[Enyx]

Not much graphical work to show off today, however, I've been working a lot on engine components to bring my game to life, and boost its efficiency.

Engine Work Done:

-Remappable Input Manager (Entire control system is now remappable and will make for a very easy controls menu when I start working on GUI interfaces. It also helped me tidy up a bunch of spaghetti code I was using for inputs previously).

-Sound Engine Work (I'm using OpenAL for my sound engine. Currently I have a basic sound system, however I need to work on directional sounds and a sound queuing system).

-.OBJ Loader improvements (Previously my OBJ loader was very basic, and could only load .OBJs made in a particular software, now I've made it able to parse multiple .OBJ export formats, including blender, which I'm currently learning to model with.)

-Cell finding and highlighting (I made this for my trap system, to display the cell to place a trap in. Currently using a placeholder model, however this will be replaced for something much cooler when I code my custom geometry shader!) - Check the gif below:



Other Progress:

-I previously said that billboards were going to be my next challenge, however, I couldn't get the 3D world to 2D screen position conversion to work properly (or as good as I expected). I ended up spending too long fiddling with my maths functions to try and achieve the perfect result, so I've pushed it to the backlog, as I think my time would be better spent on the main components of my engine that still need to be developed.

-I've started learning blender as I need some placeholder 3D models (tired of using bunnies for units), and will also need some basic animations to test my animation engine (when it's done). I started by making a very basic trap placeholder for the trap system that's currently being worked on (check pic below).



I've noticed that it's hard for people to relate to my game when all they see is placeholder models, textures and maps. I've also noticed that I enjoy working on the game more, when I've got some new models and materials to mess around with. Therefore, I'm going to try and do small amounts of model work alongside coding the main components!

The next devlog will cover the implementation of traps, the types of traps I envisage and their effect in the game. This shouldn't take too long.. (famous last words)

All for now,
Enyx